Soy consciente de que las solicitudes HTTP GET se envían al servidor web utilizando el par de nombre / valor de cadena de consulta en la URL. Esto significa que uno puede pasar datos personalizados a un servidor web. Por ejemplo, http://some_site.com.br/some-page.asp?name=custom_data .
¿Hay otros tipos de solicitud HTTP que se envían de esta forma en la URL? Por lo que sé, por ejemplo, las solicitudes HTTP POST tienen datos personalizados en la carga útil.
Como dice @Philipp, cualquier URI puede tener una cadena de consulta, independientemente del método HTTP (GET, POST, PUT, ...) con el que se usa.
En general, las RFC no discuten explícitamente las cadenas de consulta, incluso cuando se discuten métodos como GET donde esperamos verlos. Una mención explícita rara está en RFC 2068 :
algunas aplicaciones han usado tradicionalmente GET y HEAD con consulta URL (aquellas que contienen un "?" En la parte rel_path)
Es posible que desee seguir los enlaces de RFC 7237 , que enumera una serie de métodos HTTP no tradicionales, para ver si alguno describe explícitamente su manejo de los parámetros de cadena de consulta; Revisé algunos y no encontré una discusión explícita.
Ahora, dicho todo esto, hay un par de problemas de seguridad que se relacionan con esta imprecisión.
Uso inapropiado
Hay ocasiones en que los parámetros de la cadena de consulta no son adecuados; por ejemplo, considere RFC 2616 :
Los autores de servicios que utilizan el protocolo HTTP NO DEBEN usar GET formularios basados en la presentación de datos confidenciales, ya que esto hacer que estos datos se codifiquen en el URI de solicitud. Muchos existentes los servidores, proxies y agentes de usuario registrarán el URI de solicitud en algunos Lugar donde pueda ser visible para terceros. Los servidores pueden usar Envío de formulario basado en POST en su lugar.
Esto es bueno ... pero las cadenas de consulta no están prohibidas en las solicitudes POST, simplemente no se espera . Como resultado, algunos servidores web (Tomcat, por ejemplo, y programas PHP que usan $_REQUEST ) llevará silenciosamente todos los parámetros a un POST, ya sea que estén en la cadena de consulta o en el cuerpo, y los hará accesibles a la aplicación como parámetros de entrada. He visto un caso en el que un formulario POST funcionó bastante bien cuando se alimentaron los parámetros de la cadena de consulta durante meses antes de que alguien se diera cuenta de que estaba ocurriendo (y que se estaba registrando información confidencial que no debería).
Cache-busting
Una cosa que algunas aplicaciones harán es agregue una cadena de consulta falsa a las solicitudes como una forma de garantizar que obtengan contenido nuevo y sin caché . Debido a que el servidor generalmente ignora las cadenas de consulta que no espera, la aplicación cliente puede hacer esto de manera segura.
La excepción es cuando existen controles estrictos, como un Firewall de aplicaciones web, que consideran cadenas de consulta desconocidas o inesperadas como signos de un escaneo o ataque malicioso. Si el WAF sabe que /foo/bar no debe tener parámetros de cadena de consulta, y entra una solicitud para el /foo/bar?_fresh=20150819 , el WAF puede bloquear esa solicitud.
En resumen, la holgura que permite que las cadenas de consulta en lugares y URI no se anticipen significa que la restricción de los controles de seguridad puede bloquear la funcionalidad como efecto secundario.
Ambigüedad general
Esto es realmente un superconjunto de los otros problemas, pero la falta de reglas bien definidas sobre cuándo una cadena de consulta puede o no ser utilizada significa que se introducen problemas de seguridad. Debido a que cada servidor puede elegir manejar cadenas de consulta en lugares extraños de manera diferente, el profesional de la seguridad no puede predecir el modelo de amenaza sin probar para ver cómo funcionan las cosas en su configuración, e incluso entonces esas pruebas generalmente están incompletas (por ejemplo, es difícil pensar de cada cosa loca que un atacante podría hacer con cadenas de consulta). Si existieran reglas estrictas y rápidas ("las cadenas de consulta no están permitidas en las solicitudes POST"), esto sería más fácil.
la famosa pauta de Jon Postel para los protocolos de Internet:
Sea liberal en lo que acepta, y conservador en lo que envía
Es bueno para la interoperabilidad, pero malo para la seguridad. Cuanto más liberal sea un sistema para aceptar insumos, es probable que se introduzcan más problemas de seguridad. Y en el caso de cadenas de consulta en métodos HTTP, los RFC terminan dejando una ambigüedad que requiere interpretaciones del sistema muy liberales.
De acuerdo con RFC 3986 - Identificador de recursos uniforme las componente de consulta está permitido para cualquier URI independientemente del protocolo utilizado. Eso significa que no solo está permitido para cualquier método HTTP (lo que usted llama "tipo de solicitud"), sino también para cualquier otro protocolo que use URI, como por ejemplo ftp.
Lea otras preguntas en las etiquetas web-application http