¿Qué tan malo es $ _REQUEST y cuáles son algunas contramedidas aceptables de Band-Aid?

Question

Recientemente me he encontrado con un par de respuestas populares relacionadas con PHP que sugirieron usar el superglobal $_REQUEST, que considero un olor a código, porque me recuerda a register_globals.

¿Puede proporcionar una buena explicación/evidencia de por qué $_REQUEST es una mala práctica? Voy a arrojar un par de ejemplos que he desenterrado, y me gustaría más información/perspectiva sobre vectores de ataque teóricos y exploits del mundo real, así como sugerencias de pasos razonables que el administrador de sistemas puede tomar para reducir el riesgo (menos de reescribiendo la aplicación ... o, ¿tenemos necesidad de para ir a la gestión e insistir en una reescritura?).

Ejemplo vulnerabilidades: predeterminados GPC matriz de mezcla de orden significa que los valores de cookie anulan GET y POST, por lo $_REQUEST puede ser utilizado para ataques XSS y HTTP. PHP permite que las cookies vars sobrescriban las matrices superglobales. Las primeras 10 diapositivas de this talk dan ejemplos (toda la charla es genial). phpMyAdmin exploit ejemplo de ataque CSRF.

Ejemplo contramedidas: Reconfigurar $_REQUEST matriz de mezcla de orden de GPC a CGP así GET/POST sobrescribir galleta, no al revés. Use Suhosin para bloquear la sobrescritura de superglobales.

(Además, no estaría preguntando si pensaba que mi pregunta era una víctima, pero afortunadamente la inmensa SO responder a "When and why should $_REQUEST be used instead of $_GET/$_POST/$_COOKIE?" fue "Nunca.")

Answer 1

Su vulnerables a nada pasó en la URL. Por lo tanto, si un formulario contiene un campo oculto con el "ID de usuario" que se envió con el formulario, aunque en teoría el usuario no puede editarlo, no hay nada que lo detenga, cambie el valor si es lo suficientemente claro.

Si solo desea obtener el valor de la solicitud, está bien, pero debe tener en cuenta que puede ser falso, por lo que debe actuar en consecuencia, y ciertamente no utilizarlo para el parámetro/valor seguro datos.

Answer 2

Simplemente trátelo tal como es: un método para obtener datos del usuario. Tiene que ser sanitizado y validado, entonces, ¿por qué te importa si se trata de un POST, un GET o una cookie? Todos provienen del usuario, por lo que dicen '¡pueden ser engañados!' es superfluo

Answer 3

$ _REQUEST es un mal como $ _GET, $ _POST y $ _COOKIE. Si bien creo que hay escenarios válidos para usar $ _REQUEST pero hay una buena razón para no usar $ _REQUEST y etiquetarlo como "mala práctica".

La razón principal por la que se usa $ _REQUEST es que el parámetro se puede transferir en $ _POST o $ _GET. Al acceder a $ _REQUEST no tiene que comprobar $ _GET y $ _POST si el valor está establecido. El problema es que la configuración de ini gpc_order puede cambiar el comportamiento de compilación de $ _REQUEST. Esta configuración puede variar de un servidor a otro y su script puede cambiar el comportamiento.

Answer 4

$_REQUEST es problemático porque ignora la diferencia entre la URL ($_GET) y el cuerpo de la solicitud ($_POST). Una solicitud HTTP-GET no debe tener efectos secundarios, mientras que un HTTP-POST puede tener efectos secundarios y, por lo tanto, no se puede almacenar en caché. Al lanzar estas fuentes de datos completamente diferentes en un solo contenedor, se requieren aplicaciones que no son REST -ful, es decir, malas aplicaciones.