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

116

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

sprugman
источник
2
См. Связанные вопросы и ответы: stackoverflow.com/questions/1149118/…
Гордон,
2
Начиная с php 5.3, php.ini по умолчанию говорит, что в него помещаются только данные GET и POST $_REQUEST. См. Php.net/request_order. Я только что наткнулся на этот перерыв в обратной совместимости, когда ожидал, что будут данные cookie, $_REQUESTи задаюсь вопросом, почему они не работают! Итак, самая большая причина избегать использования $ _REQUEST заключается в том, что ваш скрипт не может установить request_orderсам себя (это так PHP_INI_PERDIR), поэтому изменение php.ini может легко нарушить предположения, на которых построен ваш скрипт. Лучше поместить эти предположения прямо в ваш сценарий.
Даррен Кук

Ответы:

184

Там абсолютно ничего плохого с принятием вход от обоих $_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, создавал бы его вручную.

bobince
источник
2
Эти ситуации (данные слишком длинные для отправки через GET) являются исключением, а не правилом,
Бен Джеймс
1
Хороший ответ. Я также заметил, что в таких фреймворках, как Zend Framework, параметры GET и POST объединены в один объект запроса. Меня это не поразило, пока я не прочитал ваш пост.
Джей Сидри
По умолчанию для конфигурации request_order в php.ini, начиная с PHP 5.4+, установлено значение «GP», поэтому я бы посоветовал пойти на это ... но, как всегда, действуйте осторожно.
bcmoney 05
если $ _POST a="foo"и $ _COOKIE a="bar", то будут ли здесь какие-либо переопределения / конфликты?
Rust
75

Я покопался в некоторых сообщениях групп новостей о 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 и ломать наивные приложения.

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

Гордон
источник
1
+1 приятно видеть обсуждение этого ... Я думал, что схожу с ума!
bobince
2
Я думаю, что это обсуждение было несколько чрезмерно обобщенным. Настоящая проблема заключается в незнании разработчика, а не в существовании файлов cookie в $ _REQUEST как таковом. Фиксированный PHPSESSID, например, будет сброшен с помощью файла cookie для каждого домена в любом случае с помощью современного кода обработки сеанса. А для некоторых приложений действительно может быть желательным переопределение переменных запроса cookie (например, sort_order = ASC переопределяет поисковую форму GET var). Хотя кодирование в таком поведении явно более разумно.
Марио
1
Очень исчерпывающий пост, это должен быть ответ. Может быть, люди боятся длинного поста;)
Джунг Нгуен 06
К сожалению, Расмус прокомментировал это в 2009 году, но, тем не менее, $ _REQUEST, по сути,
остался
10

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

Лука Маттеис
источник
19
Этот ответ описывает, что такое $ _REQUEST, но не отвечает на вопрос.
zombat
1
Он говорит, что просто лучше знать, какой тип запроса будет входить, и кодировать этот конкретный запрос.
Polaris878,
8

$_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. Он был немного удивлен (хотя, к сожалению, не комично), когда я рассказал ему, как ведет себя эта переменная. Излишне говорить, что эта практика свергнута.

Dereleased
источник
8

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

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

Бен Джеймс
источник
1
но разве это не зависит от реализации? «Indempotent» - новое слово для меня, но если я правильно его понимаю, было бы легко представить себе создание ситуации GET, которая не была бы неопределенной. Например, счетчики страниц обычно увеличиваются каждый раз, когда вы запрашиваете определенный URL.
sprugman
1
@sprugman - также могут быть ситуации, когда у вас есть данные GET и POST в одном запросе, и в этом случае метод запроса по существу бессмысленен при контекстуализации с данными запроса.
zombat
sprugman, очевидно, что любой запрос GET что-то модифицирует, потому что он регистрируется веб-сервером. Он все еще может быть независимым в домене приложения, где эти метаданные не имеют особого значения.
Бен Джеймс,
@sprugman - общая идея здесь в том, что у вас не должно быть запроса GET, который изменяет данные. Типичным примером того, почему это плохо, может быть веб-паук, просматривающий ваш сайт и переходящий по ссылкам, которые непреднамеренно изменяют данные. Например, ссылка "флаг" в сообщении SO.
Эрик Петрелье
Это был банальный пример. Как насчет того, если я использую GET через ajax, потому что он быстрее (как предлагается в этом сообщении на carsonified carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post ).
sprugman
7

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

Сэмпсон
источник
3

Мне действительно нравится его использовать. Это дает вам гибкость в использовании 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?
Кайл Батт
1
@Kyle - не используя его для неидемпотентных действий. Я, конечно, не стал бы использовать его для всего, просто указав, что он полезен, например, для поиска, как я упоминал в своем примере.
Эрик Петрелье
1
Эта волшебная идея о том, что _POST безопасен, а _GET нет, не должна исчезнуть. Если я неправильно использую ваше программное обеспечение, то для меня очень мало (если вообще есть) различий в отправке запроса POST и запроса GET. Безопасность заключается в том, что вы делаете с данными, а не в том, откуда они пришли. Что касается простых эксплойтов XSS / Request, вполне возможно, что он использует _REQUEST только для значений, которые будут действительны либо с POST, либо с GET, и использовать _POST только для вещей, которые должны быть отправлены POST. Здравый смысл, а не магическое суперглобальное использование.
Дата выпуска
1
@Kyle - Я до сих пор не понимаю, как вы не могли сделать то, о чем говорите, так же легко, используя что-то вроде curl () или сообщение ajax для передачи тех же данных через POST и COOKIE. Независимо от того, используете ли вы REQUEST, GET, POST или COOKIE, все данные в конечном итоге поступают от клиента и всегда могут быть подделаны.
Эрик Петрелье
1
@zombat: сформированный вами запрос curl не будет зарегистрирован как уязвимый пользователь. Ссылка, которую вы создаете и размещаете на своем сайте, будет. @Dereleased: это не волшебное мышление, и в GET все еще есть множество уязвимостей. но безопаснее доверять POST от зарегистрированного пользователя, чем GET от зарегистрированного пользователя.
Кайл Батт
2

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

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

Кайл Батт
источник
2

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

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

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

Яни Хартикайнен
источник
Хотя я согласен с вами, я думаю, что важно отметить, почему это правда и / или опасно: следует использовать, $_POSTкогда важно, чтобы данные были POSTDATA. Следует использовать, $_REQUESTкогда данные не зависят от используемой HTTP-команды. Во всех этих случаях следует тщательно дезинфицировать все входные данные.
Дата выпуска
1
Я не понимаю, как источник данных влияет на вероятность подделки межсайтовых запросов. Злоумышленник может легко установить параметр POST, предоставив пользователю форму POST, указывающую на ваш сайт; вам понадобятся одни и те же меры защиты от XSRF, независимо от того, идет ли отправка через GET или POST.
bobince
Гораздо проще использовать GET для подделки. Например, вы можете просто иметь тег img с его src, установленным с желаемыми параметрами. Он будет работать, даже если пользователь не узнает об этом.
Яни Хартикайнен
0

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

Брайан Т Ханнан
источник
Что вы пытаетесь сказать? Вы путаете $_REQUESTс $_SERVER['QUERY_STRING']?
Дата выхода
0

Если вы знаете, какие данные вам нужны, вам следует явно запросить их. 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.

Дункан
источник
0

Я думаю, с этим нет проблем $_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; 
    } 
  }
}
user953985
источник
0

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

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

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

Arjan202
источник
-1

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

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

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

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

amh15
источник
Те, кто предпочитает голосовать против, объясните, пожалуйста, в мое назидание.
amh15
-2

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

стан
источник
4
Нет никакой разницы в безопасности между $ _POST и $ _GET, за исключением того, что вы не можете ввести запрос POST в адресную строку браузера. Однако на создание запроса cURL из командной строки с использованием POST требуется всего 5 секунд.
zombat
3
@Zombat: Нам нужно начать какую-то кампанию, чтобы убедить людей, что POST по своей сути небезопасен или даже безопаснее, чем GET. Безопасность заключается в том, как вы обрабатываете данные, а не в том, какой HTTP-глагол был использован для их получения.
Дата выпуска
@Dereleased - я предлагаю культовое двухцветное изображение облака с несколькими молниями для обозначения Интернета со словом «ИЗМЕНЕНИЕ» под ним.
zombat
1
@GuyT: Это очень узкий кругозор. Дело не только в том, насколько это «безопасно», но и в том, насколько это конфиденциально. Параметры GET могут отображаться как автозаполнение в URL-адресе браузера, даже в истории браузера. Кроме того, безопасность не ограничивается браузером. Например, многие серверы регистрируют URL-адреса http, поэтому, например, в журнале будет записано что-либо в URL-адресе. Отображение имени пользователя и пароля в журналах имеет значение. На всякий случай всегда избегайте передачи конфиденциальной информации в виде параметров GET.
Стэн
1
В частности, журналы доступа Apache. Любой URL-адрес запроса будет зарегистрирован, и ЛЮБОЙ, у кого есть доступ к журналам, сможет увидеть ваши учетные данные.
Стэн