Защищаем свой сайт от хакеров: 9 советов по безопасности

Перевод статьи Руалда Гербера, Тоби Комптона и Тима Перри «9 security tips to protect your website from hackers».

Безопасность сайта от хакерских атак

Возможно, вы считаете, что ваш сайт не представляет интереса для хакеров, но атаки на такие «неинтересные» сайты происходят постоянно. Большинство из них не имеют цели украсть ваши данные. Вместо этого злоумышленники пытаются использовать ваш сервер в качестве промежуточного звена для рассылки спама по email или для устройства временного веб-сервера (для обслуживания нелегальных файлов). Другие способы использования скомпрометированных машин – использование ваших серверов в качестве части ботнета или для майнинга криптовалют. Также на ваш сайт может напасть программа-шантажист.

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

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

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

Обновление ПО

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

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

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

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

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

2. Следите за возможным внедрением SQL-кода

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

Обратите внимание на этот запрос:

[code]"SELECT * FROM table WHERE column = ‘" + parameter + "’;"[/code]

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

[code]"SELECT * FROM table WHERE column = » OR ‘1’=’1′;"[/code]

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

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

[code]$stmt = $pdo->prepare(‘SELECT * FROM table WHERE column = :value’);
$stmt->execute(array(‘value’ => $parameter));[/code]

3. Защита от XSS-атак

Комментарии опасны

При межсайтовом скриптинге (Cross-site scripting, XSS) в ваши страницы внедряется зловредный код JavaScript, который затем запускается в браузерах ваших пользователей. Он может изменять содержимое страницы, похищать информацию и отсылать ее тому, кто совершил атаку.

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

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

Эффективным может оказаться не только внедрение JavaScript в HTML, но и внедрение контента, который будет запускать код путем вставки директив Angular или использования хелперов Ember.

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

При динамическом генерировании HTML используйте функции, которые недвусмысленно делают нужные вам изменения. Например, используйте element.setAttribute и element.textContent, которые будут автоматически экранироваться браузером, вместо ручной установки элемента .innerHTML. Или используйте функции вашего инструмента шаблонов, которые автоматически выполняют нужное экранирование, вместо строк конкатенации или установки чистого HTML-контента.

Еще одним мощным инструментом для защиты от XSS является Content Security Policy (CSP). CSP это хедер, который может возвращаться вашим сервером и который сообщит браузеру об ограничениях выполнения JavaScript на этой странице. Например, о запрете запуска любых скриптов не из вашего домена, запрете inline JavaScript или отключении eval(). У Mozilla есть прекрасное руководство с некоторыми примерами конфигураций. Это затруднит работу скриптов нападающего, даже если они попадут на вашу страницу.

4. Относитесь внимательно к сообщениям об ошибках

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

5. Делайте проверку и в бэкенде, и во фронтенде

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

6. Проверяйте пароли

Проверка паролей

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

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

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

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

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

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

Разве что может потребоваться конфигурация дополнительных модулей для использования соли в паролях (Drupal 7) или установки минимального количества символов, при котором пароль считается достаточно сильным.

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

7. Избегайте загрузки файлов

Загрузка файлов небезопасна

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

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

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

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

Есть такие варианты как переименование файла при загрузке для обеспечения правильного расширения файла, или смена прав доступа к файлу, чтобы он не мог быть выполнен, например, chmod 0666. При использовании *nix можно создать файл .htaccess (см. ниже), в котором прописать защиту от двойного расширения (как image.jpg.php).

Защита от двойного расширения файла

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

Если ваши файлы недоступны напрямую, вам нужно создать скрипт для их выбора из приватной папки (или HTTP handler в .NET) и доставки в браузер. Теги изображений поддерживают атрибут src, который не является прямым URL изображения. Поэтому ваш атрибут src может указывать на ваш скрипт доставки файлов, позволяющий установить правильный тип содержимого в HTTP-хедере. Например:

Ваш атрибут src может указывать на ваш скрипт доставки файлов

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

Убедитесь, что у вас установлен файервол и заблокированы ненужные порты. По возможности установите DMZ (Demilitarised Zone), что позволяет ограничить внешний доступ к порту 80 и 443. Но это может быть невозможно, если у вас нет доступа к вашему серверу из внутренней сети, поскольку вам придется открыть порты для разрешения загрузки файлов и удаленно логиниться на ваш сервер по SSH или RDP.

Если вы разрешаете загрузку файлов из интернета, допускайте только безопасные методы передачи, такие как SFTP или SSH.

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

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

8. Используйте HTTPS

Протокол HTTPS

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

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

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

Примечательно, что Google собирается выше ранжировать сайты с HTTPS. Небезопасный HTTP устарел, пора апгрейдиться.

Вы уже используете HTTPS повсюду? Идите дальше: обратите внимание на HTTP Strict Transport Security (HSTS) – простой хедер, который вы можете добавлять к ответам вашего сервера для запрета небезопасного HTTP для всего вашего домена.

9. Используйте инструменты обеспечения безопасности

Инструменты безопасности

Когда вы решите, что уже сделали все возможное для обеспечения безопасности своего сайта, приходит время проверки. Самый эффективный способ для этого – использование некоторых инструментов безопасности сайта, т. н. инструментов тестирования на проникновение (penetration testing или pen testing).

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

Стоит обратить внимание на такие бесплатные инструменты:

  • Netsparker (доступны бесплатный вариант от сообщества и пробная версия). Хорошо подходит для тестирования на SQL injection и XSS.
  • OpenVAS. Претендует на звание самого продвинутого open source сканера безопасности. Хорош для тестирования известных уязвимостей, в настоящее время их в его базе больше 25 тысяч. Но его может быть трудно установить, для этого может потребоваться OpenVAS сервер, а он запускается только на *nix. OpenVAS это форк Nessus, сделанный до того, как последний стал коммерческим продуктом с закрытым кодом.
  • SecurityHeaders.io (бесплатная онлайн-проверка). Инструмент для быстрого уведомления о том, какие хедеры безопасности домена, упомянутые выше (например, CSP и HSTS), включены и правильно настроены.
  • Xenotix XSS Exploit Framework. Инструмент от OWASP (Open Web Application Security Project), включающий огромную выборку примеров XSS-атак. Вы можете запускать его для быстрой проверки уязвимости инпутов вашего сайта в Chrome, Firefox и IE.

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

Можно пойти дальше, попытавшись скомпрометировать сайт вручную с использованием значений POST/GET. Здесь вам может помочь прокси отладки: он позволит вам перехватить значение HTTP-запроса между вашим браузером и сервером. Для начала с этой целью можно воспользоваться бесплатным приложением Fiddler.

Что же стоит попытаться изменить в запросе? Если у вас есть страницы, которые должны быть видны только вошедшим в систему пользователям, вы можете попытаться изменить такие URL-параметры как id пользователя или значения cookie, чтобы попытаться увидеть подробности о другом пользователе. Также стоит протестировать формы, изменяя значения POST, чтобы попытаться отправить код для осуществления XSS или загрузить скрипт на сервер.


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

1 комментарий к “Защищаем свой сайт от хакеров: 9 советов по безопасности”

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх