Есть ли у $ _REQUEST проблемы с безопасностью?

Question

Мой приспешник сейчас изучает PHP,
и он прислал мне свой код PHP,
и я обнаружил, что он использует $ _REQUEST в своем коде.

В учебнике, который я прочитал, написано, что
$ _REQUEST имеет проблемы с безопасностью, поэтому
нам лучше использовать $ _POST.

поэтому я ответил приспешнику, что
нам лучше использовать $ _POST.

Это нормально?

Answer 1

Я бы сказал, что опасно характеризовать $ _POST как более безопасный, чем $ _REQUEST.

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

Короче говоря: Неважно, откуда поступают данные, если они не обрабатываются безопасным образом.

Answer 2

Ну, причина того, что $_REQUEST имеет проблемы, состоит в том, что он выбирает значения из $_GET, $_POST и $_COOKIE, что означает, что если вы кодируете вещи определенным образом и делаете определенные недопустимые доверительные отношения Согласно предположениям клиента, злоумышленник может воспользоваться этим, предоставив значение в другом месте, чем вы ожидали, и переопределив то, которое вы пытаетесь передать.

Это также означает, что вы, возможно, дали неверному указанию своему приспешнику, потому что это могло быть значение GET или COOKIE, которое он брал с $_REQUEST. Вам нужно будет использовать любое место, в котором на самом деле отображается искомое значение, не обязательно $_POST.

Answer 3

Как уже упоминалось в нескольких ответах: Любые данные, поступающие от клиента, не могут быть доверенными и по умолчанию должны рассматриваться как вредоносные . Сюда входят $_POST, $_GET, $_COOKIE и $_REQUEST (комбинация первых), но также и другие.

Говоря о том, что некоторые из них более опасны, чем другие, я действительно выделю $_GET и $_REQUEST (включая $_GET) из $_POST, поскольку генерировать немного сложнее, т.е. манипулировать запросом POST, чем запросом GET . Акцент здесь слегка , но использование POST для чувствительных операций, по крайней мере, удаляет еще один слой низко висящих плодов для использования.

Особенно, когда дело доходит до Межсайтового скриптинга (или XSS) и кражи cookie, довольно просто заставить браузер жертвы выдать GET-запрос на атакуемый сервер, просто вставив скрытое изображение с измененным URL-адресом на странице или подделкой ссылки.

Для выдачи POST-запроса требуется по крайней мере некоторый JavaScript, который немного сложнее ввести в браузер жертвы для выполнения (в зависимости от ситуации). Очевидно, что POST-запросы могут генерироваться непосредственно злоумышленниками, поэтому им также нельзя доверять, но для сценариев, когда злоумышленник использует сторонний браузер, им немного сложнее манипулировать.

Безопасность всегда сводится к тому, чтобы максимально усложнить взлом вашего приложения с учетом ограничений реализации и т. Д. Никогда нельзя быть на 100% безопасным. Поэтому лучше всего выбирать альтернативу, которую труднее использовать, даже если разница незначительна , при выборе между различными подходами реализации.

В конце концов, это всегда удаление низко висящих фруктов. Конечно, POST-запросами также можно манипулировать, но для любой операции с повышенным риском используйте POST-запрос и ограничьтесь использованием $_POST в своем коде. Таким образом, вы уже исключили некоторые очень простые GET-атаки и теперь можете сосредоточиться на проверке данных POST. Только не думайте, что использование POST внезапно сделало операцию безопасной по умолчанию.

Answer 4

Конечно, можно говорить людям, чтобы они использовали $_POST вместо $_REQUEST. Всегда лучше быть более уверенным в том, где вы получаете свои данные.

Answer 5

@ Christian:

Говоря о том, что некоторые из них более опасны, чем другие, я действительно выделю $ _GET и $ _REQUEST (включая $ _GET) из $ _POST, поскольку генерировать, то есть обрабатывать, запрос POST немного сложнее, чем ПОЛУЧИТЬ запрос. Акцент здесь немного, но использование POST для чувствительных операций, по крайней мере, удаляет еще один слой низко висящих плодов для использования.

Bzzt. Извините, но это не правда.

Любой, кто понимает разницу между GET и POST или то, как неантифицированные входные данные могут быть использованы, не колеблясь ни секунды, чтобы запустить Tamper Data.

Некоторые люди понимают это прямо здесь: безопасность при использовании $ _REQUEST в хорошо спроектированной системе НИЧЕГО не теряется и не приобретается.

Answer 6

Нет реальной разницы в безопасности между использованием $_POST и $_REQUEST, вы должны санировать данные с равной тщательностью.

Самая большая проблема с $_REQUEST заключается в том, что вы, возможно, пытаетесь получить данные из формы POST, но у вас может быть параметр GET с тем же именем. Откуда будут поступать данные? Лучше явно запросить данные из того места, где вы ожидаете, $_POST в этом примере

Есть незначительные преимущества безопасности - проще выполнять XSS (точнее, XSRF ) атаки на параметры GET, что возможно, если вы используете $_REQUEST, когда вы действительно просто хочу данные POST ..

Очень мало ситуаций, когда вам нужны данные из POST, GET или cookie. Если вы хотите получить данные POST, используйте $_POST, если вы хотите получить данные из параметров GET, используйте $_GET, если Вы хотите данные cookie, используйте $_COOKIE

Answer 7

Самый безопасный способ - это проверить и подтвердить данные. Я обычно генерирую случайный уникальный идентификатор для формы и сохраняю его в сеансе пользователя, но его легко обходит решительный злоумышленник. Гораздо лучше, чтобы очистить все входящие данные. Проверьте htmlspecialchars () и его функции. Я также использую стороннюю утилиту для кросс-сайта, такую ​​как HTML Purfier

В некоторых практических заметках всегда используйте intval (), который должен быть числовым, экранируйте все входящие строки, используйте регулярное выражение для телефонных номеров, электронных писем или всего, что будет частью SQL-запроса.

Надеюсь, это поможет.