Обеспечение безопасности сайта при разработке

Уровень сложности: 

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

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

1. Выбор надёжных средств проектирования, или надёжной CMS

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

  • обсуждения в Интернете случаев взлома,
  • статистика взломов различных CMS из достоверных источников, например, https://blog.sucuri.net/,
  • частота обновлений CMS и отчёты на официальных сайтах о перекрытии уязвимостей,
  • наличие подробных гидов по обеспечению защиты CMS.

Для примера на официальном сайте CMS Drupal существует раздел отчётов о безопасности и обновлениях безопасности https://www.drupal.org/security. Для WordPress также существует множество гидов, например: http://codex.wordpress.org/Hardening_WordPress. Что-то об этом сказано и на сайте Joomla! : https://docs.joomla.org/Security_Checklist/You_have_been_hacked_or_defaced

Какая CMS безопасна?

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

При использовании готовой CMS для управления безопасностью желательно:

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

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

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

Управлять обновлениями CMS. Локальный сайт - самый безопасный. Обновления зачастую могут привести к заражениям, и это может происходить разными путями: перехватом соединений с удалённым сервером, взлом главного сервера, хакерской активностью в пределах хостинга, на котором размещён сайт. Поэтому процесс обновления должен быть отключаемым и при необходимости производиться в ручном режиме.

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

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

Как создавать безопасный сайт?

Проектирование собственной системы или доработка функций готовой CMS должны удовлетворять требованиям:

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

Разграничение уровней доступа пользователей. Роли - это выделяемые пользователям наборы возможностей, разрешений. Каждому пользователю изначально должны предоставляться максимально ограниченные возможности, то есть для роли "неавторизованный посетитель" может выделяться только возможность просмотра материалов, подписки на новости и, возможно, регистрация на сайте, комментарии. Для роли "зарегистрированный пользователь" могут предоставляться права обращения за поддержкой, создание тикетов, публикации на сайте материалов с модерацией, изменение имени, восстановление пароля и т.д. Функция разграничения прав - это базовая функция, реализуемая на многопользовательских проектах. Без неё невозможна разработка многопользовательских Интернет-сайтов.

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

Проверка пользовательского ввода. Это базовый принцип программирования. Ошибки в кодах программ при работе с данными, введёнными пользователем, могут ломать не только функцию, но и базу данных, файлы, приводить не только к некорректной обработке данных, но и к поломке всей системы. Проверка ввода должна не только исключать ошибки набора (неправильный формат телефона, емайл), также должна исключать возможность инъекций - то есть кодов, которые могут быть интерпретированы и исполнены как команды, например sql-инъекции, shell-инъекции.

Защита от ботов. Ограничение активности ботов призвано предотвратить подбор паролей, тестирование инъекций.

Права на файлы и папки Linux. Для большинства хостингов права на папки выставляются 755, на файлы - 644. Для папки временных файлов и загружаемых пользовательских файлов, возможно предоставление права записи 775 или даже 777. Желательно при этом обеспечить защиту с помощью .htacccess внутри этой папки.

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

Сокрытие структуры CMS, её фалов и папок. Это означает, что при обращении к папке сайта, в которой нет index.html, не должен выводиться список файлов папок, также при отображении ошибок сайта не желательно показывать эти ошибки анонимным пользователям, которые могут увидеть пути сайта и адреса файлов скриптов.

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

Ограничение потребляемых ресурсов. При обработке ошибок 404 нужно ограничить потребляемые ресурсы: например, создать статичную страницу 404.html. Также при атаках DDOS нужно отлавливать возможные ошибки и ограничивать работу сайта или его функций. Часто при переполнении памяти сервера (при атаках DDOS) функции сайта могут давать сбои, которые могут открыть хакеру важную информацию о конфигурации сервера, системы CMS.

Настройки безопасности сервера. Некоторые ошибки в работе сервера (apache, nginx) или ошибки в .htaccess могут приводить к тому, что все исполняемые файлы не исполняются, а отображаются как текст. В таком случае хакер может прочитать файл настроек и узнать пароли баз данных, возможно, администратора сайта, также ftp.

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

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

Другие рекомендации читайте в рубрике Безопасность или в предложенных темах под статьёй.