O que há de errado em usar $ _REQUEST []?

116

Eu vi uma série de posts aqui dizendo para não usar a $_REQUESTvariável. Normalmente não, mas às vezes é conveniente. O que há de errado com isso?

sprugman
fonte
2
Veja as perguntas e respostas relacionadas: stackoverflow.com/questions/1149118/…
Gordon
2
Desde o php 5.3, o php.ini padrão diz que apenas os dados GET e POST são colocados no $_REQUEST. Consulte php.net/request_order Acabei de descobrir essa quebra de compatibilidade com versões anteriores ao esperar que os dados do cookie estivessem $_REQUESTe me perguntando por que não estava funcionando! Portanto, a maior razão para evitar o uso de $ _REQUEST é agora que seu script não pode se auto-definir request_orderPHP_INI_PERDIR), então uma mudança no php.ini pode facilmente quebrar as suposições sobre as quais seu script foi construído. Melhor colocar essas suposições diretamente em seu script.
Darren Cook,

Respostas:

184

Não há absolutamente nada de errado em receber informações de ambos $_GETe $_POSTde uma forma combinada. Na verdade, é isso que você quase sempre deseja fazer:

  • para uma solicitação idempotente simples geralmente enviada via GET, existe a possibilidade de que a quantidade de dados que você deseja não caiba em uma URL, então ela foi transformada em uma solicitação POST em vez de uma questão prática.

  • para uma solicitação que tenha um efeito real, você deve verificar se ela foi enviada pelo método POST. Mas a maneira de fazer isso é verificar $_SERVER['REQUEST_METHOD']explicitamente, não depender de $_POSTestar vazio para obter um GET. E de qualquer maneira, se o método for POST, você ainda pode querer tirar alguns parâmetros de consulta do URL.

Não, o problema $_REQUESTnão tem nada a ver com a combinação dos parâmetros GET e POST. É que também, por padrão, inclui $_COOKIE. E os cookies realmente não são como parâmetros de envio de formulário: você quase nunca quer tratá-los como a mesma coisa.

Se você acidentalmente obtiver um conjunto de cookies em seu site com o mesmo nome de um de seus parâmetros de formulário, os formulários que dependem desse parâmetro pararão de funcionar de maneira misteriosa devido aos valores de cookie substituindo os parâmetros esperados. Isso é muito fácil de fazer se você tiver vários aplicativos no mesmo site e pode ser muito difícil de depurar quando você tem apenas alguns usuários com cookies antigos que você não usa mais perambulando e quebrando os formulários de maneiras não - outra pessoa pode se reproduzir.

Você pode mudar este comportamento para uma ordem muito mais sensata GP(não C) com a configuração request_order no PHP 5.3. Onde isso não for possível, eu pessoalmente evitaria $_REQUESTe, se eu precisasse de um array combinado GET + POST, crio-o manualmente.

bobince
fonte
2
Essas situações (dados muito longos para serem enviados via GET) são uma exceção, não uma regra
Ben James
1
Boa resposta. Também percebi que, com frameworks como Zend Framework, os parâmetros GET e POST são combinados em um objeto de solicitação. Isso nunca me ocorreu até que eu li sua postagem.
Jay Sidri
Por padrão, a configuração request_order é definida como "GP" no php.ini a partir do PHP 5.4+, então eu diria que vá em frente ... mas como sempre, prossiga com cuidado.
bcmoney
se $ _POST for a="foo"e $ _COOKIE a="bar", então haverá alguma substituição / conflito aqui?
Ferrugem
75

Tenho vasculhado alguns posts de newsgroups sobre PHP Internals e encontrei uma discussão interessante sobre o tópico. O tópico inicial era sobre outra coisa, mas uma observação de Stefan Esser, um (se não o ) especialista em segurança no mundo do PHP direcionou a discussão para as implicações de segurança do uso de $ _REQUEST para alguns posts.

Citando Stefan Esser sobre PHP Internals

$ _REQUEST é uma das maiores fraquezas de design em PHP. Cada aplicativo que usa $ _REQUEST é muito provavelmente vulnerável a problemas de falsificação de solicitação cruzada atrasada. (Isso basicamente significa que se, por exemplo, um cookie chamado (idade) existir, ele sempre substituirá o conteúdo GET / POST e, portanto, solicitações indesejadas serão realizadas)

e em uma resposta posterior ao mesmo tópico

Não se trata do fato de que alguém pode forjar GET, POST; Variáveis ​​COOKIE. É sobre o fato de que os COOKIEs sobrescreverão os dados GET e POST em REQUEST.

Portanto, eu poderia infectar seu navegador com um cookie que diz, por exemplo, ação = logout e daquele dia em diante você não pode mais usar o aplicativo porque REQUEST [ação] será encerrado para sempre (até que você exclua manualmente o cookie).

E infectar você com um COOKIE é tão simples ...
a) Eu poderia usar um vuln XSS em qualquer aplicativo em um subdomínio
b) Você já tentou definir um cookie para * .co.uk ou * .co.kr quando você possui um único domínio lá?
c) Outros domínios cruzados de qualquer maneira ...

E se você acredita que isso não é um problema, posso dizer que existe uma possibilidade simples de definir um cookie fe a * .co.kr que resulta em várias versões do PHP apenas retornando páginas em branco. Imagine: apenas um único cookie para matar todas as páginas PHP em * .co.kr

E definindo um ID de sessão ilegal em um cookie válido para * .co.kr em uma variável chamada + PHPSESSID = ilegal, você ainda pode fazer o DOS em todos os aplicativos PHP na Coreia usando sessões PHP ...

A discussão continua por mais algumas postagens e é interessante de ler.


Como você pode ver, o principal problema com $ _REQUEST não é tanto que ele possui dados de $ _GET e $ _POST, mas também de $ _COOKIE. Alguns outros caras da lista sugeriram alterar a ordem em que $ _REQUEST é preenchido, por exemplo, preenchendo-o com $ _COOKIE primeiro, mas isso pode levar a vários outros problemas potenciais, por exemplo, com o manuseio de sessões .

Você poderia omitir completamente $ _COOKIES do $ _REQUEST global, de modo que não seja sobrescrito por qualquer um dos outros arrays (na verdade, você pode limitá-lo a qualquer combinação de seu conteúdo padrão, como o manual do PHP na configuração de variable_order ini diga-nos:

variable_order Define a ordem da análise da variável EGPCS (Environment, Get, Post, Cookie e Server). Por exemplo, se variables_order for definido como "SP", então o PHP criará as superglobais $ _SERVER e $ _POST, mas não criará $ _ENV, $ _GET e $ _COOKIE. Definir como "" significa que nenhum superglobal será definido.

Mas, novamente, você também pode considerar não usar $ _REQUEST completamente, simplesmente porque no PHP você pode acessar Environment, Get, Post, Cookie e Server em seus próprios globais e ter um vetor de ataque a menos. Você ainda precisa limpar esses dados, mas é uma coisa a menos com que se preocupar.


Agora você deve estar se perguntando, por que $ _REQUEST existe afinal e por que não foi removido. Isso também foi perguntado no PHP Internals. Citando Rasmus Lerdorf sobre Por que $ _REQUEST existe? em PHP Internals

Quanto mais coisas como essas removemos, mais difícil se torna para as pessoas mudarem rapidamente para versões mais novas, mais rápidas e seguras do PHP. Isso causa muito mais frustração para todos do que alguns recursos legados "feios". Se houver um motivo técnico, desempenho ou segurança decente, precisamos dar uma olhada nisso. Nesse caso, o que devemos olhar não é se devemos remover $ _REQUEST, mas se devemos remover dados de cookies dele. Muitas configurações já fazem isso, incluindo todas as minhas, e há um forte motivo de segurança válido para não incluir cookies em $ _REQUEST. A maioria das pessoas usa $ _REQUEST para significar GET ou POST, sem perceber que também pode conter cookies e, como tal, os bandidos podem fazer alguns truques de injeção de cookies e quebrar aplicativos ingênuos.

De qualquer forma, espero que lance alguma luz.

Gordon
fonte
1
1 bom ver alguma discussão sobre isso ... Achei que estava ficando louco!
bobince
2
Acho que essa discussão foi um pouco generalizada demais. O problema real é o desconhecimento do desenvolvedor, não a existência de cookies em $ _REQUEST em si. O PHPSESSID fixado, por exemplo, será redefinido com um cookie por domínio de qualquer maneira com o código de tratamento de sessão contemporâneo. E para alguns aplicativos, uma solicitação de substituição de cookie vars pode realmente ser desejável (por exemplo, sort_order = ASC substitui um formulário de pesquisa GET var). Embora codificar explicitamente esse comportamento seja mais sensato.
mario
1
Postagem muito abrangente, esta deve ser a resposta. Talvez as pessoas
temam
Infelizmente, Rasmus comentou sobre isso em 2009, mas $ _REQUEST é essencialmente o mesmo agora, em 2015.
Kzqai
10

$_REQUESTrefere-se a todos os tipos de solicitações (GET, POST etc.). Isso às vezes é útil, mas geralmente é melhor especificar o método exato ($ _GET, $ _POST etc).

Luca Matteis
fonte
19
Esta resposta descreve o que é $ _REQUEST, mas não responde à pergunta.
zombat
1
Ele está dizendo que é apenas uma prática melhor saber que tipo de solicitação seria recebida e codificar para essa solicitação específica.
Polaris878
8

$_REQUEST geralmente é considerado prejudicial pelo mesmo motivo que as transformações de dados de complexidade simples para média costumam ser realizadas no código do aplicativo em vez de declaradas em SQL: alguns programadores são péssimos.

Como tal, se alguém tende a usar em $_REQUESTqualquer lugar, posso fazer qualquer coisa via GET via POST, o que significa configurar<img> tags no meu site (malicioso) que fazem com que os usuários logados em seu módulo de e-commerce comprem produtos silenciosamente, ou eu pode fazer com que cliquem em links que resultarão em ações perigosas ou na revelação de informações confidenciais (provavelmente para mim).

No entanto, isso ocorre porque um programador PHP novato, ou pelo menos inexperiente, comete erros simples. Em primeiro lugar, saiba quando os dados de que tipo são apropriados. Por exemplo, tenho um serviço da web que pode retornar respostas em URLEncoding, XML ou JSON. O aplicativo decide como formatar a resposta verificando o cabeçalho HTTP_ACCEPT, mas pode ser forçado a formar um especificamente enviando o formatparâmetro.

Ao verificar o conteúdo do parâmetro de formato, ele pode ser enviado via querystring ou um postdata, dependendo de uma infinidade de fatores, entre os quais se os aplicativos de chamada querem ou não "& format = json" misturado com sua solicitação. Neste caso, $_REQUESTé muito conveniente porque evita que eu tenha que digitar algo assim:

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

Não vou divagar muito mais, mas basta dizer que $_REQUEST uso não é dissuadido porque é inerentemente perigoso - é apenas outra ferramenta que faz exatamente o que é pedido, quer você entenda essas implicações ou não - é o decisão pobre, preguiçosa ou desinformada de um programador pobre, preguiçoso ou inexperiente que causa este problema.

Como usar $_REQUESTcom segurança


  1. Conheça seus dados : você deve ter alguma expectativa quanto ao tipo de dados que obterá, portanto, limpe-os de acordo. Dados para um banco de dados? addslashes()ou *_escape_string(). Vai mostrar para o usuário? htmlentities()ou htmlspecialchars(). Esperando dados numéricos? is_numeric()ou ctype_digit(). Na verdade, filter_input()e suas funções relacionadas são projetadas para fazer nada além de verificar e higienizar dados. Use essas ferramentas, sempre.
  2. Não acesse dados superglobais fornecidos pelo usuário diretamente . Crie o hábito de higienizar seus dados, todas as vezes, e mova-os para limpar variáveis, mesmo que seja justo $post_clean. Como alternativa, você pode simplesmente limpar diretamente nas superglobais, mas o motivo pelo qual defendo o uso de uma variável separada é porque isso facilita a localização de vulnerabilidades no código, já que qualquer coisa que aponte diretamente para uma superglobal e não seu equivalente sanitizado é considerado um erro perigoso .
  3. Saiba de onde seus dados devem vir. Fazendo referência ao meu exemplo acima, é perfeitamente razoável permitir que a variável de formato de resposta seja enviada via GET ou POST. Também permito que a variável "action" seja enviada por qualquer um dos métodos. No entanto, as próprias ações têm requisitos muito específicos quanto a qual verbo HTTP é aceitável . As funções, por exemplo, que fazem alterações nos dados usados ​​pelo serviço, só podem ser enviadas via POST. As solicitações de certos tipos de dados sem ou de baixo privilégio (como imagens de mapa geradas dinamicamente) podem ser atendidas em resposta a solicitações de qualquer um dos métodos.

Em conclusão, lembre-se desta regra simples:

SEGURANÇA É O QUE VOCÊ FAZ, GENTE!

EDITAR:

Eu recomendo fortemente o conselho de bobince: se você puder, defina orequest_order parâmetro em php.ini para "GP"; ou seja, nenhum componente de cookie. Quase não há raciocínio racional para isso em mais de 98% dos casos, pois os dados do cookie quase nunca devem ser considerados comparáveis ​​à string de consulta ou aos pós-dados.

PS, anedota!

Conheci um programador que pensou em $_REQUESTum lugar para simplesmente armazenar dados que fossem acessíveis de forma superglobal. Nomes de usuário e senhas importantes, caminhos para arquivos, você nomeia e ele foi armazenado em $_REQUEST. Ele ficou um pouco surpreso (embora não comicamente, infelizmente) quando eu disse a ele como essa variável se comporta. Desnecessário dizer que essa prática foi deposta.

Liberado
fonte
8

As solicitações GET devem ser idempotentes e as solicitações POST geralmente não são. Isso significa que dados $_GETe $_POSTgeralmente devem ser usados de diferentes maneiras.

Se seu aplicativo estiver usando dados de $_REQUEST, ele se comportará da mesma forma para solicitações GET e POST, o que viola a idempotência de GET.

Ben James
fonte
1
mas isso não depende da implementação? "Indempotente" é uma palavra nova para mim, mas se estou entendendo bem, seria fácil imaginar configurar uma situação GET que não fosse indempotente. Por exemplo, os contadores de página geralmente aumentam cada vez que você solicita um determinado url.
sprugman
1
@sprugman - também, você pode ter situações em que há dados GET e dados POST na mesma solicitação, caso em que o método de solicitação é essencialmente sem sentido quando contextualizado com os dados da solicitação.
zombat
sprugman, obviamente qualquer solicitação GET modifica algo porque é registrado pelo servidor web. Ele ainda pode ser indempotente no domínio do aplicativo, onde esses metadados realmente não importam.
Ben James
@sprugman - a ideia geral aqui é que você não deve ter uma solicitação GET que modifica os dados. Um exemplo típico de por que isso é ruim seria um web spider rastreando seu site e seguindo links que modificam os dados sem querer. Por exemplo, o link "sinalizar" em uma postagem SO.
Eric Petroelje
Esse foi um exemplo trivial. Que tal se eu estiver usando GET via ajax porque é mais rápido (como sugerido neste post em carsonified carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post ).
sprugman
7

É vago. Você não sabe realmente como os dados chegaram até você, pois carregam dados de postagem, obtenção e cookie. Não necessariamente acho que isso é sempre uma coisa ruim, a menos que você precise saber ou restringir o método de entrega.

Sampson
fonte
3

Na verdade, gosto de usar. Dá-lhe a flexibilidade de usar GET ou POST, o que pode ser útil para coisas como formulários de pesquisa em que a maior parte do tempo os dados são POSTADOS, mas às vezes você vai querer dizer link para uma pesquisa particular, então você pode usar parâmetros GET. .

Além disso, se você olhar para muitas outras linguagens (ASP.NET, por exemplo), elas não fazem distinção alguma entre as variáveis ​​GET e POST.

ETA :

Eu nunca usei REQUEST para obter os valores COOKIE, mas acho que Kyle Butt enfatiza isso nos comentários deste post. NÃO é uma boa ideia usar REQUEST para obter os valores COOKIE. Eu acredito que ele está certo ao dizer que existe um potencial real para falsificação de solicitação entre sites se você fizer isso.

Além disso, a ordem em que as coisas são carregadas no REQUEST é controlada pelos parâmetros de configuração no php.ini (variables_order e request_order). Então, se você tiver a mesma variável passada via POST e GET, qual delas realmente entra em REQUEST depende dessas configurações ini. Isso pode afetar a portabilidade se você depender de um pedido específico e essas configurações forem configuradas de maneira diferente do que você espera.

Eric Petroelje
fonte
isso é um erro terrível. Como você pode garantir que ações não idempotentes foram realizadas em um POST?
Kyle Butt
1
@Kyle - por não usá-lo para ações não idempotentes. Certamente não o usaria para tudo, apenas ressaltando que É útil, como para pesquisas como mencionei no meu exemplo.
Eric Petroelje
1
Esta ideia mágica de que _POST é seguro e _GET não é inevitável. Se eu não estiver usando o software corretamente, haverá muito pouca (ou nenhuma) diferença para mim no envio de uma solicitação POST em relação a uma solicitação GET. A segurança está no que você faz com os dados, não de onde eles vêm. Quanto aos exploits XSS / Request simples, é inteiramente possível que use _REQUEST apenas para valores que seriam válidos com POST ou GET, e use _POST apenas para coisas que devem ser POST. Bom senso, não uso superglobal mágico.
Cancelamento em
1
@Kyle - Ainda não vejo como você não poderia fazer o que mencionou com a mesma facilidade usando algo como curl () ou um post ajax para passar os mesmos dados via POST e COOKIE. Quer você use REQUEST, GET, POST ou COOKIE, todos os dados vêm do cliente e sempre podem ser falsificados.
Eric Petroelje
1
@zombat: A solicitação curl que você formou não será conectada como um usuário vulnerável. O link que você cria e coloca em seu site irá. @ Lançado: Não é pensamento mágico e ainda existem vulnerabilidades em abundância no GET. mas é mais seguro confiar em um POST de um usuário conectado do que em um GET de um usuário conectado.
Kyle Butt
2

É importante entender quando usar POST, quando usar GET e quando usar um cookie. Com $ _REQUEST, o valor que você está procurando pode ter vindo de qualquer um deles. Se você espera obter o valor de um POST ou GET ou de um COOKIE, é mais informativo para alguém que está lendo seu código usar a variável específica em vez de $ _REQUEST.

Alguém também apontou que você não deseja que todos os POSTs ou cookies sejam substituídos por GETs porque existem diferentes regras entre sites para todos eles, por exemplo, se você retornar dados ajax enquanto usa $ _REQUEST, você está vulnerável a um ataque de script entre sites.

Kyle Butt
fonte
2

A única vez que usar $_REQUESTnão é uma má ideia é com GET.

  • Se você usá-lo para carregar valores POST, corre o risco de falsificações de solicitação entre sites
  • Se você usá-lo para carregar valores de cookies, mais uma vez corre o risco de falsificações de solicitação entre sites

E mesmo com GET, $_GETé mais curto para digitar do que $_REQUEST;)

Jani Hartikainen
fonte
Embora eu concorde com você, acho importante observar por que isso é verdadeiro e / ou perigoso: deve-se usar $_POSTquando for importante que os dados sejam POSTDATA. Deve-se usar $_REQUESTquando os dados são agnósticos ao verbo HTTP usado. Em todos esses casos, deve-se limpar cuidadosamente todos os dados de entrada.
Cancelamento em
1
Não vejo como a fonte dos dados se relaciona com a probabilidade de falsificação de solicitação entre sites. Um invasor pode definir um parâmetro POST perfeitamente facilmente, fornecendo ao usuário um formulário POST apontado para o seu site; você precisará das mesmas medidas de proteção anti-XSRF, independentemente de o envio vir de GET ou POST.
bobince
É muito mais fácil abusar de GET para falsificação. Por exemplo, você pode simplesmente ter uma tag img com seu src definido com os parâmetros desejados. Ele funcionará sem que o usuário saiba que ele está lá.
Jani Hartikainen
0

Eu posso ser usado apenas se você quiser recuperar o url ou nome do host atual, mas para realmente analisar dados desse URL, como parâmetros usando o símbolo &, provavelmente não é uma boa ideia. Em geral, você não deseja usar uma descrição vaga do que está tentando fazer. Se você precisar ser específico, é aí que $ _REQUEST é ruim, se você não precisar ser específico, sinta-se à vontade para usá-lo. Eu pensaria.

Brian T Hannan
fonte
O que você está tentando dizer? Você está confuso $_REQUESTcom $_SERVER['QUERY_STRING']?
Cancelamento em
0

Se você sabe quais dados deseja, deve solicitá-los explicitamente. IMO, GET e POST são dois animais diferentes e não consigo pensar em uma boa razão para você precisar misturar dados de postagem e strings de consulta. Se alguém tiver um, estou interessado.

Pode ser conveniente usar $ _REQUEST quando seus scripts podem responder a GET ou POST da mesma maneira. Eu argumentaria, porém, que este deve ser um caso extremamente raro e, na maioria dos casos, duas funções separadas para lidar com dois conceitos separados, ou pelo menos verificar o método e selecionar as variáveis ​​corretas, é o preferido. O fluxo do programa geralmente é muito mais fácil de seguir quando não é necessário cruzar a referência de onde as variáveis ​​podem estar vindo. Seja gentil com a pessoa que precisa manter seu código em 6 meses. Pode ser você.

Além dos problemas de segurança e WTFs causados ​​por cookies e variáveis ​​de ambiente na variável REQUEST (não me faça começar no GLOBAL), considere o que pode acontecer no futuro se o PHP começar a suportar nativamente outros métodos, como PUT e DELETE. Embora seja extremamente improvável que eles sejam mesclados na superglobal REQUEST, é possível que eles possam ser incluídos como uma opção na configuração variable_order. Portanto, você realmente não tem ideia do que REQUEST contém e do que está tendo precedência, principalmente se seu código for implantado em um servidor de terceiros.

O POST é mais seguro do que o GET? Na verdade não. É melhor usar GET onde for prático, porque é mais fácil ver em seus logs como seu aplicativo está sendo explorado quando é atacado. O POST é melhor para operações que afetam o estado do domínio porque os spiders geralmente não os seguem, e os mecanismos de busca preditiva não excluirão todo o seu conteúdo quando você efetuar login no CMS. No entanto, a questão não era sobre os méritos de GET vs POST, era sobre como o receptor deveria tratar os dados recebidos e por que é ruim mesclá-los, então este é realmente apenas um BTW.

Duncan
fonte
0

Eu acho que não há problema com $_REQUEST, mas devemos ter cuidado ao usá-lo, pois é uma coleção de variáveis ​​de 3 fontes (GPC).

Acho que $_REQUESTainda está disponível para fazer programas antigos compatíveis com novas versões de php, mas se começarmos novos projetos (incluindo novas bibliotecas), acho que não devemos usar $_REQUESTmais para tornar os programas mais claros. Devemos até mesmo considerar a exclusão de usos de $_REQUESTe substituí-los por uma função wrapper para tornar o programa mais leve, especialmente no processamento de grandes dados de texto enviados, uma vez que $_REQUESTcontém cópias de $_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; 
    } 
  }
}
usuário953985
fonte
0

Darren Cook: "Desde o php 5.3, o php.ini padrão diz que apenas dados GET e POST são inseridos $_REQUEST. Veja php.net/request_order Acabei de me deparar com essa quebra de compatibilidade com versões anteriores ao esperar que os dados do cookie estivessem $_REQUESTe me perguntando por que não estavam . estou trabalhando! "

Uau ... alguns dos meus scripts pararam de funcionar por causa de uma atualização para o PHP 5.3 . Fez a mesma coisa: suponha que os cookies seriam definidos ao usar a $_REQUESTvariável. Com a atualização exatamente isso parou de funcionar.

Agora chamo os valores dos cookies separadamente usando $_COOKIE["Cookie_name"]...

Arjan202
fonte
-1

O problema central é que contém cookies, como já foi dito.

No PHP 7, você pode fazer isso:

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

Isso evita o problema dos cookies e, na pior das hipóteses, dá a você um array vazio e, na melhor das hipóteses, uma fusão de $ _GET e $ _POST com o último tendo precedência. Se você não está muito preocupado em permitir a injeção de parâmetros de URL por meio da string de consulta, é bastante conveniente.

amh15
fonte
Aqueles que escolheram votar negativamente, por favor, expliquem para minha edificação.
amh15 de
-2

É muito inseguro. Além disso, é estranho, pois você não sabe se está recebendo um POST ou GET ou outra solicitação. Você realmente deve saber a diferença entre eles ao projetar seus aplicativos. GET é muito inseguro, pois é passado na URL e não é adequado para quase nada além da navegação na página. O POST, embora não seja seguro por si só, fornece um nível de segurança.

Stan
fonte
4
Não há diferença na segurança entre $ _POST e $ _GET, exceto que você não pode digitar uma solicitação POST em uma barra de URL do navegador. No entanto, leva apenas 5 segundos para fazer uma solicitação cURL de linha de comando utilizando POST.
zombat
3
@Zombat: Precisamos começar algum tipo de campanha para convencer as pessoas de que o POST não é inerentemente seguro, ou até mais seguro, do que o GET. A segurança está em como você trata os dados, não no verbo HTTP usado para obtê-los.
Cancelamento em
@ Lançado - proponho uma imagem icônica de uma nuvem em dois tons com alguns raios para representar a internet, com a palavra "MUDAR" embaixo.
zombat
1
@GuyT: Essa é uma visão muito estreita. Não se trata apenas de quão "seguro" é, mas de quão confidencial é. Os parâmetros GET podem aparecer como autocompletes no url do navegador, até mesmo no histórico do navegador. Além disso, a segurança não termina com o navegador. Por exemplo, muitos servidores registram urls http, então qualquer coisa na url seria registrada, por exemplo. Ter um nome de usuário / senha mostrado nos logs faz a diferença. No lado seguro, sempre evite passar informações confidenciais como parâmetros GET.
stan
1
Especificamente, os logs de acesso do Apache. Qualquer url de solicitação será registrado e QUALQUER PESSOA que tenha acesso aos registros poderá ver suas credenciais chegando.
stan