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

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

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

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

Причина, по которой $ _ REQUEST имеет проблемы, заключается в том, что он получает значения из $ _ GET , $ _ POST , и $ _ COOKIE , что означает, что если вы кодируете вещи определенным образом и делаете определенные недопустимые предположения о доверии клиента, злоумышленник может воспользоваться этим, предоставив значение в другом месте, чем вы ожидали, и переопределение того, которое вы пытались передать.

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

Как уже упоминалось в нескольких ответах: Любым данным, исходящим от клиента, нельзя доверять, и они должны рассматриваться как вредоносные по умолчанию . Сюда входят $ _ POST , $ _ GET , $ _ COOKIE и $ _ REQUEST (комбинация первых), а также другие.

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

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

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

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

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

даже если разница незначительна , при выборе между различными подходами к реализации.

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

даже если разница незначительна , при выборе между различными подходами к реализации.

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

используйте запрос POST и ограничьтесь использованием $ _ POST в своем коде. Таким образом, вы уже исключили несколько очень простых атак GET drive-by и теперь можете сосредоточиться на проверке ваших данных POST. Только не думайте, что использование POST внезапно сделало операцию безопасной по умолчанию.

используйте запрос POST и ограничьтесь использованием $ _ POST в своем коде. Таким образом, вы уже исключили несколько очень простых атак GET drive-by и теперь можете сосредоточиться на проверке ваших данных POST. Только не думайте, что использование POST внезапно сделало операцию безопасной по умолчанию.

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

Нет реальной разницы в безопасности между использованием $ _ POST и $ _ REQUEST , вы должны дезинфицировать данные с такой же тщательностью.

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

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

Там очень несколько ситуаций, когда вам нужны данные из POST, GET или cookie .. Если вы хотите получить данные POST, используйте $ _ POST , если вы хотите получить данные из параметров GET, используйте $ _ GET , если вам нужны данные cookie, используйте $ _ COOKIE

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

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

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

@Christian:

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

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

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

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