Октябрь 27, 2005

Приемы безопасного веб-программирования на PHP

Данная статья не претендует на роль всеобъемлющего руководства на тему "как сделать так, чтоб меня никто не поломал".

Единственная цель этой статьи - показать некоторые используемые мной приемы для защиты веб-приложений типа WWW-чатов, гостевых книг, веб-форумов и других приложений подобного рода. Итак, давайте рассмотрим некоторые приемы программирования на примере некоей гостевой книги, написанной на PHP.

Первой заповедью веб-программиста, желающего написать более-менее защищенное веб-приложение, должно стать "Никогда не верь данным, присылаемым тебе пользователем". Пользователи - это по определению такие злобные хакеры, которые только и ищут момента, как бы напихать в формы ввода всякую дрянь типа PHP, JavaScript, SSI, вызовов своих жутко хакерских скриптов и тому подобных ужасных вещей. Поэтому первое, что необходимо сделать - это жесточайшим образом отфильтровать все данные, присланные пользователем.

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

<input type=text name=username maxlength=20>

На роль настоящей защиты, конечно, это претендовать не может - единственное назначение этого элемента - ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength, установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER:

<?
$referer=getenv("HTTP_REFERER");
if (!ereg("^http://www.myserver.com")) {
echo "hacker? he-he...\n";
exit;
}
?>

Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, хацкеру будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа. В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита годится только от Ну Совсем Необразованных хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут - то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его ото всюду, откуда это возможно. Времени на обращение к переменной уходит немного - а береженого Бог бережет.

продолжение следует...

Разместил:

Автор:

20:13 « предыдущая | следующая » Статьи

Комментарии

1. 28.10.05 02:13 От: Арсен Кириллов

С реферер - перебор. Это не метод защиты, хотя бы потому, что тем же curl'ом обходится в три строки. Конечно, класно про него вспомнить - но все же. Еще бы рекомендовл обратить внимание на php.net. Там в начале года проходила довольно резкая статья по поводу безопасности и ошибок в php-enjine.

http://softm.h1.ru/

2. 28.10.05 15:11 От: MiRacLe

Небольшое отступление:

вот из-за таких "недалёких" советчиков и пишут направо и налево "кривые" приложения....

А о том что referer может банально "резаться" различными локальными файрволами, корпоративными прокси и т.п. сетевыми фильтрами автор не знал ?

И все пользователи, установившие у себя Norton Какой-то-там Firewall просто идут лесом, затем полем и в конце концов забывают о сайте на который его не пустил "крайне умный" разработчик.

Теперь о главном - referer надо проверять только в том случае если он ЕСТЬ! не надо так же забывать о том что в большинстве случаев www.domain.tld и domain.tld это один и тот же ресурс и в зависимости от настроек сервера форма отправленная с domain.tld может попадать в обработку на www.domain.tld (или наоборот) соответственно проверка любезно опубликованная автором опять-таки огорчит потенциального писателя опуса в гостевой книге сообщением о том что он hacker.....

Итог - прежде чем нажимать на кнопку "Опубликовать" автору рекомендуется попить чаю. Если после этого снова возникнет желание поучать других - повторить историю с чаем....

3. 29.10.05 17:45 От: in

Согласен с MiRacLe. Это не защита! Это видимость и самоуспокоение. Тут недавно закончилась Zend/PHP Conference 2005. Там были очень серьезные доклады по защите. Жалко, из России там был только один человек (насколько мне известно). Дождемся, когда он напишет эссе по материалам данной конференции: http://www.phpworld.ru/

Ваш комментарий

Обсудить на форуме?

Подумайте, прежде чем высказать своё мнение. Постарайтесь сделать свой комментарий полезным для других. Не используйте ненормативную лексику. Пользователи, пишущие "от нечего делать" бессмысленные наборы символов, будут блокироваться навсегда.