XSS usando el método POST
Por si no lo recuerdan, todos los ataques explicados en el artículo
anterior se basaban en el método HTTP GET, sacando el caso del XSS
persistente. La razón de esto es que las variables usando el método GET
van en la URL, por lo que para realizar el ataque sólo es necesario que
el usuario abra un link armado por el atacante.
Para refrescar un poco la memoria, tomen en cuenta el ejemplo donde el
script imprimía todo lo pasado por parámetro. Si el parámetro se envía
con el método GET, el atacante sólo debería armar una URL del estilo
http://www.ejemplo.com/vulnerable.php?param=<SCRIPT>alert(‘XSS’);</SCRIPT>
Ahora piensen en el método HTTP POST. Cuando se usa POST las
variables van dentro del cuerpo del mensaje HTTP. Para el que no conozca
HTTP, el protocolo cuenta con dos partes, un HEADER donde van distintos
parámetros (como la URL que solicitamos y los parámetros GET, el tipo
de browser, el sistema operativo, el tipo del mensaje, las cookies,
etc), y el CONTENIDO (donde va la página -html,img,xml,etc- en si, o los
parámetros POST). El que se encarga de manejar el protocolo del lado
del cliente es el browser, el cual arma los paquetes HTTP. Para un
usuario es fácil manipular los parámetros GET porque van en la URL, pero
no es tan simple manipular los parámetros POST.
Un pedido POST no se puede armar con los parámetros en la URL, así
que necesitamos de un formulario. Pero cómo utilizamos un formulario en
un ataque XSS no persistente? La respuesta es, usando una página
intermedia.
Una vez que el atacante descubre una vulnerabilidad XSS en un parámetro
POST de una página www.buenovulnerable.com/vulnerable.php, éste arma un
formulario en una página que puede modificar (ya sea en un servidor
propio o uno hackeado, pero no viene al caso) como ser
www.malomalo.com/xsspost.php. Lo que hace a continuación es enviar al
usuario víctima la URL de su página con algún texto que lo incite a
visitarla. Cuando el usuario ingresa en www.malomalo.com/xsspost.php,
ésta automáticamente envía los parámetros armados por el atacante a
www.buenovulnerable.com/vulnerable.php la cual ahora contiene código de
atacante (inyectado por XSS a través del método POST). Si el usuario
estaba logueado, o utilizando la página www.buenovulnerable.com, el
atacante podrá obtener cookies u otra información.
