«Не доверяйте своим пользователям. Они могут навредить Вам.»
Дэйв Чайлд

Дэйв Чайлд (Dave Child) стоит за недавно переименованным Added Bytes (ранее ilovejackdaniels.com, сейчас www.addedbytes.com) — сайтом, где приводятся написанные Дэйвом шпаргалки по многим языкам программирования. Он работал на многие компании в Великобритании и добился признания в мире программирования.

«Итак, главное правило веб-разработки: никогда, ни при каких обстоятельствах не доверяй своим пользователям. Предполагай, что любые данные, которые сайт получает от пользователя, содержат вредоносный код. Всегда. Включая и данные, которые ты проверил на стороне клиента, например, с помощью JavaScript. Если ты сможешь этим руководствоваться, это станет залогом твоего успеха. Если безопасность в PHP важна для тебя, этот единственный пунктик самый важный для усвоения.»

Теперь разберем все возможные данные передающиеся от пользователя в контексте PHP, а точнее глобальные массивы $_GET, $_POST, $_COOKIE, $_SERVER, $_SESSION и $_ENV.

Дада! $_SERVER, $_SESSION и $_ENV — тоже не безопасны!

PS: статья — НЕ перевод, как может показаться из вступления. Я привел лишь очень удачную цитату. А сама статья — это описание моей личной точки зрения.

Почему нельзя доверять GET, POST, COOKIE?

Я думаю это самый банальный пункт, и уже любой мало-мальский программист знает что за этими данными нужно следить как нельзя сильно. Все очень просто.

Хакер, может изменить строку URL так как ему захочется (GET), сможет передать любые данные в содержимом пакета (POST), сможет модифицировать куки или добавить свои куки. И если ваш скрипт будет готов «к необычным данным», то вы защищены, а если нет… То вы даете шанс хакеру взломать ваше приложение. Будьте бдительны!

Бьюсь об заклад 95% уязвимостей php-приложений, берут начало от неправильного подхода к фильтрации этих данных.

P.S.: не забывайте проверять помимо содержимого, еще и тип переменных. К примеру в вашем приложении ожидается строка, а хакер может передать массив, что вызовет ошибку типа Warning, и если у вас не отключен вывод ошибок, то хакер сможет узнать некоторую информацию, которую ему возможно не следовало бы знать.

Почему нельзя доверять массиву $_SERVER?

Нельзя доверять данным начинающимся с префикса HTTP_. Почему? Да потому что эти данные тоже можно модифицировать. Напомню, все значения начинающиеся с префикса HTTP_ — значения заголовков пакета, которые, напомню, сам пользователь генерирует и передает.

Теперь о самых часто используемых параметрах:

• HTTP_USER_AGENT — Содержит информацию о браузере пользователя. Очень часто разработчики не фильтруют этот параметр занося его в БД, что приводит к уязвимостям от XSS до SQL-injection
• HTTP_REFERER — Содержит информацию о странице с которой пришел пользователь. Тоже самое что и предыдующий параметр.
• HTTP_X_FORWARDED_FOR — Содержит информацию о реальном IP пользователя если тот использует прокси. К сожалению разработчики забывают, что он может содержать ЛЮБОЕ значение, даже близко не похожее на IP адрес. Но даже если програмист фильтрует это значение, то возможно он забывает что здесь может передаваться любой IP адрес. То есть если у вас предусмотренна система привязки доступа по IP, то хакер может подделать этот параметр чтобы передать в нем IP адрес администратора.

Вообщем не забываем что некоторую информацию в массиве $_SERVER все же передает пользователь. И ее необходимо фильтровать!

Почему нельзя доверять массиву $_SESSION?

Вот казалось бы, да? А вот сессии тоже оказывается можно модифицировать вне нашего ведома.

Не так давно я наткнулся на интересную статью от некоего Dr.Z3r0 Новый метод атаки через reverse-ip

Если в кратце, то… Если ваш сайт расположен на хостинге с множеством других сайтов, то злоумышленник может взломать один из соседних сайтов, или официально купить хостинг на одном с вами сервере. Это, при определенной настройке сервера, позволит ему попасть в папку где PHP хранит файлы с сессиями, и сгенерировать, свою, нужную ему сессию с нужными ему данными.

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

Почему нельзя доверять массиву $_ENV?

Представим предыдущую ситуацию:

Если ваш сайт расположен на хостинге с множеством других сайтов, то злоумышленник может взломать один из соседних сайтов, или официально купить хостинг на одном с вами сервере.

Если ваш веб сервер поддерживает keep-alive соединения, то есть позволяет запросить несколько страниц за одно подключение, то атака будет выглядеть так:

Хакер может создать такой веб скрипт на вашем сервере (пусть и в папке с другим сайтом) который бы создавал свою переменную окружения. И с помощью keep-alive подключения, за одно соединение запросил бы две страницы, сначала свою (которая бы модифицировала имеющиеся или создавала новые переменные окружения) и затем сразу же вашу.

И если вы не предусмотрели фильтрации переменных окружения, то ваша страница (если она использует эти переменные) может отработать не так как надо вам, а так как надо хакеру, что может привести к печальным последствиям.