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 sabéis para no meterse en líos
Como ya sabéis para instalar DVWA, os montáis la máquina virtual y le metéis la iso de DVWA (https://github.com/nightmare-rg/dvwa-vagrant/tree/master/dvwa-1.0.8)
Vamos a ello!
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 \t\n\r\0/
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).
Espero que os haya gustado :D
Para cualquier cosa, escribir un comentario y estaré encantado de responder.
Saludos.
NaxHack5
"La mejor defensa es un buen ataque"
No hay comentarios:
Publicar un comentario