msgbartop
Создание и раскрутка сайтов, продвижение в ТОП
msgbarbottom







24 Июн 13 Что нужно. Организация структуры

Чаще всего уязвимость сайтов связана со слабой проверкой вво­димых пользователем данных. Принципиальным тут является блоки­ровка возможности посетителя вводить вредоносный код. Если такая блокировка отсутствует, то это чревато возможностью злоумышленника захватить контроль над сайтом: сделать дефейс, переписывать и удалять файлы на сайте, оставлять иные следы деятельности. Три типичных случая ввода пользовательских данных — встроенная поисковая систе­ма, разнообразные формы обратной связи (книги отзывов) и загрузка файлов.

Первый случай наименее опасен. При поиске на сайте посетитель вводит текст, но он (если не ведется учет поисковых запросов) никуда не записывается. Поэтому посетитель, введя вредоносный код, факти­чески ничего не может изменить на сайте (конечно, если он не напишет на серверном языке, на котором работает поисковый механизм, функ­цию, удаляющую или видоизменяющую содержимое каких-то файлов, вместе с программными скобками: <? 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

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

Это основные задачи программиста.

Комментарии закрыты.