Атака на Internet

В нашем случае имитируется отправление данных формы методом GET, но для имитации метода POST (пример работы с POST приведен далее) тоже нет серьезных препятствий. С точки зрения безопасности эти методы примерно равнозначны. Некоторое предпочтение можно отдать POST, поскольку GET передает всю информацию непосредственно в URL, что делает ее более доступной для перехвата. Представим ситуацию, когда некоторая форма требует ввода имени и пароля и передает их методом GET. Далее динамически формируется страница, имеющая ссылку на другой сервер. Если посетитель уйдет по этой ссылке, то в качестве Referer в log-файл сервера будет записан тот самый URL, в котором открыто прописаны имя пользователя и его пароль. Опять же GET легче поддается имитации – для его подделки необязательно копировать и модифицировать код формы, достаточно набрать в адресной строке браузера подходящий URL.

В-пятых, ошибочно хранить критичную информацию в открытых для доступа файлах. Можно, конечно, утешать себя мыслью, что адреса файлов еще надо определить, но в любом случае это решение нельзя признать удачным: всегда есть шанс, что из-за плохой конфигурации сервера станет возможным просмотр списка файлов в каталоге и наша информация будет выставлена на всеобщее обозрение; нельзя исключать возможность распространения нашего скрипта – он завоюет популярность, его исходные тексты станут доступными по всей сети, и месторасположение секретных файлов опять-таки перестанет быть тайной. Поэтому файлы с критичной информацией желательно располагать в местах, по возможности вынесенных за пределы дерева каталогов Web-сервера или хотя бы защищенных от чтения (например, при использовании Apache этого можно добиться, разместив в защищаемом каталоге файл. htaccess со строкой deny all внутри).

Источник многих проблем для сайтов с установленными гостевыми книгами (или аналогичными скриптами) – html-тэги. Разрешив пользователю ввод тэгов, вы тем самым провоцируете атаку и на других пользователей, и на сервер. Последнее возможно в случае, если сервер сконфигурирован таким образом, что файлы, создаваемые скриптом, допускают использование SSI (Server Side Includes – директивы включения на стороне сервера). SSI позволяют вставить в html-документ результат выполнения некоторой программы, содержимое другого файла, значение переменной окружения и т. д. Директивы SSI имеют следующий вид:

команда параметр =" аргумент "–>

Например:

Чтобы не допускать к использованию SSI всех посетителей сервера, можно разрешить SSI-директивы только в файлах с определенным расширением (обычно *.shtml), тогда в файлах *.html, создаваемых скриптами, команды SSI будут восприниматься как простой комментарий. Однако подобное решение далеко не всегда устроит разработчика сайта. Следующий способ – полная фильтрация тэгов. Самое простое – заменить все символы «<» и «>» на коды «<» и «>» соответственно:

$string =~ s//>/g;

Другой вариант – удалить все, что находится внутри угловых скобок:

$string =~ s/<([^>]|\n)*>//g;

Опять же не все Web-мастера желают лишать своих посетителей возможности вставки кодов для красивого оформления текста. Тогда последнее, что остается сделать, – фильтровать часть кодов, оставляя лишь самые «безопасные». Это наиболее трудоемкий и потенциально опасный путь: