конструктивные просчеты

ЕКАТЕРИНА СЕДОВА

Спецвыпуск: Хакер, номер #067, стр. 067-056-1

(ПРОГРАММИСТ DEFA GRUPPE)

PHP-БАГИ

ХАЛАТНОСТЬ И НЕВНИМАТЕЛЬНОСТЬ — ВОТ ОСНОВНЫЕ ПРИЧИНЫ УЯЗВИМОСТИ КОДА ПЕРЕД ЗЛОУМЫШЛЕННИКАМИ. ДЕЙСТВИТЕЛЬНО, АБСОЛЮТНОЕ БОЛЬШИНСТВО PHP-ПРОГРАММИСТОВ, ПРОЕКТИРУЯ ИНТЕРАКТИВНЫЕ САЙТЫ, СЛЕДЯТ ЗА ИХ КОРРЕКТНОЙ РАБОТОЙ ТОЛЬКО В ИДЕАЛЬНЫХ УСЛОВИЯХ, ТО ЕСТЬ ПРИ «ИДЕАЛЬНЫХ» ДАННЫХ, ВВОДИМЫХ ПОЛЬЗОВАТЕЛЯМИ, И УМУДРЯЮТСЯ ЗАБЫВАТЬ О БЕЗОПАСНОСТИ ТОНКИХ МОМЕНТОВ КОДА

Поговорим о вещах, которые, как правило, программисты знают, но по каким-то причинам оставляют без внимания.

стандартные ошибки

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

[первое правило,] которым должен руководствоваться любой PHP-программер, — обязательная двусторонняя проверка данных, вводимых пользователем. На стороне клиента (посредством js) и на стороне сервера (PHP), что совсем не избыточно. Если речь идет о безопасности, лишним не бывает ничего. Для проверки данных на клиентской стороне отлично подходит распространенная сейчас js-библиотека fValidate (доступна по адресу http://web.archive.org/web/20041111044016/www.peterbailey.net/fValidate). Она элементарно встраивается в код, легко дописывается, позволяет гибко описывать форматы вводимых данных и определять произвольные посредством регулярных выражений. Просто клад для PHP’шника, если он не хочет тратить время на написание клиентской проверки и сосредотачивается на серверной.

[серверная часть] web-приложения уязвима таким до жути популярным видам атак, как SQL- и PHP-инъекции, которые возникают из-за недостаточной проверки и обработки данных, передаваемых от пользователя.

[SQL-инъекция] позволяет модифицировать SQL-запросы скрипта к базе данных, с которой он взаимодействует, либо выполнять запросы, не предвиденные кодом. Уязвимость сайта такому виду атаки проверяется просто: в поле формы или в адресную строку вводится кавычка (одинарная или двойная). В результате такой атаки на уязвимый сайт появится детальное сообщение об ошибке, что откроет атакующему информацию о технологии, используемой на сайте, и о том месте в коде, где произошла ошибка. Любой злодей легко догадается, как поломать дальше, больше и вредоноснее.

пример SQL-инъекции

Допустим, в БД есть таблица новостей (статей, вакансий) стандартного вида: ID (уникальный идентификатор) и поля заголовка, анонса и текста.

Запрос формируется уникальным ID конкретной новости, который передается скрипту методом GET, к примеру, так:

http://test.test/news.php?id=1

Текст самого запроса в скрипте при этом выглядит вот так:

$query="SELECT `title`, `text` FROM `news` WHERE `id`=” . $_GET["id"];

Злоумышленник, конечно, еще не знает об этом, но благодаря нескольким последовательным запросам быстро выяснит. Такие уязвимости позволяют модифицировать запрос в части параметра WHERE. Когда злоумышленник обнаружит дыру, он сразу же бросится выяснять, какое количество полей используется в запросе. Для этого задают неверный ID’шник (чтобы исключить вывод реальной информации из базы) и объединяют его через UNION с запросом, содержащим одинаковое количество пустых полей: