Насколько злым является $ _REQUEST и какие допустимые меры противодействия?

Question

Недавно я наткнулся на пару популярных ответов, связанных с PHP, в которых предлагалось использовать суперглобальный $_REQUEST, который я считаю запахом кода, потому что он напоминает мне register_globals.

Можете ли вы дать хорошее объяснение / доказательство того, почему $_REQUEST является плохой практикой? Я приведу пару примеров, которые я выкопал, и мне бы хотелось больше информации / перспективы как о теоретических векторах атак, так и о реальных эксплойтах, а также предложения разумных шагов, которые может предпринять системный администратор для снижения риска (если не считать переписываете приложение ... или нам нужно , чтобы перейти к руководству и настаивать на переписывании?).

Пример уязвимостей: По умолчанию GPC порядок слияния массивов означает, что значения COOKIE переопределяют GET и POST, поэтому $_REQUEST можно использовать для атак XSS и HTTP. PHP позволяет файлам cookie перезаписывать суперглобальные массивы. Первые 10 слайдов из этого доклада приводят примеры (весь доклад великолепен). phpMyAdmin эксплойт пример атаки CSRF.

Пример контрмер: Переконфигурировать $_REQUEST порядок слияния массива от GPC до CGP, поэтому GET / POST перезаписывает COOKIE, а не наоборот. Используйте Suhosin , чтобы заблокировать перезапись суперглобальных элементов.

(Кроме того, я бы не спрашивал, думал ли я, что мой вопрос был обманом, но, к счастью, подавляющий SO-ответ на "Когда и почему следует использовать $ _REQUEST вместо $ _GET / $ _POST / $ _COOKIE? " было" Никогда. ")

Answer 1

Просто обработайте это как есть: метод получения данных от пользователя. Он должен быть подвергнут санитарной обработке и проверке, так почему вас это должно волновать, если он имеет форму POST, GET или cookie? Все они получены от пользователя, поэтому они говорят, что могут быть подделаны! лишнее.

Answer 2

$_REQUEST проблематично, поскольку игнорирует разницу между URL ($_GET) и телом запроса ($_POST). Запрос HTTP-GET должен быть без побочных эффектов, тогда как HTTP-POST может иметь побочные эффекты и поэтому не может быть кэширован. Бросая эти совершенно разные источники данных в одно ведро, вызываются приложения, которые не * REST -фул, то есть плохие приложения.

Answer 3

$ _ REQUEST - это зло как $ _GET, $ _POST и $ _COOKIE. Хотя я думаю, что есть допустимые сценарии использования $ _REQUEST, но есть одна веская причина не использовать $ _REQUEST и пометить его как «плохую практику».

Основная причина использования $ _REQUEST заключается в том, что параметр может быть передан в $ _POST или $ _GET. Получая доступ к $ _REQUEST, вам не нужно проверять как $ _GET, так и $ _POST, если значение установлено. Проблема в том, что установка ini gpc_order может изменить поведение сборки $ _REQUEST. Этот параметр может отличаться для разных серверов, и ваш сценарий может изменить поведение.

Answer 4

Его уязвимо для всего, что передается по URL. Таким образом, если форма содержала скрытое поле с «идентификатором пользователя», которое было отправлено вместе с формой, хотя в теории пользователь не может редактировать ее, ничто не мешает им изменить значение, если оно достаточно.

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