22.03.2018
0
89

Добрый день, сегодня хотелось бы затронуть такую тему, как безопасность сайта. Обычно владелец сайта думает об этом уже по факту взлома, хотя ошибки были допущены практически в самом начале его создания.

Сегодня мы с вами поделимся типичными ошибками, которые приводят к уязвимостям на сайте, а также дадим пару советов насчет того, что же все таки стоит делать и на что обращать внимание как программистам, так и владельцам. И начнем с программной стороны.

Выбор системы, на которой будет сделан сайт

Самое важное в начале создания сайта — это выбор системы, на которой он будет построен. Сейчас это может одна из подобный категорий:

  1. CMS (WordPress, Joomla, Bitrix, Magento, PrestaShop) и таких более 150-ти штук;
  2. Framework (Laravel, Zend, Phalcon) — здесь круг до 10-ти штук примерно;
  3. Самописная система какой-то компании – ни в коем случае, если только это не какая-то очень крутая компания с многомиллионным количеством клиентов. И здесь хочется добавить: любой самопис потенциально опасен, потому что его делает 2-5 человек, и эта система не поддается общему представлению, соответственно считать, что её сделали эксперты, нельзя;
  4. Конструктор сайтов – это выбор для отдельной категории людей — тех, кто хочет быстро, красиво и с проблемами в доработке сайта. Очень часто случается так, что сайты на конструкторе нельзя изменить так, как этого хочется. Кроме того, их банально нельзя оптимизировать и работать с ними студии не берутся потом.

Подводя итоги по категории систем нужно сказать лишь одно:

Если вы выбираете CMS или Framework, то выбирайте однозначно проверенную временем и рейтинговую систему, она априори будет лучше своих более мелких товарищей, так как имеет большое комьюнити и прошла уже через множество усовершенствований.

Систему выбрали, пора и сайт делать

После того, как система выбрана, часто для клиента наступает этап «черной коробки». Это процесс, при котором сайт делается, даются промежуточные результаты, но при этом нет никаких тестирований системы или же нет просто адекватной проверки как программистами, так и самим заказчиком.

Приведем пример для большей наглядности.

Заказчик: нужна форма регистрации и 2 обязательных поля.

Разработчик: ОК.

Результат: форма есть, поля есть, но, например, при разработке не был учтен тот факт, что человек захочет, как вариант, вставить в поле имени вот такой текст:

<b>Привет мир</b>

Что приведет к тому, что форма пропустит теги и запишет их в таком формате прямо в базу данных.

Это пример самой банальной и простой ошибки, но в более сложных случаях хакеры могу внедрить через такие поля свой скрипт, и это приведет, как минимум, к нарушению работы админ панели с сайтом.

Поэтому, совет для всех (не важно разработчик вы или заказчик):

Уделяйте внимание данным, которые поступают из всех форм. Все поля должны быть валидированы и проходить элементарные проверки и очищение от ненужных символов.

Начиная уже с таких мелких проверок вы сможете построить первую стену безопасности на сайте.

стена

Если в компании нет тестировщиков, которые могли бы проверить сделанный сайт на минимальные требования по безопасности, вам, как заказчику, остается лишь верить в то, что программист после недельной работы не просто закрыл проект и пошел домой, а еще выделил время на то, чтобы проверить свой собственный код. Честно признаться, программисты часто ленятся это делать сразу, и могут сделать лишь одно глобальное тестирование в конце проекта, или же сделать тестирование поверхностным.

 

А это чаще бывает вот в таком случае: сделали на сайте форму и подключили на нее валидацию только при помощи Javascript.

 

В обычной среде любой человек зайдет, попробует что-то сделать не так и ему скрипт скажет о том, что «вы не ввели данные» и у вас нет шанса ошибиться. Но представьте ситуацию другую: на сайт заходит хакер, у которого в браузере отключены скрипты. К чему это приведет? Правильно! Как минимум к тому, что он сможет отправить вам тысячи пустых форм и испортить вам жизнь на часок другой.

Поэтому хочется сделать небольшой вывод, который разработчики должны постоянно помнить:

Свой код нужно проверять как в нормальных условиях, так и в необычных условиях его работы, а именно нужно идти от обратного: заранее не доверять введенным данным и предполагать, что у клиента может что-то не сработать. А как итог, писать валидацию не только на стороне браузера, но и на стороне сервера.

тестируем

Все эти наблюдения были получены из личного опыта как разработки, так и ведения проектов. Теперь хотелось бы сделать некий топ советов, которых стоит придерживаться, чтобы ваш сайт был более безопасным в сети.

 

Советы для повышения безопасности сайта

 

Совет первый. Обновляйте программное обеспечение.

 

Это может показаться очевидным, но постоянное обновление программного обеспечения имеет жизненно важное значение для обеспечения безопасности вашего сайта. Это относится как к серверной операционной системе, так и к любому программному обеспечению, которое вы можете запускать на своем сайте, например, в CMS или на форуме. Когда в программном обеспечении обнаружены дыры в области безопасности, хакеры быстро пытаются злоупотреблять ими.

Если вы используете управляемый хостинг, вам не нужно так беспокоиться о применении обновлений безопасности для операционной системы, поскольку хостинговая компания должна позаботиться об этом сама.

Если вы используете стороннее программное обеспечение на своем сайте, такое как CMS или форум, вы должны убедиться, что вы быстро применяете любые исправления безопасности. У большинства поставщиков есть список рассылки или RSS-канал, в котором подробно описаны проблемы безопасности веб-сайта.

Многие разработчики используют такие инструменты, как Composer, npm или RubyGems для управления зависимостями своего программного обеспечения, а уязвимости безопасности, появляющиеся в пакете управления, являются одним из самых простых способов получить удаленный доступ.

 

Совет второй. Защищайтесь от SQL инъекций

Атаки SQL-инъекций — это когда злоумышленник использует поле веб-формы или параметр URL, чтобы получить доступ к базе данных или манипулировать ею. Это легко предотвратить, всегда используя параметризованные запросы. Большинство веб-языков имеют эту функцию и ее легко реализовать.

 

Рассмотрим этот запрос:

Если злоумышленник изменил параметр URL для передачи такого кода  ‘or ‘ 1 ‘=’ 1, это приведет к тому, что запрос будет выглядеть следующим образом:

Поскольку «1» равно «1», это позволит злоумышленнику добавить дополнительный запрос в конец оператора SQL, который также будет выполнен.

Вы можете исправить этот запрос, явно его параметризируя. Например, если вы используете MySQLi в PHP, это должно может выглядеть вот так:

Совет третий. Защита от XSS

 

Атаки с использованием межсайтового скриптинга (XSS) вводят вредоносный JavaScript на ваши страницы, который затем запускается в браузерах ваших пользователей, а также может изменять содержимое страницы или украсть информацию для отправки назад злоумышленнику. Например, если вы показываете комментарии на странице без проверки, тогда злоумышленник может отправлять комментарии, содержащие теги скриптов и JavaScript, которые могут запускаться в браузере каждого другого пользователя и украсть их файл cookie для входа, позволяя взять под контроль учетную запись каждого пользователя, который просмотрел комментарий. Вы должны убедиться, что пользователи не могут добавлять активный JavaScript-контент на свои страницы.

 

Это особая проблема в современных веб-приложениях, где страницы создаются в основном из пользовательского контента и которые во многих случаях генерируют HTML-код, который затем также интерпретируется интерфейсами, такими как Angular и Ember. Эти фреймворки обеспечивают много возможностей защиты от XSS, но смешивание сервера и клиентского рендеринга также создает новые и более сложные возможности атак.

 

Ключевым моментом здесь является сосредоточение внимания на том, как ваш пользовательский контент может избежать ожидаемых атак и интерпретироваться браузером как нечто другое, что вы подразумевали. Это похоже на защиту от SQL-инъекции. При динамическом создании HTML используйте функции, которые явно вносят изменения в код или используйте функции в вашем шаблоне, который автоматически выполняет соответствующее экранирование, а не конкатенацию строк или установку необработанного содержимого HTML.

 

Еще одним мощным инструментом в панели инструментов защитника XSS является Политика безопасности контента (CSP). CSP — это заголовок, который сообщает браузеру о том, как и каким образом выполняется JavaScript на странице, например, чтобы запретить запуск любых сценариев, не размещенных в вашем домене, запретить встроенный JavaScript или отключить eval ().

 

Совет четвертый. Сообщения об ошибках

 

Будьте осторожны с тем, сколько информации вы выдаете в своих сообщениях об ошибках. Предоставьте только минимальные ошибки для ваших пользователей, чтобы убедиться, что они не раскрывают секретов на вашем сервере (например, ключи API или пароли базы данных). Не предоставляйте также подробные сведения об исключении, так как они могут сделать сложные атаки, такие как SQL-инъекция, намного проще. Храните подробные ошибки в журналах сервера и покажите пользователям только необходимую им информацию.

 

Совет пятый. Валидация / проверки на стороне сервера

 

Валидация всегда должна выполняться как на стороне браузера, так и на стороне сервера. Браузер может обнаруживать простые сбои, такие как обязательные поля, которые пусты, и когда вы вводите текст в поле только чисел. Однако их можно обойти стороной, и вы должны убедиться, что вы совершаете и более глубокую проверку сервера, поскольку это может привести к введению вредоносного кода или кода сценария в базу данных или может привести к нежелательным результатам на вашем веб-сайте.

 

Совет шестой. Загрузка файлов

 

Разрешение пользователям загружать файлы на ваш сайт может быть большой угрозой безопасности сайта, даже если это просто возможность смены аватарки. Риск состоит в том, что любой загруженный файл может содержать скрипт, который при запуске на вашем сервере полностью открывает ваш сайт.

 

Если у вас есть форма для загрузки файлов, вам нужно обрабатывать все файлы с большим вниманием. Если вы разрешаете пользователям загружать изображения, вы не можете полагаться на расширение файла или тип mime, чтобы убедиться, что файл является изображением, поскольку их можно легко подделать. Даже открытие файла и чтение заголовка или использование функций для проверки размера изображения не являются полным доказательством. Большинство форматов изображений позволяют хранить раздел комментариев, который может содержать PHP-код, который может быть выполнен сервером.

 

Так что вы можете сделать, чтобы предотвратить это?

 

В конечном итоге вы хотите, чтобы пользователи не могли выполнять любой файл, который они загружают. По умолчанию веб-серверы не будут пытаться выполнять файлы с расширениями изображений, но не рекомендуется полагаться исключительно на проверку расширения файла.

 

Некоторые параметры — переименование файла при загрузке, чтобы обеспечить правильное расширение файла, или изменить права доступа к файлу, например chmod 0666, чтобы он не был выполнен.

 

Большинство хостинг-провайдеров сами конфигурируют сервер для вас, но если вы размещаете свой сайт на своем собственном сервере(VPS или VDS), есть несколько вещей, которые вы должны проверить.

 

  • Убедитесь, что у вас установлена ​​настройка брандмауэра, и блокируются все несущественные порты.
  • Если возможно, создайте DMZ (демилитаризованная зона), обеспечивающая доступ только к портам 80 и 443 из внешнего мира.
  • Если вы разрешаете загрузку файлов из Интернета, используйте только безопасные методы транспорта на ваш сервер, такие как SFTP или SSH.

 

Наконец, не забывайте об ограничении физического доступа к вашему серверу.

 

Совет седьмой. HTTPS

 

HTTPS — это протокол, используемый для обеспечения безопасности через Интернет. HTTPS гарантирует пользователям, что они общаются с сервером, который они ожидают, и что никто другой не может перехватывать или изменять контент, который они просматривают при транзите трафика.

 

Если у вас есть что-то, что может потребоваться частным пользователям, очень важно использовать только HTTPS для его доставки. Это страницы с кредитными картами и входами (и URL-адреса, которые они отправляют). Форма входа часто задает, например, файл cookie, который отправляется с каждым другим запросом на ваш сайт, который зарегистрировал пользователь, и используется для аутентификации этих запросов. Взломщик, похищающий это, сможет идеально подражать пользователю и выполнить свой сеанс входа в систему.

 

Это уже не так сложно или дорого, как раньше. Let’s Encrypt предоставляет полностью бесплатные и автоматизированные сертификаты, которые вам необходимо включить на своем хостинге.

 

Совет восьмой. HSTS

 

HTTP Strict Transport Security – это инструмент,который принудительно активирует соединение по протоколу HTTPS. Это по факту заголовок, который заставляет браузер принудительно использовать HTTPS соединение с сайтом. принудительно активирующий защищённое соединение через протокол HTTPS. Вот пример данного заголовка при помощи файла htaccess:

 

Header set Strict-Transport-Security «max-age=31536000» env=HTTPS

 

Совет девятый. Используйте CSP

 

Политика защиты контента (CSP) — это некая прослойка в сфере безопасности, которая позволяет определить определенные виды атак на сайт, особенно она умеет определять атаки вида XSS.

 

Настройка политики безопасности контента включает добавление HTTP-заголовка Content-Security-Policy на веб-страницу и предоставление ему значений для управления ресурсами, которые пользовательский браузер может загрузить для этой страницы. Например, страница, загружающая и отображающая изображения, может разрешать изображения из любого места, но ограничивать действие формы конкретной конечной точкой. Правильно разработанная политика безопасности контента помогает защитить страницу от атаки с использованием межсайтового скриптинга.

 

Мы привели некоторые общие примеры, которые помогут вам настроить данный заголовок.

 

Пример 1

Администратор сайта хочет, чтобы весь контент поступал из собственного источника сайта (это исключает субдомены).

Content-Security-Policy: default-src ‘self’

 

Пример 2.

Администратор сайта хочет разрешить контент из доверенного домена и всех его поддоменов (он не должен быть тем же самым доменом, на котором установлен CSP).

Content-Security-Policy: default-src ‘self’ * .trusted.com

 

Пример 3.

Администратор сайта хочет разрешить пользователям веб-приложения включать изображения из любого источника в свой собственный контент, но ограничивать аудио- или видеоматериалы доверенными поставщиками и все сценарии только для определенного сервера, на котором размещен доверенный код.

 

Content-Security-Policy: default-src ‘self’; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

 

Здесь по умолчанию содержимое разрешено только из источника документа со следующими исключениями:

  • Изображения могут загружаться из любого места (обратите внимание на «*»).
  • Медиа разрешено только с media1.com и media2.com (а не из поддоменов этих сайтов).
  • Исполняемый скрипт разрешен только с usercripts.example.com.

 

Пример 4.

Администратор сайта для сайта онлайн-банкинга должен гарантировать, что весь его контент загружен с использованием SSL, чтобы предотвратить перехватывание запросов злоумышленниками.

 

Content-Security-Policy: default-src https://onlinebanking.myobank.com

 

Сервер разрешает доступ только к документам, загружаемым специально через HTTPS через источник onlinebanking.mybank.com.

 

Пример 5.

Администратор сайта электронной почты хочет разрешить HTML в электронной почте, а также изображения, загруженные из любого места, но не JavaScript или другое потенциально опасное содержимое.

 

Content-Security-Policy: default-src ‘self’ * .mailsite.com; img-src *

 

Обратите внимание, что в этом примере не указан script-src; с примером CSP, этот сайт использует параметр, указанный директивой default-src, а это означает, что скрипты могут быть загружены только с исходного сервера.

 

Тестирование CSP

Чтобы облегчить развертывание, CSP можно развернуть в режиме только для отчетов. Политика не применяется, но любые нарушения сообщаются предоставленному URI. Кроме того, заголовок отчета может использоваться для проверки будущей версии политики без ее фактического развертывания.

 

Вы можете использовать заголовок Content-Security-Policy-Report-Only, чтобы указать свою политику, например:

 

Content-Security-Policy-Report-Only: политика

 

Если в одном ответе присутствуют заголовок Content-Security-Policy-Report-Only и заголовок Content-Security-Policy, обе эти политики соблюдаются. Политика, указанная в заголовках Content-Security-Policy, применяется в то время, когда политика Content-Security-Policy-Report-Only генерирует отчеты, но не применяется.

 

Ниже представлены примеры добавления заголовка CSP на сайт.

 

Конфигурация для сайта из файла PHP

Настройка для сервера Apache (применяйте, только если вы умеете работать с конфигурационным файлом).

И в заключение

Надеемся, что эти советы помогут сохранить безопасность вашего сайта и информации. К счастью, большинство CMS имеют множество встроенных функций безопасности, но по-прежнему полезно знать самые распространенные способы взлома сайта, чтобы вы могли принять все меры по защите своих данных.




В версии 2.0

  • Существенно доработан интерфейс
  • Появилась возможность добавлять фразы
  • Добавлена поддержка "serpstat.com"
  • Добавлена возможность выгрузить слова через запятую
  • Добавлена возможность выгрузить фразы в кавычках
  • Появилась кнопка "Добавить" из буфера обмена, копируйте и вставляйте в расширение ранее собранные списки
  • Добавлена возможность закрепить окно расширения или скрыть его для вашего удобства
  • В analytics.google.com расширение больше не работает

Обновлены комбинации

  • LeftMouseClick для добавления слова, повторное нажатие - для удаления
  • ALT + LeftMouseClick - для сбора фраз