¿Qué tiene de malo usar $ _REQUEST []?

He visto una serie de publicaciones aquí que dicen que no use la $_REQUESTvariable. Normalmente no lo hago, pero a veces es conveniente. ¿Qué tiene de malo?

No hay absolutamente nada de malo en recibir información de ambos $_GETy $_POSTde forma combinada. De hecho, eso es lo que casi siempre quieres hacer:

• para una solicitud idempotente simple que generalmente se envía a través de GET, existe la posibilidad de que la cantidad de datos que desea no quepan en una URL, por lo que se ha mutado a una solicitud POST como una cuestión práctica.

• para una solicitud que tenga un efecto real, debe verificar que se envíe mediante el método POST. Pero la forma de hacerlo es verificar $_SERVER['REQUEST_METHOD']explícitamente, no confiar en $_POSTestar vacío para un GET. Y de todos modos, si el método es POST, es posible que desee eliminar algunos parámetros de consulta de la URL.

No, el problema $_REQUESTno tiene nada que ver con la combinación de parámetros GET y POST. Es que también, por defecto, incluye $_COOKIE. Y las cookies no son en absoluto como parámetros de envío de formularios: casi nunca querrá tratarlas como lo mismo.

Si accidentalmente obtiene una cookie configurada en su sitio con el mismo nombre que uno de los parámetros de su formulario, entonces los formularios que dependen de ese parámetro dejarán de funcionar misteriosamente debido a que los valores de las cookies anulan los parámetros esperados. Esto es muy fácil de hacer si tiene varias aplicaciones en el mismo sitio, y puede ser muy difícil de depurar cuando solo tiene un par de usuarios con cookies antiguas que ya no usa merodeando y rompiendo los formularios de maneras que no -alguien más puede reproducirse.

Puede cambiar este comportamiento al orden mucho más sensato GP(no C) con la configuración request_order en PHP 5.3. Cuando esto no sea posible, personalmente evitaría $_REQUESTy, si necesitaba una matriz combinada GET + POST, la crearía manualmente.

He estado investigando algunas publicaciones de grupos de noticias sobre PHP Internals y encontré una discusión interesante sobre el tema. El hilo inicial fue sobre otra cosa, pero un comentario de Stefan Esser, un (si no el ) experto en seguridad en el mundo PHP, giró la discusión hacia las implicaciones de seguridad de usar $ _REQUEST para algunas publicaciones.

Citando a Stefan Esser en PHP Internals

$ _REQUEST es una de las mayores debilidades de diseño de PHP. Todas las aplicaciones que utilizan $ _REQUEST son probablemente vulnerables a problemas de falsificación de solicitudes entre sitios retrasados. (Esto básicamente significa que, por ejemplo, si existe una cookie llamada (edad), siempre sobrescribirá el contenido GET / POST y, por lo tanto, se realizarán solicitudes no deseadas)

y en una respuesta posterior al mismo hilo

No se trata del hecho de que alguien pueda falsificar GET, POST; Variables COOKIE. Se trata del hecho de que las COOKIE sobrescribirán los datos GET y POST en REQUEST.

Por lo tanto, podría infectar su navegador con una cookie que diga, por ejemplo, acción = cerrar sesión y a partir de ese día ya no podrá usar la aplicación porque REQUEST [acción] se cerrará para siempre (hasta que elimine manualmente la cookie).

E infectarlo con una COOKIE es tan simple ...
a) Podría usar un vuln XSS en cualquier aplicación en un subdominio
b) ¿Alguna vez intentó configurar una cookie para * .co.uk o * .co.kr cuando tiene un dominio único allí?
c) Otros dominios cruzados de cualquier forma ...

Y si cree que esto no es un problema, puedo decirle que existe una posibilidad simple de configurar fe una cookie * .co.kr que da como resultado que varias versiones de PHP solo devuelvan páginas en blanco. Imagínese: una sola cookie para eliminar todas las páginas PHP en * .co.kr

Y al establecer un ID de sesión ilegal en una cookie válida para * .co.kr en una variable llamada + PHPSESSID = ilegal , aún puede DOS cada aplicación PHP en Corea usando sesiones PHP ...

La discusión continúa para algunas publicaciones más y es interesante de leer.

Como puede ver, el principal problema con $ _REQUEST no es tanto que tenga datos de $ _GET y $ _POST, sino también de $ _COOKIE. Algunos otros chicos de la lista sugirieron cambiar el orden en el que se llena $ _REQUEST, por ejemplo, llenarlo con $ _COOKIE primero, pero esto podría llevar a muchos otros problemas potenciales, por ejemplo, con el manejo de la sesión .

Sin embargo, puede omitir completamente $ _COOKIES del $ _REQUEST global, para que ninguna de las otras matrices lo sobrescriba (de hecho, puede limitarlo a cualquier combinación de sus contenidos estándar, como el manual de PHP en la configuración ini de variable_order Cuéntanos:

variable_order Establece el orden del análisis de la variable EGPCS (Entorno, Obtener, Publicar, Cookie y Servidor). Por ejemplo, si variables_order se establece en "SP", PHP creará las superglobales $ _SERVER y $ _POST, pero no creará $ _ENV, $ _GET y $ _COOKIE. Establecer en "" significa que no se establecerán superglobales.

Pero, de nuevo, también podría considerar no usar $ _REQUEST por completo, simplemente porque en PHP puede acceder a Environment, Get, Post, Cookie y Server en sus propios globales y tener un vector de ataque menos. Aún tiene que desinfectar estos datos, pero es una cosa menos de la que preocuparse.

Ahora puede que se pregunte por qué existe $ _REQUEST después de todo y por qué no se elimina. Esto también se preguntó en PHP Internals. Citando a Rasmus Lerdorf sobre ¿Por qué existe $ _REQUEST? en PHP Internals

Cuantas más cosas como esta eliminemos, más difícil será para las personas pasar rápidamente a versiones más nuevas, más rápidas y más seguras de PHP. Eso causa mucha más frustración para todos que unas pocas funciones heredadas "feas". Si hay una razón técnica, un rendimiento o una seguridad decentes, debemos analizarlo detenidamente. En este caso, lo que deberíamos analizar no es si deberíamos eliminar $ _REQUEST, sino si deberíamos eliminar los datos de las cookies. Muchas configuraciones ya hacen eso, incluida la mía propia, y hay una razón de seguridad válida y sólida para no incluir cookies en $ _REQUEST. La mayoría de la gente usa $ _REQUEST para referirse a GET o POST, sin darse cuenta de que también podría contener cookies y, como tal, los malos podrían potencialmente hacer algunos trucos de inyección de cookies y romper aplicaciones ingenuas.

De todos modos, espero que arroje algo de luz.

$_REQUESTse refiere a todo tipo de solicitudes (GET, POST, etc.). Esto a veces es útil, pero generalmente es mejor especificar el método exacto ($ _GET, $ _POST, etc.).

$_REQUEST generalmente se considera dañino por la misma razón que las transformaciones de datos de complejidad simple a mediana a menudo se realizan en el código de la aplicación en lugar de declararse en SQL: algunos programadores apestan.

Como tal, si uno tiende a usar en $_REQUESTtodas partes, puedo hacer cualquier cosa a través de GET que pueda a través de POST, lo que significa configurar <img>etiquetas en mi sitio (malicioso) que hacen que los usuarios que inician sesión en su módulo de comercio electrónico compren productos en silencio, o yo puede hacer que hagan clic en enlaces que resultarán en acciones peligrosas o la revelación de información confidencial (probablemente para mí).

Sin embargo, esto se debe a que un programador PHP novato, o al menos sin experiencia, comete errores simples. En primer lugar, sepa cuándo los datos de qué tipo son apropiados. Por ejemplo, tengo un servicio web que puede devolver respuestas en URLEncoding, XML o JSON. La aplicación decide cómo formatear la respuesta verificando el encabezado HTTP_ACCEPT, pero se puede forzar a uno específicamente enviando el formatparámetro.

Al verificar el contenido del parámetro de formato, podría enviarse a través de una cadena de consulta o un postdata, dependiendo de una multitud de factores, uno de los cuales es si las aplicaciones que llaman quieren o no "& format = json" mezclado con su solicitud. En este caso, $_REQUESTes muy conveniente porque me ahorra tener que escribir algo como esto:

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

No voy a divagar mucho más, pero basta con decir que el $_REQUESTuso no se disuade porque es inherentemente peligroso; es solo otra herramienta que hace exactamente lo que se le pide, ya sea que comprenda esas implicaciones o no, es el Decisión deficiente, perezosa o desinformada de un programador pobre, perezoso o sin experiencia que causa este problema.

Cómo utilizar de $_REQUESTforma segura

1. Conozca sus datos : debe tener alguna expectativa sobre qué tipo de datos obtendrá, así que desinfecte en consecuencia. ¿Datos para una base de datos? addslashes()o *_escape_string(). ¿Vas a mostrárselo al usuario? htmlentities()o htmlspecialchars(). ¿Espera datos numéricos? is_numeric()o ctype_digit(). De hecho, filter_input()y sus funciones relacionadas están diseñadas para no hacer más que verificar y desinfectar los datos. Utilice estas herramientas siempre.
2. No acceda directamente a los datos de superglobales proporcionados por el usuario . Adquiera el hábito de desinfectar sus datos, cada vez, y mueva sus datos a variables limpias, incluso si es justo $post_clean. Alternativamente, puede limpiar directamente en las superglobales, pero la razón por la que defiendo el uso de una variable separada es porque hacerlo facilita la detección de vulnerabilidades en el código, ya que cualquier cosa que apunte directamente a una superglobal y no a su equivalente desinfectado se considera un error peligroso. .
3. Sepa de dónde deberían provenir sus datos. Haciendo referencia a mi ejemplo anterior, es perfectamente razonable permitir que la variable de formato de respuesta se envíe a través de GET o POST. También permito que la variable "acción" se envíe a través de cualquiera de los métodos. Sin embargo, las acciones en sí tienen requisitos muy específicos en cuanto a qué verbo HTTP es aceptable . Las funciones, por ejemplo, que realizan cambios en los datos utilizados por el servicio solo pueden enviarse a través de POST. Las solicitudes de ciertos tipos de datos sin privilegios o sin privilegios (como imágenes de mapas generadas dinámicamente) se pueden atender en respuesta a solicitudes de cualquiera de los métodos.

En conclusión, recuerda esta sencilla regla:

¡LA SEGURIDAD ES LO QUE USTED HACE, GENTE!

EDITAR:

Yo fuertemente recomiendo el consejo de bobince: si se puede, establecer el request_orderparámetro en php.ini para "GP"; es decir, ningún componente de cookie. Casi no hay un razonamiento racional para esto en el 98% + de los casos, ya que los datos de las cookies casi nunca deben considerarse comparables con la cadena de consulta o con los datos posteriores.

PD: ¡Anécdota!

Conocí a un programador que pensó en $_REQUESTun lugar para simplemente almacenar datos que fueran accesibles de una manera superglobal. Nombres de usuario y contraseñas importantes, rutas de acceso a archivos, el nombre y se almacenó en $_REQUEST. Se sorprendió un poco (aunque no de manera cómica, lamentablemente) cuando le dije cómo se comportaba esa variable. No hace falta decir que esa práctica ha sido destituida.

Las solicitudes GET deben ser idempotentes y las solicitudes POST generalmente no lo son. Esto significa que los datos en $_GETy $_POSTgeneralmente deben usarse de diferentes maneras.

Si su aplicación está utilizando datos de $_REQUEST, se comportará de la misma manera para las solicitudes GET y POST, lo que viola la idempotencia de GET.

Es vago. Realmente no sabe cómo llegaron los datos, ya que contienen datos de publicación, obtención y cookies. No creo necesariamente que eso sea siempre algo malo, a menos que necesite conocer o restringir el método de entrega.

De hecho, me gusta usarlo. Le brinda la flexibilidad de usar GET o POST, lo que puede ser útil para cosas como formularios de búsqueda donde la mayoría de las veces se publican datos, pero a veces querrá decir un enlace a una búsqueda en particular, por lo que puede usar los parámetros GET en su lugar .

Además, si observa muchos otros lenguajes (ASP.NET por ejemplo), no hacen ninguna distinción entre las variables GET y POST en absoluto.

ETA :

Nunca he usado REQUEST para obtener valores de COOKIE, pero creo que Kyle Butt hace un gran punto en los comentarios de esta publicación sobre eso. NO es una buena idea utilizar REQUEST para obtener valores de COOKIE. Creo que tiene razón en que existe un potencial real de falsificación de solicitudes entre sitios si lo hace.

Además, el orden en el que se cargan las cosas en REQUEST está controlado por los parámetros de configuración en php.ini (variables_order y request_order). Entonces, si tiene la misma variable pasada a través de POST y GET, cuál ingresa realmente en REQUEST depende de esas configuraciones ini. Esto podría afectar la portabilidad si depende de un pedido en particular y esos ajustes están configurados de manera diferente a lo esperado.

Es importante comprender cuándo usar POST, cuándo usar GET y cuándo usar una cookie. Con $ _REQUEST, el valor que está buscando podría provenir de cualquiera de ellos. Si espera obtener el valor de un POST o un GET o de una COOKIE, es más informativo que alguien que lea su código use la variable específica en lugar de $ _REQUEST.

Alguien más señaló también que no desea que todos los POST o cookies sean anulados por GET porque existen diferentes reglas entre sitios para todos ellos, por ejemplo, si devuelve datos ajax mientras usa $ _REQUEST, es vulnerable a un ataque de script entre sitios.

La única vez $_REQUESTque no es mala idea usarlo es con GET.

• Si lo usa para cargar valores POST, corre el riesgo de falsificaciones de solicitudes entre sitios
• Si lo usa para cargar valores de cookies, nuevamente corre el riesgo de falsificaciones de solicitudes entre sitios.

E incluso con GET, $_GETes más corto de escribir que $_REQUEST;)

Es posible que se use solo si desea recuperar la URL actual o el nombre de host, pero para analizar datos de esa URL, como los parámetros que usan el símbolo &, probablemente no sea una buena idea. En general, no desea utilizar una descripción vaga de lo que está intentando hacer. Si necesita ser específico, ahí es donde $ _REQUEST es malo, si no necesita ser específico, no dude en usarlo. Pensaría.

Si sabe qué datos desea, debe solicitarlos explícitamente. En mi opinión, GET y POST son dos animales diferentes y no puedo pensar en una buena razón por la que alguna vez necesitarías mezclar datos de publicación y cadenas de consulta. Si alguien tiene uno, me interesaría.

Puede ser conveniente usar $ _REQUEST cuando sus scripts puedan responder a GET o POST de la misma manera. Sin embargo, yo diría que este debería ser un caso extremadamente raro, y en la mayoría de los casos se prefieren dos funciones separadas para manejar dos conceptos separados, o al menos verificar el método y seleccionar las variables correctas. El flujo del programa suele ser mucho más fácil de seguir cuando no es necesario hacer referencias cruzadas de dónde podrían provenir las variables. Sea amable con la persona que debe mantener su código en 6 meses. Podría ser tu.

Además de los problemas de seguridad y las WTF causadas por las cookies y las variables de entorno en la variable REQUEST (no me refiero a GLOBAL), considere lo que podría suceder en el futuro si PHP comenzara a admitir de forma nativa otros métodos como PUT y DELETE. Si bien es extremadamente poco probable que se fusionen en la superglobal REQUEST, es posible que se incluyan como opción en la configuración de variable_order. Por lo tanto, realmente no tiene idea alguna de lo que REQUEST tiene y qué tiene prioridad, particularmente si su código se implementa en un servidor de terceros.

¿POST es más seguro que GET? Realmente no. Es mejor usar GET cuando sea práctico porque es más fácil ver en sus registros cómo se explota su aplicación cuando es atacada. POST es mejor para las operaciones que afectan el estado del dominio porque las arañas generalmente no las siguen y los mecanismos de búsqueda predictiva no eliminarán todo su contenido cuando inicie sesión en su CMS. Sin embargo, la pregunta no era sobre los méritos de GET vs POST, se trataba de cómo el receptor debería tratar los datos entrantes y por qué es malo fusionarlos, así que esto es realmente solo un BTW.

Creo que no hay problema con $_REQUEST , pero debemos tener cuidado al usarlo ya que es una colección de variables de 3 fuentes (GPC).

Supongo $_REQUESTque todavía está disponible para hacer que los programas antiguos sean compatibles con las nuevas versiones de php, pero si comenzamos nuevos proyectos (incluidas nuevas bibliotecas), creo que no deberíamos usar $_REQUESTmás para que los programas sean más claros. Incluso deberíamos considerar eliminar los usos de $_REQUESTy reemplazarlo con una función contenedora para hacer que el programa sea más liviano, especialmente en el procesamiento de datos de texto enviados de gran tamaño, ya que $_REQUESTcontiene copias 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; 
    } 
  }
}

Darren Cook: "Dado que php 5.3, el php.ini predeterminado dice que solo se ingresan datos GET y POST $_REQUEST. Ver php.net/request_order Me encontré con esta ruptura de compatibilidad con versiones anteriores cuando esperaba que hubiera datos de cookies $_REQUESTy me preguntaba por qué no estaba ¡Funciona! "

Vaya ... acabo de que algunos de mis scripts dejaran de funcionar debido a una actualización a PHP 5.3 . Hizo lo mismo: suponga que las cookies se establecerían al usar la $_REQUESTvariable. Con la actualización exactamente eso dejó de funcionar.

Ahora llamo a los valores de las cookies por separado usando $_COOKIE["Cookie_name"]...

El problema central es que contiene cookies, como han dicho otros.

En PHP 7 puede hacer esto:

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

Esto evita el problema de las cookies y, en el peor de los casos, le proporciona una matriz vacía y, en el mejor de los casos, una fusión de $ _GET y $ _POST con la última teniendo prioridad. Si no le molesta demasiado permitir la inyección URL de parámetros a través de la cadena de consulta, es muy conveniente.

Es muy inseguro. También es incómodo ya que no sabe si está recibiendo un POST o un GET, u otra solicitud. Realmente debería conocer la diferencia entre ellos al diseñar sus aplicaciones. GET es muy inseguro, ya que se pasa en la URL y no es adecuado para casi nada más que para la navegación de páginas. POST, aunque tampoco es seguro por sí mismo, proporciona un nivel de seguridad.