¿Es suficiente que el método POST sea más seguro que el método GET? Un simple experimento demuestra que no

La frase cierta “el método POST es más seguro que el método GET”, la hemos leído y escuchado decenas de veces y ha sido y es (en mi criterio) culpable desde hace muchos años de que se desarrollen aplicaciones web con prácticas de seguridad deficientes.

Todo parte del hecho de que, entre otras cosas, el método GET envía los datos como parámetros de la URL a la que hace la petición y el método POST lo envía dentro del cuerpo de la petición. Por tanto, si utilizamos el método POST, ni en el historial del navegador web ni en otros sistemas intermedios quedará registrada la URL con los datos de la petición HTTP. El método GET por otra parte es cacheable y el método POST no.

Hasta aquí todo bien y es la explicación normal que podemos encontrar en los libros estándares de programación web. Sin embargo, desde la perspectiva de un ciberdelincuente, la utilización del método POST en lugar del método GET, es tan poco efectiva como un cartel de “No pasar”. ¿Por qué hago esta afirmación? Muy sencillo: que los datos viajen dentro del cuerpo de una petición HTTP no implica que se hayan tomado medidas adicionales por parte del protocolo HTTP para encriptar la información o algo similar (lo que si se logra si se usa HTTPS), por tanto, un atacante solo tiene que observar las tramas de red para detectar y leer la información de su interés.

Para demostrar lo que puede observarse durante una petición POST por un canal inseguro, realicé un experimento usando Kali Linux (Atacante), la máquina virtual del proyecto BWA con una colección de aplicaciones web de pruebas (Aplicación Web) y mi computadora como Cliente. En mi caso usé la aplicación webgoat.net y dentro de ella accedí a la página de autenticación CustomerLogin.aspx.

Lo primero que quisiera llamar la atención es sobre la composición de la petición POST. En la figura 1 podemos observar la información contenida en el encabezado y en el cuerpo, visualizada a través de OWASP ZAP en modo proxy de intercepción.

figura-1-composicion-de-la-peticion-http

Figura 1. Composición de la petición HTTP enviada con el método POST. Elaboración propia.

Puede apreciarse que el parámetro ctl00$BodyContentPlaceholder$txtUserName contiene el nombre de la cuenta de usuario y el parámetro ctl00$BodyContentPlaceholder$txtPassword contiene la contraseña. En este punto estamos viendo la información antes de salir de la computadora del cliente.

A continuación, les muestro las tramas de red que viajan portando la petición HTTP. Para ello utilicé el programa WireShark en modo sniffer (cosa que un ciberdelincuente puede hacer más fácil que reproducir un archivo mp3 de Major Lazer).

Es evidente, en las secciones enmarcadas en cuadrados rojos, como el nombre de la cuenta de usuario y la contraseña pueden ser fácilmente capturados.

figura-2-tramas-capturadas-con-wireshark

Figura 2. Tramas de red capturadas con Wireshark donde se aprecia como la información viaja en texto plano en el cuerpo de la petición POST si no se utiliza HTTPS. Elaboración propia.

Por tanto, queda demostrado que, si un dato viaja en el cuerpo de una petición o respuesta HTTP, brinda una seguridad tan endeble que no vale la pena señalarla en el caso de una aplicación profesional. Por supuesto, el método POST ofrece otras ventajas, por ejemplo, dificulta la inyección de código script en los parámetros de la petición cuando estas viajan en el cuerpo, pero solo es eso, dificulta, no impide que se haga.

Para evitar que esto ocurra, deben enviarse siempre las peticiones por canales seguros, habilitando TLS en el servidor web y asegurándonos que esté presente la política HSTS en el encabezado de las peticiones de respuesta HTTP. Las pruebas de seguridad OTG-CONFIG-007 y OTG-AUTHN-001 de la OTG te ayudarán a conducir una revisión de este aspecto en tu aplicación web.

Espero que te haya servido esta explicación y por favor, si escuchas nuevamente a alguien diciendo que su aplicación web es muy segura porque usa POST en lugar de GET, explícale porque esto no es suficiente. Así estaremos contribuyendo a que nuestros datos viajen más seguros en un futuro cercano.

Espero que te haya gustado la entrada y te pueda ayudar a fortalecer la seguridad en tu aplicación web. Yo por mi parte he disfrutado escribiéndola.

S4lud0s y h4st4 el próx1m0 p0st!!!

Anuncios

Un comentario en “¿Es suficiente que el método POST sea más seguro que el método GET? Un simple experimento demuestra que no

  1. Pingback: Apuntes sobre el Referer spoofing, el Referer spam y otros problemas de seguridad relacionados | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s