DVWA. XSS reflected.

Buenas amigos !

Volvemos con otra entrada en el blog, vamos a continuar con el DVWA, ya explicamos el SQL Injection, esta vez vamos a ver otra de las vulnerabilidades más peligrosas que podemos encontrar en un servidor, el XSS, en este caso el XSS Reflected o reflejado.

El XSS o Cross-site scripting es un tipo ataque típico de las aplicaciones Web, que permite a una tercera persona inyectar en páginas web visitadas por el usuario código JavaScript o en otro lenguaje similar.

La forma conocida como reflejada comúnmente se produce en sitios que reciben información vía GET (aunque también puede darse el caso vía POST), como por ejemplo: buscador.php?d=cadena_a_buscar.

Si sufriera este tipo de vulnerabilidad se podría inyectar código en el navegador del siguiente modo: buscar.php?d=< script type =”text/javascript “ > script () ; < / script >

De esta forma el código insertado no se mostraría de forma persistente, pero aun así un usuario malintencionado podría crear una URL que ejecute el código malicioso para posteriormente enviárselo a una persona y que al ejecutarlo ésta pueda sustraer cookies o incluso su contraseña (Pishing).

Vayamos al DVWA y lo ponemos en low y vemos el código.

Esta porción de código sólo valida que el nombre introducido no sea una cadena vacía.

Vemos que tenemos una caja de texto que nos pide nuestro nombre, vamos a ponerlo y vemos que ocurre:

Vemos que aparte de imprimirlo debajo de la pantalla, también lo reproduce en la URL. Vamos a inyectar código en la caja de texto, en este caso un alert, que es comando para sacar por pantalla, el echo de PHP<Script>

Vamos un paso más allá, podemos hacer sacar la cookie para hacer un robo de sesión y entrar como otro usuario. Para ello pondremos :

<script>alert(document.cookie)</script>

Vamos a subirlo a nivel médium y vemos el código.

El código es exactamente igual, sólo que se añade un str_replace que hace que cuando se encuentre un <script> lo reemplace por una cadena vacia, comprobemos que es verdad:

Vemos que solo está filtrado la <script> …. Pero si pensamos, podemos utilizar <SCRIPT>

Si intentamos hacer lo mismo con el robo de cookie, pasará exactamente lo mismo.

Conclusión

Para evitar este tipo de vulnerabilidad se recomienda filtrar siempre la información procedente del usuario antes de hacer uso de ella. Generalmente con filtrar los caracteres “ <> “sería suficiente, aunque se recomienda también filtrar los nombres de las etiquetas que pueden resultar peligrosas en este tipo de ataque como:

<script>,<object>, <applet>, <embed>, <form>, etc