Безопасность веб-сайтов. Основы

Автор: | 10.05.2019

Безопасность веб-сайтов и сервисов занимает ключевую позицию при их разработке. Этому следует уделять особое внимание.

Работу с сервером начните с настройки open_basedir (php.ini), ограничивающей набор каталогов, в которых PHP может открывать файлы. Если с помощью этой настройки открыть доступ только к каталогу сайта или к родительскому каталогу данного каталога, хакер не сможет получить доступ к важным системным файлам, находящимся в других каталогах.

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

При использовании общего хоста (shared hosting) рекомендуется изменить папку сеанса. По умолчанию PHP записывает все данные сеанса в общую временную папку, например в папку /tmp в nix-системах. Любой пользователь сервера имеет права чтения и записи по отношению к этой папке, а поскольку услугами общего хоста пользуются десятки пользователей, все они получают возможность чтения хранящихся на этом хосте данных сеанса. Поэтому лучше создать папку с правами записи в области сервера с частым доступом (но только не в папке сайта), чтобы лишь ваш сайт мог использовать сеансы. Либо данные сеанса можно хранить в базе данных.

Дам еще одну рекомендацию по обеспечению безопасности сервера с помощью PHP. Не используйте функции, которые вызывают на выполнение код на сервере, такие как system() и exec(). Также проявляйте осторожность при использовании функций, выполняющих операции с файлами и папками на сервере (создание, открытие, чтение и запись). Если же приходится выполнять какие-либо операции с файлами и папками на сервере, убедитесь в том, что при вызове функций применяются верифицированные данные, а не данные, подставленные пользователем.

Существуют разные виды атак на сайт: XSS, SQL-инъекция, RFI (Remote File Inclusion) — представляет собой попытку со стороны хакера внедрить на сайте файл, находящийся на другом сервере. LFI (Local File Inclusion) — подобна предыдущей атаке. Отличие заключается в том, что в результате выполнения этой атаки важный документ, находящийся на том же сервере, например файл паролей, будет прочитан и отображен.

Чтобы предотвратить атаки RFI и LFI, воспользуйтесь директивой PHP open_basedir. Альтернативный способ предотвращения подобной атаки заключается в изменении названия загруженного файла. Если хакер не знает имени файла, находящегося на сервере, то он не сможет вызывать его на выполнение.

Существует такой вид атаки , как атака межсайтовой подделки запроса (Cross-Site Request Forgery — CSRF). В ходе этой атаки предпринимается попытка вызова не авторизованных команд авторизованным пользователем. Успех подобных атак основан на том, что сайт доверяет пользователям, которые были предварительно аутентифицированы. Например, предположим, что ваш сайт имеет страницу, которая переводит деньги на банковские счета пользователей. С помощью формы выбирается пользователь и сумма перевода.

После ввода данных в форму обрабатывается денежная сумма. Теперь предположим, что некий пользователь, который является администратором сайта, вошел на ваш сайт, был аутентифицирован и выполнил определенные действия. Если он затем не покинул сайт, то в его браузере остается куки-файл, который говорит о том, что он является аутентифицированным пользователем и находится на вашем сайте. Затем он сталкивается с некоторой страницей, на которой хакер идентифицировал сценарий PHP в качестве кода тега <image>:

Это может быть общий форум, страница отзывов или же любой сайт, который обеспечивает пользователям возможность отсылать изображения определенным образом. Как только ваш администратор загружает страницу с тегом <image>, его браузер выполняет запрос сценария add_credits.php, находящегося на вашем сайте, передавая имя пользователя и номера кредитных карт. Этот запрос будет осуществлять поиск сервера, который будет точно таким, как если бы он намеренно перешел на страницу add_scripts.php. Эта страница сначала подтвердит состояние аутентификации пользователя (т.е. вашего администратора), создающего запрос.

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

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

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

Чтобы гарантированно предотвращать атаки CSRF, нужно, чтобы важные запросы, такие как перевод денежных средств, фактически инициировались вашим собственным сайтом. Нельзя использовать «ссылку» в окне браузера, соответствующую ранее посещенной странице, на которой, например, регистрировался администратор. Создайте собственную привязку между формой HTML и страницей, которая обрабатывает запрос. Эта привязка сама по себе будет уникальным секретным токеном, генерируемым для каждого запроса.