10 советов по безопасности для защиты вашего сайта от хакеров
Вы можете думать, что ваш сайт не имеет смысла взламывать, однако веб-сайты постоянно находятся под угрозой взлома.
Большинство взломов веб-сайтов не преследует цели украсть ваши данные или нарушить работу сайта. Они направлены на использование вашего сервера для рассылки спама или временного использования веб-сервера для хранения файлов, обычно нелегального содержания.
Взломы постоянно производятся автоматизированными скриптами, написанными специально, чтобы прочёсывать интернет и пытаться взломать сайты, имеющие известные дыры в программном обеспечении.
Вот 10 наших советов, которые помогут вам сохранить ваш сайт в безопасности:
01. Обновляйте программное обеспечение
Это может показаться очевидным, но регулярное обновление программного обеспечения жизненно важно для поддержания безопасности вашего сайта.
Это относится как к операционной системе сервера, так и к любому программному обеспечению, которое используется на вашем сайте, такому как CMS или форум. Когда обнаруживаются дыры в безопасности программного обеспечения, хакеры быстро пытаются воспользоваться этим.
Если ваш сайт располагается на хостинге, тогда вам не стоит беспокоиться о своевременной установке обновлений для операционной системы, так как хостинговая компания должна заботиться об этом самостоятельно.
Если вы используете программное обеспечение сторонних производителей на вашем сайте, вроде CMS или форума, убедитесь, что вы устанавливаете обновления системы сразу после их выхода.
Большинство производителей ПО имеют рассылку или RSS канал с описанием проблем безопасности веб-сайтов. WordPress, Umbraco и многие другие CMS уведомляют вас о доступных обновлениях при входе в административную часть сайта.
02. SQL-инъекции
При атаке посредством SQL-инъекции атакующий использует поле веб-формы или параметр URL, чтобы получить доступ к вашей базе данных или манипулировать данными.
Когда вы используете стандартный Transact SQL, то возможно незаметно вставить мошеннический код в ваш запрос так, что он может быть использован для изменения таблиц, получения информации или удаления данных.
Вы можете легко предотвратить это, всегда используя параметризированные запросы.
Большинство языков веб разработки поддерживают эту возможность.
Рассмотрим запрос:
"SELECT * FROM table WHERE column = '" + parameter + "';"Если злоумышленник изменит параметр URL на ‘ or ‘1’=’1, это приведёт к тому, что запрос примет следующий вид:
"SELECT * FROM table WHERE column = '' OR '1'='1';"Так как ‘1’ равен ‘1’, атакующий получит доступ ко всем данным таблицы. Также это позволит ему добавить дополнительный запрос в конец выражения SQL, который будет выполнен наряду с исходным.
03. XSS
Межсайтовый скриптинг заключается в том, что атакующий пытается передать JavaScript или какой-либо другой код в веб-форму, чтобы выполнить вредоносный код на вашем веб-сайте.
При создании формы всегда проверяйте данные, которые к вам приходят от пользователей, и кодируйте или маскируйте любые спецсимволы.
04. Сообщения об ошибке
Будьте осторожны с количеством информации, которое вы выдаёте в ваших сообщениях об ошибке. Например, если у вас есть форма для входа на ваш веб-сайт, вы должны обдумать сообщение, которое вы выдадите пользователю в случае неудачной попытки авторизации.
Вы должны использовать общие фразы, вроде «Неправильное имя пользователя или пароль», и не указывать, в чём именно пользователь ошибся.
Если злоумышленник пытается подобрать имя пользователя и пароль, а сообщение об ошибке выдаёт, что одно из полей было верным, тогда он может сконцентрироваться на оставшемся поле, что упрощает его задачу:
05. Проверка форм на стороне сервера
Проверка форм всегда должна производиться как на стороне браузера, так и на стороне сервера. Браузер может проверить простые ошибки, вроде незаполненного обязательного поля или текста, введённого в поле, требующее ввода числа.
Однако эти проверки могут быть обойдены, и вы должны проверять эти условия также и на стороне сервера. Отсутствие подобной проверки может привести к вставке вредоносного кода в вашу базу данных или нежелательным результатам работы веб-сайта.
06. Пароли
Все знают, что нужно использовать сложные пароли, но это не значит, что люди всегда так делают. Критически важно использовать сложные пароли к вашему серверу и блоку администрирования веб-сайта, но не менее важно требовать от ваших пользователей использования сложных паролей к их аккаунтам.
Несмотря на то, что пользователи этого не любят, принудительные требования к паролям, такие как минимальная длина не менее восьми символов, включение в состав пароля символов в верхнем регистре или цифр, поможет им, в конечном счёте, сохранить их информацию.
Пароли всегда должны храниться в зашифрованном виде, лучше всего с использованием алгоритма одностороннего хэширования, например SHA. При использовании этого метода для авторизации пользователей вы просто сравниваете зашифрованные значения.
Для дополнительной защиты можно использовать «соль» для паролей, при этом добавляя новую «соль» к каждому паролю.
В случае если веб-сайт будет взломан и злоумышленник получит данные с паролями, хранение хэшированных паролей поможет снизить ущерб, т.к. потребуется их дешифрование. Лучшее, что может сделать злоумышленник в этом случае – это атака по словарю или атака перебором, то есть проверка всех возможных комбинаций, пока не будет найдено совпадение.
При использовании «соли» в паролях, процесс взлома большого количества паролей становится ещё медленнее, т.к. каждый вариант должен быть хэширован отдельно для всех комбинаций пароль + «соль», что требует больших вычислительных затрат.
К счастью, большинство CMS предоставляют инструменты управления пользователями со многими встроенными системами безопасности, хотя для использования «соли» или установки минимальной сложности пароля может потребоваться некоторая альтернативная настройка или дополнительные модули.
Если вы используете .NET, тогда стоит использовать провайдеры членства, т.к. они имеют множество настроек, предоставляют встроенную систему безопасности и включают в себя готовые элементы для входа в систему и изменения пароля.
07. Загрузки файлов
Предоставление пользователям возможности загружать файлы на ваш веб-сайт может быть связано с большим риском в плане безопасности, даже если речь идёт просто о смене аватара. Риск состоит в том, что любой загруженный файл, как бы безобидно он ни выглядел, может содержать скрипт, который при выполнении на вашем сервере открывает доступ к вашему сайту.
Если у вас на сайте есть форма загрузки файла, тогда вам нужно относиться ко всем загружаемым файлам с подозрением. Если вы позволяете пользователям загружать изображения, то при определении типа файла, вы не можете полагаться на расширение или mime-тип, так как они легко могут быть подделаны.
Даже открытие файла и чтение его заголовка или использование функций проверки размера изображения не являются стопроцентной гарантией безопасности. Большинство форматов изображений позволяют хранить комментарии, которые также могут содержать код PHP, который может быть выполнен на сервере.
Так что же вы можете сделать, чтобы предотвратить это? Обычно вам нужно запретить исполнение загружаемых файлов пользователями.
По умолчанию веб серверы не пытаются выполнять файлы с расширениями изображений, но не рекомендуется полагаться исключительно на расширение файла, так как известны случаи, когда файл «image.jpg.php» обходил эту проверку.
Вот некоторые варианты решения проблемы: переименование файла при загрузке, чтобы удостовериться в корректности разрешения; изменение разрешений для файла, например на chmod 0666, чтобы он не мог быть выполнен.
В *nix системах вы можете создать файл .htaccess (смотрите пример ниже), который откроет доступ только к заданному множеству файлов, что исключит возможность атаки с двойным расширением, упомянутой ранее:
deny from all
order deny,allow
allow from allОднако, рекомендуемое решение – полностью исключить прямой доступ к загружаемым файлам. При этом любые файлы, загружаемые на ваш веб-сайт, хранятся в папке вне корня сайта или в базе данных как большие двоичные объекты (BLOB).
Если ваши файлы недоступны напрямую, вам потребуется создать скрипт (или обработчик HTTP в .NET), чтобы извлекать их из закрытой папки и выдавать браузеру.
Тэги img поддерживают атрибут src, который в данном случае не будет являться прямым URL-адресом изображения, а будет указывать на скрипт извлечения файла. Также не забудьте указать в скрипте корректный HTTP заголовок content-type.
Например:
<img src="/imageDelivery.php?id=1234" />
<?php
// imageDelivery.php
// Извлечение имени файла из БД соответственно $_GET["id"]
...
// Выдача изображения браузеру
Header('Content-Type: image/gif');
readfile('images/'.$fileName);
?>Большинство хостинг провайдеров производит необходимые настройки сервера за вас, но если ваш веб-сайт работает на вашем собственном сервере, тогда есть ещё несколько вещей, которые вам нужно проверить.
Убедитесь, что у вас настроен межсетевой экран, и он блокирует несущественные порты. Если это возможно, настройте DMZ (демилитаризованную зону), открыв доступ из внешнего мира только к портам 80 и 443. Хотя, это может быть невозможно, если вы не имеете доступа к вашему серверу из локальной сети, так как в этом случае вам придётся открыть порты, позволяющие загружать файлы и удалённо управлять вашим сервером через SSH или RDP.
Если вы позволяете загрузку файлов из интернета, используйте защищённые методы передачи, такие как SFTP или SSH.
Если это возможно, выделите отдельный сервер под базу данных, отличный от веб-сервера.При этом сервер базы данных не будет напрямую доступен из внешнего мира, только ваш веб сервер сможет получить доступ к нему, тем самым минимизируя риск кражи ваших данных.
Наконец, не забудьте ограничить физический доступ к вашему серверу.
09.SSL
SSL – это протокол, использующийся для обеспечения безопасности при передаче данных по сети интернет. Это хорошая идея использовать сертификат безопасности каждый раз, когда вы передаёте персональную информацию между клиентом и веб сервером или базой данных.
Злоумышленники могут прослушивать канал связи и, если он не безопасен, перехватить пересылаемую информацию и использовать её для получения доступа к аккаунтам и персональной информации пользователей:
10. Инструменты проверки веб-сайтов
Когда вы уже думаете, что сделали всё возможное, настало время протестировать систему безопасности вашего сайта. Наиболее эффективный способ сделать это – использовать инструменты проверки сайтов, также известные как тесты на проникновение или pen-тесты.
Для этого существует множество коммерческих и бесплатных продуктов. Они работают по схожей со скриптами хакеров схеме, используя все известные эксплойты и пытаясь взломать ваш сайт одним из описанных выше способов, например, при помощи SQL-инъекции.
Вот некоторые бесплатные инструменты:
- Netsparker (доступна бесплатная пробная версия). Подходит для тестирования на SQL-инъекции и XSS
- OpenVAS. Позиционирует себя как наиболее совершенный сканер системы безопасности с открытым кодом. Подходит для тестирования на известные уязвимости, на данный момент проверяет более 25000.
Но он сложен для установки и требует наличия сервера OpenVAS, который работает только под *nix.
OpenVAS – это разновидность системы Nessus до того, как последняя стала коммерческим продуктом.
Результаты автоматизированных тестов могут быть пугающими, так как они показывают все разновидности потенциальных угроз. Важным моментом является работа в первую очередь над критическими замечаниями.
К каждой выявленной проблеме прилагается хорошее объяснение потенциальной угрозы безопасности. Вы, скорее всего, решите, что некоторые средне- и малоопасные уязвимости не представляют угрозы для вашего сайта.
Если вы хотите пойти дальше, тогда есть и ещё некоторые действия, которые вы можете предпринять, попытавшись вручную взломать ваш сайт, изменяя значения POST/GET запросов.
Здесь вам может помочь debugging proxy (прокси-сервер отладки), так как он позволяет вам перехватывать значения HTTP запросов на участке между вашим браузером и сервером. Популярное бесплатное приложение, которое называется Fiddler, подойдёт для начала.
Так что же вам стоит попробовать изменить в запросе? Если у вас есть страницы, которые должны быть доступны только авторизованным пользователям, тогда я бы попробовал изменить параметры URL, такие как ID пользователя или значения cookie, чтобы попытаться выдать себя за другого пользователя.
Другая возможная область тестирования – формы. Изменяйте значения POST, чтобы попробовать отправить межсайтовый запрос или загрузить серверный скрипт:
Мы надеемся, что наши советы помогут вам содержать сайт и информацию на нём в безопасности.
К счастью, многие CMS имеют достаточно встроенных инструментов защиты, но всё равно неплохо знать о наиболее популярных угрозах безопасности, чтобы быть уверенным, что вы от них застрахованы.
Также существуют некоторые полезные модули CMS для проверки вашей системы на наиболее частые уязвимости.
Среди них Security Review для Drupal и WP Security Scan для WordPress.
Перевод статьи «10 security tips to protect your website from hackers» был подготовлен дружной командой проекта Сайтостроение от А до Я.
