$ _REQUEST tem problema de segurança?

Meu ajudante está aprendendo PHP atualmente,
e ele me enviou seu código PHP,
e eu achei que ele usa $ _REQUEST em seu código.

O livro que eu li diz que
$ _REQUEST tem problema de segurança assim
melhor usar $ _POST.

então eu respondi ao sogro que
é melhor usar $ _POST.

Isso está bem?

Eu diria que é perigoso caracterizar $ _POST como mais seguro que $ _REQUEST.

Se os dados não estão sendo validados e desinfetados antes de serem usados, você tem um possível vetor de ataque.

Em suma: não importa de onde os dados são provenientes se não estiver sendo processado de forma segura.

Bem, o motivo pelo qual $_REQUEST tem problemas é que ele pega valores de $_GET , $_POST e $_COOKIE , o que significa que se você codificar as coisas de determinadas maneiras e certificar-se de premissas inválidas de confiança-cliente, um usuário mal-intencionado poderia Aproveite isso fornecendo um valor em um lugar diferente do que você esperava e superando o que estava tentando passar.

Isso também significa que você pode ter dado as instruções incorretas de seu súplica, porque pode ter sido um valor GET ou COOKIE que ele estava pegando de $_REQUEST . Você precisaria usar qualquer lugar onde o valor que você procura realmente apareça, não necessariamente $_POST .

Como já foi mencionado em várias respostas: todos os dados provenientes do cliente não podem ser confiáveis ​​e devem ser tratados como sendo maliciosos por padrão . Isso inclui $_POST , $_GET , $_COOKIE e $_REQUEST (a combinação do primeiro), mas outros também.

Quando falando sobre alguns deles serem mais perigosos do que outros, eu certamente separaria $_GET e $_REQUEST (como inclui $_GET ) de $_POST , pois é um pouco mais difícil de gerar, ou seja, manipular, um pedido POST do que um pedido GET . A ênfase aqui é ligeiramente , mas usar o POST para operações sensíveis, pelo menos, remove outra camada de frutas com pouca suspensão para explorar.

Especialmente quando se trata de Cross Site Scripting (ou XSS) e roubo de cookies, é bastante fácil obter o navegador de uma vítima para emitir uma solicitação GET ao servidor em ataque simplesmente inserindo uma imagem oculta com um URL manipulado em uma página ou forjando um link.

Emitir um pedido POST pelo menos requer algum JavaScript, que é um pouco mais difícil de injetar no navegador da vítima para execução (dependendo da situação). Obviamente, os pedidos POST podem ser gerados diretamente pelos atacantes, para que eles também não possam ser confiáveis, mas para cenários em que um invasor está passando por um navegador de terceiros, eles são um pouco mais difíceis de manipular.

A segurança é sempre sobre torná-lo tão difícil quanto possível para quebrar sua aplicação – tendo em consideração as restrições de implementação etc. Nunca pode ser sobre 100% seguro. Portanto, é melhor escolher a alternativa que é mais difícil de explorar, mesmo que a diferença seja marginal , ao ter a escolha entre diferentes abordagens de implementação.

No final, é sempre sobre a remoção de frutas com pouca suspensão. Certamente, os pedidos POST também podem ser manipulados, mas para qualquer operação que tenha um risco elevado, use uma solicitação POST e restrinja-se a usar $_POST em seu código. Dessa forma, você já excluiu alguns ataques drive-by GET muito fáceis e agora pode concentrar-se na validação de seus dados POST. Apenas não suponha que o uso de POST de repente fez a operação segura por padrão.

Certamente, é bom dizer às pessoas que usem $_POST vez de $_REQUEST . É sempre melhor ter mais certeza sobre onde você obtém seus dados.

@Cristão:

Quando falando sobre alguns deles serem mais perigosos do que outros, eu certamente separaria $ _GET e $ _REQUEST (como inclui $ _GET) de $ _POST, pois é um pouco mais difícil de gerar, ou seja, manipular, um pedido POST do que um pedido GET . A ênfase aqui é ligeiramente, mas usar o POST para operações sensíveis, pelo menos, remove outra camada de frutas com pouca suspensão para explorar.

Bzzt. Desculpe, mas isso simplesmente não é verdade.

Qualquer pessoa que entenda a diferença entre o GET e o POST ou a forma como os insumos não podem ser explorados, não hesitarão por um segundo para ativar Tamper Data.

Algumas pessoas têm isso aqui: não há segurança perdida ou obtida usando $ _REQUEST em um sistema bem projetado.

Não há diferença de segurança real entre usar $_POST e $_REQUEST , você deve desinfetar os dados com o mesmo escrutínio.

O maior problema com $_REQUEST é que você pode estar tentando obter dados de um formulário POST, mas pode ter um parâmetro GET com o mesmo nome. De onde virão os dados? É melhor solicitar explicitamente os dados de onde você espera, $_POST nesse exemplo

Existem pequenos benefícios de segurança – é mais fácil realizar ataques XSS (mais especificamente XSRF ) nos parâmetros GET, o que é possível se você usar $_REQUEST , quando você realmente deseja apenas dados POST.

Há poucas situações em que você precisa de dados de POST, GET ou cookie .. Se você deseja obter dados POST, use $_POST , se desejar obter dados dos parâmetros GET, use $_GET , se desejar dados de cookie, use $_COOKIE

A maneira mais segura é verificar e validar os dados. Geralmente, ganho um ID exclusivo random para um formulário e armazená-lo na session do usuário, mas isso é facilmente ignorado por um atacante determinado. Muito melhor é limpar todos os dados recebidos. Confira htmlspecialchars () e sua function relacionada. Eu também uso um utilitário de terceiros para cross-site, como HTML Purfier

Em algumas notas práticas, use sempre intval () o que é suposto ser numérico, escapa de todas as cordas recebidas, use regex para números de telefone, e-mails ou qualquer coisa que fará parte de uma consulta SQL.

Espero que isto ajude.