Evitando filtros anti-XSS

Esta entrada se va a centrar en cómo evitar filtros para evitar ataques XSS (Cross Site Scripting). Para ello, se va a tomar como plataforma de pruebas DVWA, ya saben para no meterse en líos Como ya sabéis para instalar DVWA, nos monta la máquina virtual y le metemos la iso de DVWA (https://github.com/nightmare-rg/dvwa-vagrant/tree/master/dvwa-1.0.8)

Seleccionando la opción de XSS reflected y ajustando el nivel de dificultad, tenemos todo listo para empezar:

Nivel low

En el nivel “low” el servidor web no aplica ningún tipo de validación de los parámetros de entrada por lo que introduciendo la típica cadena

<script>alert(“XSS”)</script>

visualizamos el alert verificando que es vulnerable.

Una vez que se ha visto que es vulnerable, se examina el código que como se dedujo, no existe ningún mecanismo de validación de entrada:

Recomendaciones:

Para evitar todo tipo de inyección nunca se debe confiar de datos o fuentes externas y validar todo sin suponer nada, por ejemplo, que los datos esperados son los que el usuario va a introducir.

Para ello, se debe validar todos los datos de entrada, escapar o filtrar los datos no permitidos y opcionalmente sanearlos. Sin embargo, el saneamiento de datos es opcional puesto si la aplicación recibe datos que no debería podría rechazarlos y enviar un mensaje de error para que el usuario los introduzca correctamente para ser aceptados.

En este caso, en PHP se tiene una función para filtrar etiquetas no permitidas como /, <, </, script,…. Esta función es script_tags

Otra función útil para escapar los datos de entrada antes de ser mostrados cuando el código de entrada esperado es HTML es htmlspecialchars.

Del mismo modo, se debería emplear la función trim que elimina caracteres especiales de inicio o final de la cadena sustituyéndolo por espacios en blanco. Por ejemplo, elimina tnr/

Nivel medium

Introduciendo el mismo código, ya no se ejecuta, por lo tanto, se puede deducir que se están aplicando mecanismos de validación de los parámetros de entrada.

Por lo tanto, para detectar que keywords está se realiza una batería de pruebas para identificar los posibles parámetros “prohibidos” para de esta manera, poder evitarlos.

Entrada	Salida
script	Hello script
<script>	hello
script>	Hello script> — Este es bueno!
<script	hello
<<script>>	Hello <> — Filtra keyword script

Como se observa está filtrando el keyworsd “<script>”. Sin embargo, sabiendo que:

<<script> devuelve <

script> devuelve <

Ya tenemos la formula de evitar el filtro:

<<script>script>alert(“XSS medium”)</script>

Análogamente a la reconstrucción del tag de script en función del filtrado, se podría incluir construir el tag de script en partes:

<scr>script>ipt>alert(“XSS DVWA”);</script>

Del mismo modo, a la reconstrucción del tag de script en función del filtrado, se podría incluir espacios en blanco en los < > para saltarse la restricción y ver si el servidor interpreta dicho código y lo ejecuta.

<<script>script>alert(“XSS medium”);</script >

De ahí el fallo que reemplaza justamente esa palabra exacta. Por lo tanto, introduciendo el código:

<script type=”text/javascript”>alert(“XSS medium”)</script>

No detecta la cadena <script> exacta y se lo “traga”

Otro intento típico es emplear los tag de script en mayúsculas para verificar si el servidor realiza algún tipo de saneamiento, esto es, una conversión de lso valores introducidos ya sean mayúsculas o minúsculas para su posterior tratamiento y gestión:

<SCRIPT>alert(“XSS medium”);</SCRIPT>

Una vez vulnerado se mira el código fuente para ver que función emplean para determinar cómo se podría mejorar.

Observando el código fuente, se aprecia que se está empleando la función str_replace para reemplazar la keyword“<script>” por un espacio en blanco.

Adicionalmente, es más que recomendable revisar el documento de OWASP para explotar XSS (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).

Happy Hacking