XSS permite la ejecución arbitraria de código javascript, permitiendo a quién lo ejecute imitar la identidad de un usuario, secuestrando cookies de sesion, ó ejecutar código malicioso, ó una denegación de servicio.
XSS Reflejado (No persistente)
Si una web sin codificación es vulnerable al ataque reflajado XSS interpretará el siguiente código puesto en la url
<script>alert(1)</script>
Simplemente aparece una alerta mostrando un 1, ocurre cuando el input
del usuario, devuelve un error, o un mensaje de error en la aplicación
web o el input enviado por el usuario es visible en parte de la
respuesta. Este mensaje enviado por el usuario que se ve en el navegador
no se almacena.
XSS almacenado (Persistente)
Otro tipo de ataque es el stored XSS en un contexto HTML sin codificación, en este caso el apartado comment será el vulnerable a la ejecución de un simple código como este:
<script>alert(0)</script>
El input es almacenado en el servidor atacado, en su base de datos en el campo comment. Podemos visualizar el payload de ataque siendo almacenado en el navegador de la víctima.
Ocurre cuando del lado del cliente se procesa código JavaScript de fuentes inseguras.
Si el atacante controla el campo del input, puede utilizar sentencias que cuando se ejecuten usando caracteres que le permitan escapar las instrucciones y ejecutar código malicioso
<><img src=0 onerror=alert(0)>
Ejecutando esto en la URL del navegador, veríamos como nos salta un alert, nada critico, pero el caso es que podríamos ejecutar código malicioso que derivara en el robo de una cuenta de un usuario.
Introduciendo los datos en la URL, pasa el código dinámicamente, instrucciones como eval() ó innerHTML. Lo cual permite al atacante ejecutar código JavaScript malicioso, introduciendo datos en una fuente que lo propagará, causando ejecución arbitraria de JavaScript .
XSS Reflejado en HTML
Ocurre cuando el atacante inyecta en el navegador, código en una respuesta HTTP. El ataque inyectado no es persistente, sólo afecta a usuarios al abrir un link malicioso.
En este caso, dentro de las etiquetas iframe y pasandole como fuente la URL víctima cerrándola con un back slash “/” seguido de una interrogación y el campo search esto lo igualamos a la etiqueta body y le pasamos la instrucción onesize igual a print() (esto es un requerimiento para resolver el laboratorio de portswigger). Ahora continuamos con la instrucción onload y la igualamos a un valor creado por nostros, en este caso estamos redimensionando el tamaño de la ventana a 100px
<iframe src="https://0a7c006b035bd21581f1cbfa01e1007e.exploit-server.net/?search=<body onresize=print()>" onload=this.style.width='100px'></iframe>
Al ejecutar mandar esto al servidor, veremos cómo nos imprime la página pero en un tamaño de 100px, reducido. Lo cual nos mostrará que estamos controlando la ejecución de código.
Este mismo ataque se puede sofisticar mucho más cuando estamos en un contexto restringido que nos bloque los todos los tags excepto los creados por nosotros mismos.
En este caso jugaríamos con la estiqueta script dentro del cual si podríamos decirle la localización, nueva, y dentro crear nuestra etiqueta
<script>
location ='https://0ade00be04a72912806f171c00110031.web-security-academy.net/?search<etiqueta id=r onfocus=alert(document.cookie) tabindex=1>#r';
</script>
XSS reflejado en Javascript string con una comilla
En ocasiones debido a restricciones, vemos nuestro ataque ofuscado, podemos saltarnos estas restricciones variando la sintaxis.
Cerramos una comilla que debe de quedarse abierta y concatenamos con las etiquetas script lo que queremos que se ejecute, en este caso un simple alert
''</script><script>alert(0)</script>'
XSS Reflejado en JavaScript encadenando con llaves y escapando las comillas simples
Para ver el funcionamiento de la página en este caso tenemos que inspeccionar el código. Detectamos que el campo vulnerable a XSS es el var searchTerms. Esto lo igualamos a ‘test’ y vemos que nos lo interpreta. Pero sin más, debemos de concatenar alguna instrucción usando un operador como +. Probamos esto en el campo búsqueda
var searchTerms = 'test' +alert(0)
Vemos que lo interpreta, pero entra en conflicto con las comillas, así que tendremos que escaparlas
test\'+alert(0);//XSS almacenado en un evento onclick
Inspeccionando el código dentro de la etiqueta “a” veo id=author, el laboratorio nos decía que ese era el campo vulnerable.
<a id="author" href://probando 'contenido" onclick="var tracker={track()}};tracker.track('https://probando.com'+alert(0)+'');">
metemos un href y una url inventada, con un contenido cualquiera a lo cual concatenamos el evento onclick y lo igualamos al campo vulnerable: var tracker donde ira nuestra instrucción maliciosa, escapando con llaves y con la función track, le introducimos la url ficticia que acabamos de crear y dentro codificamos dos apostrofes usando la función &APOS;
https://probando.com'+alert(0)+'
