Intercambiabilidad POST y POST

Question

Intercambiabilidad POST y POST

#1 de Julie Pelletier (2 votos)
#2 de CtrlDot (1 votos)

1

En algunas aplicaciones, los métodos HTTP GET y POST se pueden usar indistintamente.

Por ejemplo, la aplicación puede esperar una solicitud POST, y la interfaz también enviará los datos en una solicitud POST, pero si la solicitud se modifica, los datos también se aceptarán en una solicitud GET.

Un ejemplo de este comportamiento sería Javas getParameter o PHPs $_REQUEST , que entregan parámetros GET y POST.

¿Esto generalmente se considera un problema de seguridad? ¿Está documentado en algún lugar, por ejemplo, como un CWE o por OWASP?
¿Este problema tiene un nombre?
¿Cuáles son los peligros de POST para obtener una rebaja? Un ejemplo que podría pensar sería la posibilidad de explotar los problemas de CSRF a través de las etiquetas img , lo que significa que un atacante puede colocar las cargas útiles de CSRF en sitios web donde no pueden publicar scripts, lo que facilita considerablemente la explotación del problema. ¿Hay otros beneficios para los atacantes?
¿Cuáles son, si los hay, los peligros de GET para POST cambiar?

web-application vulnerability http

pregunta tim 30.07.2016 - 16:16

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application vulnerability http

Riesgo de seguridad de un servicio que permite a un usuario probar la conectividad de un servidor a una impresora Detección de fraude para evitar usuarios falsos

score 2 · Answer 1

Es una mala práctica ya que hace que el desarrollo sea más confuso para garantizar que no haya superposición entre los posibles parámetros GET y POST que normalmente se procesan por separado.

También hace que sea un poco más fácil para un pirata informático beneficiarse de una vulnerabilidad en su sitio, pero no crea violaciones por sí solo.

En una aplicación web bien organizada, los parámetros GET se usan para enrutamiento (selección de página o módulo y opciones relevantes), mientras que los parámetros POST en realidad representan datos enviados por el usuario. Seguir esta sencilla guía hace que el desarrollo sea mucho más organizado, por lo que es más seguro evitar errores en su final.

score 1 · Answer 2

El OWASP ASVS hace mención de esta vulnerabilidad, ver la regla 11.1. Si bien no hace mención de esta vulnerabilidad en el nivel de método, alude a que la aplicación solo debe aceptar conjuntos definidos de métodos de solicitud HTTP.

Generalmente llevo esto un poco más lejos y vinculo la guía con la OWASP Proyecto AppSensor donde puede utilizar estos cambios en los verbos HTTP esperados como un posible punto de detección.

No creo que exista ningún peligro real de una POST para obtener una degradación desde la perspectiva del servidor. Mientras esté protegiendo contra la contaminación por parámetros, y esté monitoreando el tráfico desde la perspectiva de un appensor, no habrá daños. Obviamente, GET se pasa en la cadena de consulta y es registrado por otros dispositivos en la cadena. Este es un problema del lado del cliente IMHO y solo podría suceder si su código (formularios, html, javascript) se cambiara (ya sea a través de MITM o vía javascript incorrecto después del procesamiento).