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.