¿Por qué PHPs $ _REQUEST se considera malo?

Question

¿Por qué PHPs $ _REQUEST se considera malo?

#1 de Polynomial (4 votos)

3

De acuerdo con la hoja de trucos PHP de OWASP :

Se desaconseja enfáticamente el uso de $_REQUEST . Este súper global no se recomienda ya que incluye no solo los datos POST y GET, sino también las cookies enviadas por la solicitud. Todos estos datos se combinan en una matriz, lo que hace casi imposible determinar el origen de los datos. Esto puede generar confusión y hace que su código sea propenso a errores, lo que podría ocasionar problemas de seguridad.

Entiendo por qué esto es una mala práctica desde una perspectiva de programación, pero no entiendo las implicaciones de seguridad de esto. Dado que el atacante, la persona que envía la solicitud, tiene control total sobre las tres: obtener variables, publicar variables y cookies, no veo qué diferencia hace.

Un problema que podría ver es si, por ejemplo, un WAF verifica la cadena de consulta en busca de comportamientos sospechosos, por lo que el atacante entrega la carga útil en una cookie. Pero ¿hay otros problemas? ¿Puede alguien darme un ejemplo concreto de cómo el uso de $_REQUEST causaría una vulnerabilidad?

web-application php

pregunta Anders 12.10.2017 - 13:20

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application php

Me conecté a un WiFi aparentemente protegido por contraseña sin dar una contraseña ¿Por qué los nombres de clase deben estar en la lista blanca?

score 4 · Accepted Answer

Esto se debe a que amplía el alcance de XSS reflexivo a las solicitudes POST, ya que la mayoría de los scripts no comprueban explícitamente el verbo HTTP.

Imagina que tienes el siguiente código en un script que normalmente espera una solicitud POST:

<?php
if (($order = $orders->fetch($_REQUEST['id'])) === FALSE)
{
    die('Could not find order number ' . $_REQUEST['id']);
}
...

Si se utilizara $_POST , la vulnerabilidad de XSS seguiría existiendo, pero solo podría ser activada si un usuario va primero a una página controlada por un atacante para que un formulario pueda enviar la vulnerabilidad a través de POST. En su lugar, el atacante solo necesita que la víctima haga clic en un enlace como:

http://example.com/vulnerable.php?id=<script>alert(document.cookie);</script>

También es una preocupación para otros ataques de confusión de verbos, donde dos partes de la secuencia de comandos emiten juicios separados sobre el verbo que se usa (por ejemplo, uno asume que es un GET, el otro un POST) que resulta en un comportamiento inesperado.