Что нужно. Организация структуры
Чаще всего уязвимость сайтов связана со слабой проверкой вводимых пользователем данных. Принципиальным тут является блокировка возможности посетителя вводить вредоносный код. Если такая блокировка отсутствует, то это чревато возможностью злоумышленника захватить контроль над сайтом: сделать дефейс, переписывать и удалять файлы на сайте, оставлять иные следы деятельности. Три типичных случая ввода пользовательских данных — встроенная поисковая система, разнообразные формы обратной связи (книги отзывов) и загрузка файлов.
Первый случай наименее опасен. При поиске на сайте посетитель вводит текст, но он (если не ведется учет поисковых запросов) никуда не записывается. Поэтому посетитель, введя вредоносный код, фактически ничего не может изменить на сайте (конечно, если он не напишет на серверном языке, на котором работает поисковый механизм, функцию, удаляющую или видоизменяющую содержимое каких-то файлов, вместе с программными скобками: <? unlink("index. php"); ?>). Простое удаление тэгов из записи (strip_tags()) или преобразование системных символов (htmlspecialchars()) уже предотвращает эту возможность. Целесообразно также провести проверку на наличие недопустимых символов. Допустим, вы хотите позволить посетителям вводить в поисковую строку только русские и латинские буквы, цифры и основные знаки препинания. Проверку клиентским сценарием можно проводить еще на этапе ввода пользователем данных (в поле <input type="text" />, куда вводится поисковый запрос, помещается обработчик onBlur, срабатывающий при переходе фокуса на другое поле, либо onKeyUp — тогда проверка будет проводиться после нажатия каждой клавиши; кроме того, в тэг <form> можно поместить обработчик отправки данных такого формата: onSubmit="return...", где ... — функция проверки корректности введенного значения). К слову, многие пользователи пытаются хитрить, тестируя систему проверки введенных данных, которая не отправляет пустой запрос, и вводят несколько пробелов. Достаточно проверить содержимое поля «на истинность»:
If(document. search form. search item. value == false)
{
А1егМ"Задан пустой поисковый запрос");
}
В этом случае все символы пробельного типа будут игнорированы, и если кроме них в поисковой строке ничего нет, то будет выведено предупреждение о пустом поисковом запросе.
Пользователи, правда, часто отключают работу активных сценариев (а без JavaScript этот пример работать не будет), так что провер-
|
4 |
Программирование |
|
Ку можно проводить дважды. Второй — серверный — случай сработает обязательно, потому что работу серверного сценария рядовой пользователь отключить не в состоянии. Второй случай сложнее: если пользователь оставляет сообщения в книге отзывов, форуме, блоге или чате, посылает письмо разработчику или владельцу средствами сайта, оставляет комментарий на странице, значит, этот текст куда-то записывается. В этом случае существует потенциальная опасность: если в качестве текста записан вредоносный код (а он тоже является текстом), значит, при отображении такой записи код будет выполнен и повредит содержимое сайта. В этом случае проверку на корректность введенных данных нужно проводить трижды (в крайнем случае не менее двух раз): 1. Активным сценарием еще на этапе ввода данных. Если вводится недопустимый символ, он стирается из поля ввода, а автору записи выводится предупреждение средствами браузера. 2. Серверным сценарием перед записью данных в файл или базу данных. Серверная проверка надежнее и мощнее. В этом случае необязательно выводить какие-то предупреждения, достаточно обработать данные и записать то, что осталось от записи. Обработка в этом случае чаще всего сводится к удалению или замене опасных символов (скобок тэгов, кавычек, слэшей). Возможна и параллельная побочная обработка: удаление лишних пробелов, фильтр мата, автоматическое преобразование адресов электронной почты и URL-адресов в ссылки и т. п. 3. Серверным сценарием перед выводом в браузер при формировании страницы, содержащие данные, ранее введенные посетителями. Дело в том, что теоретически можно написать код, который после первичной обработке станет некорректным или вредоносным. Наконец, случай загрузки пользовательских файлов опасен тем, что вместо ожидаемых изображений или файлов звуковых форматов посетитель может загрузить скрипт, который при скачивании или включении в страницу может повредить содержимое. Сценарии, осуществляющие загрузку файлов, позволяют определять размер загружаемого на сервер файла, длину его имени, тип данных, расширение и другие параметры. Таким образом, вполне возможно написать фильтр, который при загрузке «неправильных» с точки зрения обработчика файлов будет выдавать предупреждение, а сами файлы загружать не будет. Алгоритм в этом случае таков: данные о файле передаются сценарию через форму, сценарий анализирует имя файла, его тип и тип данных, размер, и только если все параметры соответствуют допустимым, файл копируется на сервер. В противном случае в браузер выводятся слова сочувствия. |
|
|
274 |
|
4.3 |
В случае с большими сценариями степень потенциальной уязвимости возрастает: чем больше код, тем сложнее протестировать все случаи ошибок и их коррекции. В этом случае часто помогает метод случайного тестирования, когда вводятся самые фантастические, неструктурированные данные и наборы символов, загружаются все мыслимые типы файлов, пока не всплывет какая-либо ошибка.
Это основные задачи программиста.
