Что не так с использованием $ _REQUEST []?

Я видел здесь несколько сообщений, в которых говорилось, что нельзя использовать $_REQUESTпеременную. Обычно я этого не делаю, но иногда это удобно. Что с этим не так?

Там абсолютно ничего плохого с принятием вход от обоих $_GETи $_POSTкомбинированным способом. Фактически, это то, что вы почти всегда хотите делать:

• для простого идемпотентного запроса, обычно отправляемого через GET, существует вероятность того, что объем данных, который вы хотите, не поместится в URL-адрес, поэтому на практике он был преобразован в запрос POST.

• для запроса, который имеет реальный эффект, вы должны проверить, что он отправлен методом POST. Но способ сделать это - проверить $_SERVER['REQUEST_METHOD']явно, а не полагаться на $_POSTпустоту для GET. И в любом случае, если метод есть POST, вы все равно можете извлечь некоторые параметры запроса из URL-адреса.

Нет, проблема $_REQUESTне в объединении параметров GET и POST. Дело в том, что он также по умолчанию включает$_COOKIE . А файлы cookie на самом деле совсем не похожи на параметры отправки формы: вы почти никогда не захотите рассматривать их как одно и то же.

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

Вы можете изменить это поведение на гораздо более разумный GP(нет C) порядок с конфигурацией request_order в PHP 5.3. Там, где это невозможно, я бы лично избегал $_REQUESTи, если бы мне понадобился комбинированный массив GET + POST, создавал бы его вручную.

Я покопался в некоторых сообщениях групп новостей о PHP Internals и нашел интересное обсуждение этой темы. Исходная нить шла о чем - то другом, но замечание Стефан Эссер, а (если не ) эксперт по вопросам безопасности в PHP мире превратили дискуссию в сторону последствия для безопасности использования $ _REQUEST на несколько постов.

Цитирование Стефана Эссера о внутреннем устройстве PHP

$ _REQUEST - одна из самых слабых сторон дизайна PHP. Каждое приложение, использующее $ _REQUEST, наиболее вероятно уязвимо для проблем с подделкой отложенного межсайтового запроса. (Это в основном означает, что если, например, существует файл cookie с именем (age), он всегда будет перезаписывать содержимое GET / POST, и поэтому будут выполняться нежелательные запросы)

и в более позднем ответе в той же теме

Дело не в том, что кто-то может подделать GET, POST; Переменные COOKIE. Речь идет о том, что файлы COOKIE будут перезаписывать данные GET и POST в REQUEST.

Поэтому я мог бы заразить ваш браузер файлом cookie, в котором написано, например, action = logout, и с этого дня вы больше не можете использовать приложение, потому что REQUEST [действие] будет выходить из системы навсегда (пока вы вручную не удалите cookie).

И заразить вас с помощью COOKIE так просто ...
а) Я мог бы использовать уязвимость XSS в любом приложении на субдомене
б) Когда-либо пробовал установить cookie для * .co.uk или * .co.kr, когда у вас есть единый домен есть?
c) Другие способы перекрестного домена ...

И если вы считаете, что это не проблема, то я могу вам сказать, что существует простая возможность установить файл cookie * .co.kr, в результате чего несколько версий PHP просто возвращают белые страницы. Представьте: всего один файл cookie, чтобы убить все страницы PHP в * .co.kr

И установив нелегальный идентификатор сеанса в куки действительны для * .co.kr в переменной с именем + PHPSESSID = нелегальный вы можете по- прежнему DOS каждый PHP приложений в Корее с помощью PHP сессий ...

Обсуждение продолжается еще несколько сообщений, и их интересно прочитать.

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

Вы можете полностью опустить $ _COOKIES из глобального $ _REQUEST, чтобы он не был перезаписан каким-либо другим массивом (фактически, вы можете ограничить его любой комбинацией его стандартного содержимого, например руководство PHP по настройке variable_order ini говорит нам:

variable_order Устанавливает порядок анализа переменных EGPCS (Environment, Get, Post, Cookie и Server). Например, если для переменных_order установлено значение «SP», то PHP создаст суперглобальные переменные $ _SERVER и $ _POST, но не создаст $ _ENV, $ _GET и $ _COOKIE. Установка на "" означает, что суперглобальные переменные не устанавливаются.

Но, опять же, вы также можете подумать о том, чтобы не использовать $ _REQUEST вообще, просто потому, что в PHP вы можете обращаться к Environment, Get, Post, Cookie и Server в их собственных глобальных объектах и ​​иметь на один вектор атаки меньше. Вам все равно придется дезинфицировать эти данные, но беспокоиться об этом меньше.

Теперь вы можете задаться вопросом, почему все-таки $ _REQUEST существует и почему он не удаляется. Об этом также спрашивали на PHP Internals. Цитата Расмуса Лердорфа о том, почему существует $ _REQUEST? на внутреннем устройстве PHP

Чем больше подобных вещей мы удаляем, тем труднее людям быстро переходить на более новые, быстрые и безопасные версии PHP. Это вызывает у всех большее разочарование, чем несколько «уродливых» устаревших функций. Если есть серьезная техническая причина, производительность или безопасность, нам нужно внимательно на это взглянуть. В этом случае нам следует обратить внимание не на то, должны ли мы удалить $ _REQUEST, а на то, должны ли мы удалять из него данные cookie. Многие конфигурации уже делают это, в том числе и все мои собственные, и есть веская веская причина безопасности, чтобы не включать файлы cookie в $ _REQUEST. Большинство людей используют $ _REQUEST для обозначения GET или POST, не понимая, что он также может содержать файлы cookie, и поэтому злоумышленники потенциально могут выполнять некоторые уловки с внедрением файлов cookie и ломать наивные приложения.

Во всяком случае, надеюсь, что это пролило свет.

$_REQUESTотносится ко всем видам запросов (GET, POST и т. д.). Иногда это полезно, но обычно лучше указать точный метод ($ _GET, $ _POST и т. Д.).

$_REQUEST обычно считается вредным по той же причине, что преобразования данных от простой до средней сложности часто выполняются в коде приложения, а не декларируются в SQL: некоторые программисты - отстой.

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

Однако это происходит из-за того, что новичок или, по крайней мере, неопытный программист PHP делает простые ошибки. Прежде всего, знайте, когда данные какого типа подходят. Например, у меня есть веб-сервис, который может возвращать ответы в URLEncoding, XML или JSON. Приложение решает, как отформатировать ответ, проверяя заголовок HTTP_ACCEPT, но его можно принудительно преобразовать в него, отправив formatпараметр.

При проверке содержимого параметра формата он может быть отправлен через строку запроса или постданные, в зависимости от множества факторов, не последним из которых является то, хочет ли вызывающее приложение "& format = json", смешанное с его запросом. В данном случае $_REQUESTэто очень удобно, поскольку избавляет меня от необходимости вводить что-то вроде этого:

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

Я не собираюсь вдаваться в подробности, но достаточно сказать, что $_REQUESTиспользование не отговаривается, потому что оно изначально опасно - это просто еще один инструмент, который делает именно то, что от него требуется, понимаете ли вы эти последствия или нет - это плохое, ленивое или неосведомленное решение плохого, ленивого или неопытного программиста, которое вызывает эту проблему.

Как $_REQUESTбезопасно пользоваться

1. Знайте свои данные : у вас должно быть некоторое ожидание относительно того, какие данные вы получите, поэтому обработайте их соответствующим образом. Данные для базы данных? addslashes()или *_escape_string(). Собираетесь показать это пользователю? htmlentities()или htmlspecialchars(). Ожидаете числовых данных? is_numeric()или ctype_digit(). Фактически, filter_input()и связанные с ним функции предназначены только для проверки и очистки данных. Всегда используйте эти инструменты.
2. Не обращайтесь напрямую к данным суперглобалов, предоставленным пользователем . Возьмите за привычку дезинфицировать свои данные каждый раз и перемещать их в чистые переменные, даже если это просто так $post_clean. В качестве альтернативы вы можете просто очистить непосредственно в суперглобальных таблицах, но причина, по которой я рекомендую использовать отдельную переменную, заключается в том, что это позволяет легко обнаруживать уязвимости в коде, поскольку все , что указывает непосредственно на суперглобальный, а не на его очищенный эквивалент, считается опасной ошибкой. ,
3. Знайте, откуда должны поступать ваши данные. Ссылаясь на мой пример выше, вполне разумно разрешить отправку переменной формата ответа через GET или POST. Я также разрешаю отправлять переменную "действие" любым из методов. Однако сами действия имеют очень специфические требования в отношении того, какой HTTP-глагол приемлем . Например, функции, которые вносят изменения в данные, используемые службой, могут быть отправлены только через POST. Запросы на определенные типы данных без привилегий или с низким уровнем привилегий (например, динамически генерируемые изображения карт) могут обслуживаться в ответ на запросы из любого метода.

В заключение запомните это простое правило:

БЕЗОПАСНОСТЬ - ЭТО ВЫ ДЕЛАЕТЕ, ЛЮДИ!

РЕДАКТИРОВАТЬ:

Я настоятельно рекомендую совет bobince: если можете, установите request_orderпараметр в php.ini на «GP»; то есть без компонента cookie. Для этого почти нет рационального объяснения в 98% + случаев, так как данные cookie почти никогда не следует рассматривать как сопоставимые со строкой запроса или постданными.

PS, Анекдот!

Я знал программиста, который придумал $_REQUESTместо для простого хранения данных, которые были бы доступны суперглобальным способом. Важные имена пользователей и пароли, пути к файлам, вы его называете и он хранился в $_REQUEST. Он был немного удивлен (хотя, к сожалению, не комично), когда я рассказал ему, как ведет себя эта переменная. Излишне говорить, что эта практика свергнута.

Запросы GET должны быть идемпотентными, а запросы POST - нет. Это означает, что данные в $_GETи $_POSTобычно следует использовать по-разному.

Если ваше приложение использует данные из $_REQUEST, оно будет вести себя одинаково для запросов GET и POST, что нарушает идемпотентность GET.

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

Мне действительно нравится его использовать. Это дает вам гибкость в использовании GET или POST, которые могут пригодиться для таких вещей, как формы поиска, где большую часть времени данные отправляются POST, но иногда вы хотите сказать ссылку на конкретный поиск, поэтому вы можете вместо этого использовать параметры GET ,

Кроме того, если вы посмотрите на многие другие языки (например, ASP.NET), они вообще не делают различий между переменными GET и POST.

ETA :

Я никогда не использовал REQUEST для получения значений COOKIE, но я думаю, что Кайл Батт очень хорошо отмечает в комментариях к этому сообщению об этом. НЕ рекомендуется использовать REQUEST для получения значений COOKIE. Я считаю, что он прав в том, что есть реальная возможность подделки межсайтовых запросов, если вы это сделаете.

Кроме того, порядок, в котором данные загружаются в REQUEST, контролируется параметрами конфигурации в php.ini (variables_order и request_order). Итак, если у вас есть одна и та же переменная, переданная через POST и GET, какая из них фактически попадает в REQUEST, зависит от этих настроек ini. Это может повлиять на переносимость, если вы зависите от определенного порядка и эти параметры настроены иначе, чем вы ожидаете.

Важно понимать, когда использовать POST, когда использовать GET и когда использовать cookie. С $ _REQUEST значение, на которое вы смотрите, могло исходить от любого из них. Если вы ожидаете получить значение из POST, GET или COOKIE, для тех, кто читает ваш код, более информативно использовать конкретную переменную вместо $ _REQUEST.

Кто-то еще указал, что вы не хотите, чтобы все POST или файлы cookie были переопределены GET, потому что для всех них существуют разные межсайтовые правила, например, если вы возвращаете данные ajax при использовании $ _REQUEST, вы уязвимы к атаке межсайтового скрипта.

Единственный раз, когда использование $_REQUEST- неплохая идея - это GET.

• Если вы используете его для загрузки значений POST, вы рискуете подделать межсайтовые запросы
• Если вы используете его для загрузки значений файлов cookie, вы снова рискуете подделать межсайтовые запросы.

И даже с GET, $_GETэто короче, чем набирать $_REQUEST;)

Я мог бы использоваться только в том случае, если вы хотите получить текущий URL-адрес или имя хоста, но для фактического анализа данных из этого URL-адреса, таких как параметры, с использованием символа &, это, вероятно, не очень хорошая идея. В общем, вы не хотите использовать расплывчатое описание того, что вы пытаетесь сделать. Если вам нужно быть конкретным, где $ _REQUEST - это плохо, если вам не нужно конкретизировать, не стесняйтесь использовать его. Я бы подумал.

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

Может быть удобно использовать $ _REQUEST, когда ваши скрипты могут одинаково реагировать на GET или POST. Я бы сказал, что это должно быть чрезвычайно редким случаем, и в большинстве случаев предпочтительны две отдельные функции для обработки двух отдельных концепций или, по крайней мере, проверка метода и выбор правильных переменных. За ходом выполнения программы обычно намного легче следить, когда нет необходимости в перекрестных ссылках, откуда могут поступать переменные. Будьте добры к человеку, который должен поддерживать ваш код в течение 6 месяцев. Это может быть ты.

Помимо проблем с безопасностью и WTF, вызванных куки-файлами и переменными среды в переменной REQUEST (не заставляйте меня начинать с GLOBAL), подумайте, что может произойти в будущем, если PHP начнет изначально поддерживать другие методы, такие как PUT и DELETE. Хотя крайне маловероятно, что они будут объединены в суперглобал REQUEST, возможно, они могут быть включены как опция в настройке variable_order. Таким образом, вы действительно понятия не имеете, что содержит REQUEST и что имеет приоритет, особенно если ваш код развернут на стороннем сервере.

POST безопаснее, чем GET? На самом деле, нет. Лучше использовать GET там, где это возможно, потому что в ваших журналах легче увидеть, как ваше приложение эксплуатируется при атаке. POST лучше подходит для операций, которые влияют на состояние домена, потому что пауки обычно не следят за ними, а механизмы предиктивной выборки не удаляют весь ваш контент, когда вы входите в свою CMS. Однако вопрос был не в достоинствах GET и POST, а в том, как получатель должен обрабатывать входящие данные и почему их объединять плохо, так что это действительно просто BTW.

Я думаю, с этим нет проблем $_REQUEST, но мы должны быть осторожны при его использовании, так как это набор переменных из 3 источников (GPC).

Я думаю, $_REQUESTчто все еще доступно, чтобы сделать старые программы совместимыми с новыми версиями php, но если мы начнем новые проекты (включая новые библиотеки), я думаю, нам не следует $_REQUESTбольше использовать , чтобы сделать программы более понятными. Нам следует даже подумать об удалении использования $_REQUESTи замене на функцию-оболочку, чтобы облегчить программу, особенно при обработке больших отправленных текстовых данных, поскольку они $_REQUESTсодержат копии $_POST.

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

Даррен Кук: «Начиная с php 5.3, php.ini по умолчанию говорит, что в него помещаются только данные GET и POST $_REQUEST. См. Php.net/request_order. Я просто наткнулся на этот разрыв обратной совместимости, когда ожидал, что данные cookie будут внутри, $_REQUESTи удивился, почему это не так» т работает! "

Вау ... только что некоторые из моих скриптов перестали работать из-за обновления до PHP 5.3 . Сделал то же самое: предположим, что файлы cookie будут установлены при использовании $_REQUESTпеременной. С апгрейдом точно перестал работать.

Теперь я вызываю значения cookie отдельно, используя $_COOKIE["Cookie_name"]...

Основная проблема заключается в том, что он содержит файлы cookie, как говорили другие.

В PHP 7 это можно сделать:

$request = array_merge($_GET ?? [], $_POST ?? []);

Это позволяет избежать проблемы с файлами cookie и в худшем случае дает пустой массив, а в лучшем случае - слияние $ _GET и $ _POST, причем последнее имеет приоритет. Если вас не слишком беспокоит возможность URL-инъекции параметров через строку запроса, это довольно удобно.

Это очень небезопасно. Также это неудобно, так как вы не знаете, получаете ли вы POST или GET, или другой запрос. Вы действительно должны знать разницу между ними при разработке своих приложений. GET очень небезопасен, поскольку он передается в URL-адресе и не подходит почти для чего-либо, кроме навигации по страницам. POST, хотя и небезопасен сам по себе, обеспечивает один уровень безопасности.