¿Qué son los ataques XSS?

Un ataque XSS se produce cuando un atacante consigue introducir un código malicioso, por ejemplo mediante Javascript, en la página web alojada en un servidor web. Este código se ejecuta mediante nuestros navegadores y su objetivo es robar cookies del cliente para suplantar su identidad, modificar los enlaces originales para que redireccionen a sitios web maliciosos o modificar el sitio web con peticiones HTTP adulteradas.

¿Por qué se producen ataques XSS?

La causa de los ataques XSS es la incorrecta validación de los datos introducidos por los usuarios, que provoca que un usuario pueda dirigirse  a una página similar a la de su banco y ser fraudulenta o cambiar alguno de sus datos personales cuando se está registrando en una web.

Tipos de ataques XSS

Depende de cómo envían el código malicioso al servidor, pueden ser Non-persistent XSS y Persistent XSS.

Non-persistent XSS

No almacenan el código malicioso en el servidor, sino que lo muestran directamente al usuario. El ataque se lanza desde una fuente externa como un mail o una web de terceros.

Persistent XSS

El código del atacante logra inyectarse en la base de datos. Dicho código se ejecutará en el navegador del usuario cuando se recupere la información adulterada.

Para consultar toda la información referente a ataques XSS consultar el siguiente link de OWASP.

 

Herramientas para detectar y corregir ataques XSS

En todas las aplicaciones que hagamos es altamente recomendable conocer las vulnerabilidades de seguridad contra ataques que podamos tener. Por ejemplo en entornos de banca o seguros esta detección es de vital importancia para la salida a producción de las aplicaciones. Por suerte, contamos con herramientas automáticas que nos informan sobre los errores de seguridad que cometemos cuando desarrollamos nuestras aplicaciones. Una de ellas es ZAP de OWASP.

Detección de ataques XSS

Imaginemos que tenemos un código vulnerable como la siguiente JSP:

El parámetro cantidad es vulnerable, ya que no se valida lo que viene en este parámetro y lo escribimos directamente en la salida.

Para detectar esta situación vamos a ejecutar ZAP. Una vez dentro de la aplicación configuramos el proxy mediante el menú Herramientas > Opciones > Proxy local. Por defecto es la máquina local y el puerto 8080 y ZAP procesará las peticiones hacia esta máquina y este puerto. Por ejemplo, dejamos el proxy en localhost:7777 y configuramos el proxy de nuestro navegador también en localhost:7777 para que ZAP pueda capturar las peticiones desde nuestro navegador.

Una vez que lo hacemos colocamos la jsp en la aplicación examples de un Tomcat e intentamos acceder desde el navegador:

Nos aparecerá la ventana de nuestra JSP y ZAP habrá almacenado la sesión:

xss1
Y en el ZAP se almacenará la sesión HTTP:

Sesion en ZAP

Sesión en ZAP

Una vez que tenemos la sesión activamos el escaneo activo y la herramienta nos informa sobre todos los ataques XSS a los que somo vulnerables en la JSP:

Escaneo activo con ZAP

Escaneo activo con ZAP

Observamos que entre los ataques XSS hay uno con una bandera roja que se considera critico y deberíamos corregirlo:

Detalle ataque XSS crítico

Detalle ataque XSS crítico

 

También nos muestra otros ataques de criticidad mediana o baja.

 

Explotar vulnerabilidades XSS

Para mostrar como de fácil es para un atacante explotar esta vulnerabilidad utilizaremos la herramienta burp, que intercepta nuestras peticiones y nos permite modificar los valores de nuestros parámetros.

Nos descargamos la herramienta burp de aquí.

A continuación configuramos el proxy en el puerto 7777, que recordemos debe coincidir con el proxy configurado en nuestro navegador para que intercepte bien la petición:

 

Configurar proxy en BURP

Configurar proxy en BURP

Ponemos de nuevo la dirección de nuestra JSP de ejemplo:

Y el Burp nos intercepta la petición para que modifiquemos sus parámetros:

Interceptar parámetros con BURP

Interceptar parámetros con BURP

Imagina que estas pagando en una tienda online y nuestra página es la pasarela de pagos a la que te envía la tienda al pagar un artículo. Te aparece la cantidad y deberás introducir el número de tu cuenta al pagar. Cuando lo introduces, un script malicioso puede aprovechar una vulnerabilidad de la pasarela de pagos para modificar el submit y enviar tu número de cuenta a otro host diferente.

Deberíamos modificar el valor del parámetro con un script que modifique el submit y llame a la función que se establece en el submit de forma transparente al usuario. Por tanto, debemos sustituir la cadena con el valor de la cantidad a pagar con el siguiente código en negrita:

Por supuesto antes de sustituir con el burp lo codificamos con un conversor online de URLs:

99.45%22%0D%0A+%2F%3E+%0D%0A%3Cscript+language%3D%27javascript%27%3E%0D%0Afunction+sendCC%28%29%7B%0D%0A+form+%3D+document.getElementById%28%27sendForm%27%29%3B%0D%0A+var+numeroCuenta+%3D+form.numeroCuenta.value%3B%0D%0A+alert%28%27Enviando+numero+de+cuenta+a+host%3A%27+%2B+numeroCuenta%29%3B%0D%0A+return+sendPaymentRequest%28%29%3B%0D%0A%7D%0D%0A%0D%0Awindow.onload+%3D+function+%28%29+%7B%0D%0A+var+submitForm+%3D+document.getElementById%28%27sendForm%27%29%3B%0D%0A+submitForm.setAttribute%28%27onsubmit%27%2C+%27sendCC%28%29%27%29%3B%0D%0A%7D%0D%0A%3C%2Fscript%3E+%3Cbr

Si introducimos nuestro número de cuenta y pulsamos el submit en el formulario un atacante podrá obtener datos confidenciales:

Enviando datos sensibles

Enviando datos sensibles

 

Prevención ataques XSS

Ya hemos mencionado anteriormente que existen herramientas como ZAP para saber de antemano que páginas de nuestra aplicación son vulnerables a ataques XSS, pero, ¿cómo lo solucionamos?

La especificación OWASP nos proporciona una librería llamada ESAPI en varios lenguajes con la que podremos codificar de forma adecuada la entrada procedente de un usuario y evitar vulnerabilidades. No vamos a entrar en mucho detalle con todo lo que podemos hacer con la librería, solo mencionaremos cómo solucionar el error de nuestro página de ejemplo. Para hacerlo en la linea donde recibimos el parámetro cantidad del usuario utilizar la librería ESAPI para codificar correctamente el valor del parámetro cantidad:

 

final String cantidad = ESAPI.encoder().encodeForJavaScript( request.getParameter( "cantidad" ) );

Una vez que hacemos esto pasamos de nuevo la herramienta ZAP y vemos que las alertas críticas han desaparecido:

Alertas no críticas con ZAP

Alertas no críticas con ZAP

 

Ahora intentamos de nuevo ‘hackear’ nuestra página JSP pasando el script malicioso y vemos que aparecen unos carácteres extraños en el campo cantidad y cuando pulsemos el botón de submit del formulario el script malicioso ya no funcionará:

Solucionar ataque XSS

Solucionar ataque XSS

Existen muchas procedimientos para evitar ataques XSS. Por ejemplo, también podríamos utilizar funciones de codificación y decodificación y comprobar en cada petición que todos los parámetros están codificados correctamente. Hay múltiples soluciones para evitar el problema.

 

Espero que os haya servido. Un saludo.

 

Fuente:  diego | tododev