Безопасность Web-узла

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

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

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

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

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

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

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

Более подробно эти вопросы рассматриваются в далее.

Обеспечение безопасности компьютера, на котором установлен Web-узел

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

Ограничение доступа к информации

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

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

You don't have permission to access /secretdirectory on this server.
(Доступ запрещен
У вас нет прав доступа к каталогу /secretdirectory на этом сервере.)

При настройке Web-сервера Apache это можно сделать с помощью директивы Indexes конфигурационного файла httpd.conf:

Options Indexes // позволяет отображать файлы каталога
Options -Indexes // запрещает отображать файлы каталога

При настройке других Web-серверов следует обратиться к соответствующей документации. Кроме того, не следует присваивать файлам легко угадываемые имена. Например, если в Web-приложении используется файл с пользовательскими паролями, то присваивание ему имени passwords.php окажется далеко не лучшей идеей. Вместо этого такому файлу следует дать непримечательное или обманчивое имя, например vegetableRecipes.php. Можно возразить, что это противоречит правилу присваивания файлам отчетливых имен. Однако данный случай является особенным. Некоторые злоумышленники вводят в браузере URL-адрес www.yoursite.com/password.html и ждут, что из этого получится.

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

Осторожность при получении информации от пользователей

Пользователи могут случайно или злоумышленно ввести в форме опасную (нежелательную) информацию. Поэтому перед ее сохранением или использованием необходимо проверить ее на корректность и отсутствие опасных символов или строк. Введенная информация (даже случайная) может нанести существенный вред сценарию или базе данных. Особенно опасными являются дескрипторы HTML (например, <script>), поскольку их можно использовать для размещения на Web-узле опасных сценариев. Если введенную пользователем информацию принять и сохранить в базе данных без проверки, можно столкнуться с целым ворохом проблем, особенно в том случае, если эту информацию впоследствии будут использовать (и запускать) другие посетители Web-узла. Вопросы проверки данных, вводимых в полях форм, более подробно рассматриваются ниже, в разделе "Проверка данных".

Использование безопасного Web-сервера

Взаимодействие Web-приложения с посетителями нельзя считать абсолютно безопасным. Если находящийся на Web-узле файл передается в клиентскую часть приложения (браузер), то вполне вероятно, что во время передачи данных по Internet кто-то посторонний сможет прочитать содержимое файла. Для большинства Web-узлов это не является проблемой. Но если среди передаваемых данных содержатся номера кредитных карточек или пароли, то вопросы обеспечения их конфиденциальности сразу же выдвигаются на передний план. Уровень защищенности данных можно повысить и при использовании безопасного Web-сервера.

На безопасных Web-серверах для защиты данных часто используется протокол SSL (Secure Sockets Layer). При его использовании информация кодируется и лишь после этого передается через Web. Клиентское программное обеспечение выполняет обратное декодирование. Вне всякого сомнения, развертывание безопасного Web-сервера требует дополнительных усилий, но для некоторых приложений без этого просто не обойтись.

При взаимодействии с использованием протокола SSL URL-адрес начинается с префикса https, а не http.

Каждый Web-сервер можно защитить по-своему. Информацию о том, как включить режим использования защищенного протокола SSL, следует искать в соответствующей документации. Например, при использовании сервера Apache необходимую информацию можно найти на двух Web-узлах: www.modssl.org и www.apache-ssl.org. Если вы решили воспользоваться Web-сервером IIS компании Microsoft, то информацию о протоколе SSL можно найти на Web-узле www.microsoft. com.

Отображение статических Web-страниц

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

Язык РНР можно использовать для отображения любых Web-страниц, в том числе и статических. При этом для вывода HTML-кода можно воспользоваться функцией echo. Если же на странице содержатся только дескрипторы HTML, которые нужно использовать в сценарии РНР, то лучше всего включить определенный файл в требуемое место следующим образом:

include("имя_файла") ;

Если по каким-то причинам статическую Web-страницу понадобилось преобразовать в сценарий РНР, выполните следующее. Добавьте в начало и в конец соответствующего файла дескрипторы РНР (‹?php и ?›), а затем добавьте функцию echo в начале этого файла и заключите весь код HTML в одинарные кавычки.