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

116

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?

sprugman
fuente
2
Vea preguntas y respuestas relacionadas: stackoverflow.com/questions/1149118/…
Gordon
2
Desde php 5.3, el php.ini predeterminado dice que solo se ingresan datos GET y POST $_REQUEST. Consulte php.net/request_order . Acabo de tropezar con esta ruptura de compatibilidad con versiones anteriores cuando esperaba que hubiera datos de cookies $_REQUESTy me preguntaba por qué no funcionaba. Entonces, la razón más importante para evitar usar $ _REQUEST es ahora que su script no puede configurarse request_ordersolo (lo es PHP_INI_PERDIR), por lo que un cambio de php.ini puede romper fácilmente las suposiciones sobre las que se basa su script. Es mejor poner esas suposiciones directamente en su guión.
Darren Cook

Respuestas:

184

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.

bobince
fuente
2
Estas situaciones (datos demasiado largos para enviarlos a través de GET) son una excepción, no una regla
Ben James
1
Buena respuesta. También noté que con marcos como Zend Framework, los parámetros GET y POST se combinan en 1 objeto de solicitud. Nunca me di cuenta hasta que leí tu publicación.
Jay Sidri
Por defecto, la configuración request_order está establecida en "GP" en php.ini a partir de PHP 5.4+, así que diría que lo haga ... pero como siempre, proceda con precaución.
bcmoney
si $ _POST es a="foo"y $ _COOKIE a="bar", ¿habrá alguna anulación / conflicto aquí?
Rust
75

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.

Gordon
fuente
1
+1 es bueno ver algo de discusión sobre esto ... ¡Pensé que me estaba volviendo loco!
Bobince
2
Creo que esa discusión fue un poco generalizada. El problema real es la falta de conocimiento del desarrollador, no la existencia de cookies en $ _REQUEST per se. El PHPSESSID fijo, por ejemplo, se restablecerá con una cookie por dominio de todos modos con el código de manejo de sesión actual. Y para algunas aplicaciones, una cookie que anule la solicitud vars podría ser realmente deseable (por ejemplo, sort_order = ASC anula un formulario de búsqueda GET var). Aunque codificar tal comportamiento explícitamente es más sensato.
mario
1
Publicación muy completa, esta debería ser la respuesta. Quizás la gente teme una publicación larga;)
Dzung Nguyen
Lamentablemente, Rasmus comentó sobre esto en 2009 y, sin embargo, $ _REQUEST es esencialmente el mismo ahora, en 2015.
Kzqai
10

$_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.).

Luca Matteis
fuente
19
Esta respuesta describe qué es $ _REQUEST, pero no responde a la pregunta.
zombat
1
Él está diciendo que es una mejor práctica saber qué tipo de solicitud sería entrante y codificar esa solicitud específica.
Polaris878
8

$_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.

Liberado
fuente
8

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.

Ben James
fuente
1
pero ¿eso no depende de la implementación? "Indempotente" es una palabra nueva para mí, pero si la entiendo correctamente, sería fácil imaginar el establecimiento de una situación GET que no fuera indempotente. Por ejemplo, los contadores de páginas generalmente aumentan cada vez que solicita una URL determinada.
sprugman
1
@sprugman: también puede tener situaciones en las que tenga datos GET y datos POST en la misma solicitud, en cuyo caso el método de solicitud no tiene sentido cuando se contextualiza con los datos de la solicitud.
zombat
sprugman, obviamente, cualquier solicitud GET modifica algo porque está registrado por el servidor web. Todavía puede ser indempotente en el dominio de la aplicación, donde estos metadatos realmente no importan.
Ben James
@sprugman: la idea general aquí es que no debería tener una solicitud GET que modifique datos. Un ejemplo típico de por qué esto es malo sería una araña web rastreando su sitio y siguiendo enlaces que modifican involuntariamente los datos. Por ejemplo, el enlace "bandera" en una publicación SO.
Eric Petroelje
Ese fue un ejemplo trivial. ¿Qué tal si estoy usando GET a través de ajax porque es más rápido (como se sugiere en esta publicación en carsonified carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post ).
sprugman
7

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.

Sampson
fuente
3

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.

Eric Petroelje
fuente
eso es un terrible error. ¿Cómo se puede garantizar que se realizaron acciones no idempotentes a través de un POST?
Kyle Butt
1
@Kyle: al no usarlo para acciones no idempotentes. Ciertamente no lo usaría para todo, solo señalar que ES útil, como para búsquedas como mencioné en mi ejemplo.
Eric Petroelje
1
Esta idea mágica de que _POST es seguro y _GET no tiene que desaparecer. Si no estoy usando su software correctamente, entonces hay muy poca (si alguna) diferencia para mí entre enviar una solicitud POST frente a una solicitud GET. La seguridad está en lo que haces con los datos, no de dónde provienen. En cuanto a los exploits simples XSS / Request, es muy posible que use _REQUEST solo para valores que serían válidos con POST o GET, y use _POST solo para cosas que deberían ser POST. Sentido común, no uso mágico superglobal.
Lanzado el
1
@Kyle: todavía no veo cómo no pudo hacer lo que menciona con la misma facilidad usando algo como curl () o una publicación ajax para pasar esos mismos datos a través de POST y COOKIE. Ya sea que use REQUEST, GET, POST o COOKIE, todos los datos provienen en última instancia del cliente y siempre pueden ser falsificados.
Eric Petroelje
1
@zombat: La solicitud curl que formule no iniciará sesión como un usuario vulnerable. El enlace que cree y coloque en su sitio lo hará. @Dereleased: No es un pensamiento mágico, y todavía hay muchas vulnerabilidades con GET. pero ES más seguro confiar en un POST de un usuario que ha iniciado sesión que en un GET de un usuario que ha iniciado sesión.
Kyle Butt
2

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.

Kyle Butt
fuente
2

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;)

Jani Hartikainen
fuente
Si bien estoy de acuerdo con usted, creo que es importante señalar por qué esto es cierto y / o peligroso: se debe usar $_POSTcuando es importante que los datos sean POSTDATA. Se debe utilizar $_REQUESTcuando los datos sean independientes del verbo HTTP utilizado. En todos estos casos, se debe desinfectar cuidadosamente todos los datos de entrada.
Lanzado el
1
No veo cómo la fuente de los datos se relaciona con la probabilidad de falsificación de solicitudes entre sitios. Un atacante puede establecer un parámetro POST perfectamente fácilmente proporcionando al usuario un formulario POST dirigido a su sitio; necesitará las mismas medidas de protección anti-XSRF independientemente de si un envío proviene de GET o POST.
Bobince el
Es mucho más fácil abusar de GET por falsificación. Por ejemplo, simplemente puede tener una etiqueta img con su src configurado con los parámetros que desee. Funcionará sin que el usuario sepa que estaba allí.
Jani Hartikainen
0

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.

Brian T Hannan
fuente
¿Qué estás tratando de decir? ¿Estás confundiendo $_REQUESTcon $_SERVER['QUERY_STRING']?
Lanzado el
0

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.

Duncan
fuente
0

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; 
    } 
  }
}
user953985
fuente
0

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"]...

Arjan202
fuente
-1

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.

amh15
fuente
Aquellos que decidan votar en contra, por favor expliquen para mi edificación.
amh15
-2

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.

Stan
fuente
4
No hay diferencia de seguridad entre $ _POST y $ _GET, aparte de que no puede escribir una solicitud POST en la barra de URL del navegador. Sin embargo, solo se necesitan 5 segundos para generar una solicitud cURL de línea de comandos utilizando POST.
zombat
3
@Zombat: Necesitamos iniciar algún tipo de campaña para convencer a la gente de que POST no es intrínsecamente seguro, o incluso más seguro, que GET. La seguridad está en cómo se tratan los datos, no en el verbo HTTP que se utilizó para obtenerlos.
Lanzado el
@Dereleased - Propongo una imagen icónica en dos tonos de una nube con algunos relámpagos para representar Internet, con la palabra "CAMBIO" debajo.
zombat
1
@GuyT: Esa es una visión de mente muy estrecha. No se trata solo de cuán "seguro" es, sino de cuán confidencial es. Los parámetros GET pueden aparecer como autocompletados en la URL del navegador, incluso en el historial del navegador. Además, la seguridad no termina con el navegador. Por ejemplo, muchos servidores registran URL http, por lo que cualquier cosa en la URL se registraría, por ejemplo. Tener un nombre de usuario / contraseña en los registros marca la diferencia. En el lado seguro, siempre evite pasar información confidencial como parámetros GET.
stan
1
Específicamente los registros de acceso de Apache. Se registrará cualquier URL de solicitud, y CUALQUIERA que tenga acceso a los registros podrá ver cómo llegan sus credenciales.
stan