PortSwigger Academy - Reflected Cross-Site Scripting (XSS)

¡Hola a todos! Aquí estamos de nuevo y esta vez seguimos preparando la certificación Burp Suite Certified Professional (BSCP), que proporciona una base muy buena de cara a auditorías web y gestión de la presión, sobre todo en el examen para el cual te proporcionan 4 horas y hay que explotar hasta 6 vulnerabilidades. Además, se trata de un examen muy barato (<100€) lo que la hace sumamente atractiva.

Antes de nada, recordad que PortSwigger nos permite probar 30 días su versión profesional de Burp Suite. Os recomendamos que activéis esta versión para poder probar todas las funcionalidades de la herramienta.

En esta entrada explicaremos y solucionaremos todos los laboratorios relativos a Reflected Cross-Site Scripting (XSS). Hay muchos walkthroughs sobre cómo resolver estos laboratorios, pero exponerlos aquí nos sirve para afianzar conceptos y enseñaros además algunos trucos de uso de Burp Suite Professional, así como comentar veces que hemos visto las vulnerabilidades estudiadas en los laboratorios en la vida real. Sin más dilación, ¡comenzamos!

Si tuviéramos que decir qué vulnerabilidad es la más prevalente en las webs que analizamos, sin duda, optaríamos por el Cross-Site Scripting, especialmente en sus formas reflejada y almacenada. Hemos visto este tipo de vulnerabilidades en aplicaciones de todo tipo y, aunque su mitigación es sencilla, en muchos casos no se aplican técnicas de desarrollo seguro que permitan ponerle freno a tiempo. Asimismo, muchas veces es tomada como inofensiva por los desarrolladores, pero sus consecuencias pueden ser bastante graves. Por ello, presta especial atención a este post.

Cabe añadir también que este tipo de vulnerabilidades son bien detectadas habitualmente por escáneres automáticos, aunque en algunos casos se pueden añadir detecciones a nivel manual. En toda esta tirada de laboratorios intentaremos hacerlo todo a mano, si bien apoyarse en herramientas para este tipo de vulnerabilidad suele ser muy útil.

Lab1 (Apprentice) – Reflected XSS into HTML context with nothing encoded

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a cross-site scripting attack that calls the alert function.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()».

Comenzamos mapeando los puntos de entrada de la aplicación y observamos un formulario de búsqueda en el blog. Si realizamos una consulta con un string arbitrario, como «foo», podemos observar una petición cuyo parámetro «search» adquiere el valor buscado. Asimismo, en la respuesta vemos cómo ese valor aparece reflejado:

Obtención de valor de parámetro reflejado en la respuesta

Como vemos, el valor aparece en un texto entre dos etiquetas «<h1>». Dado que dentro de ese contexto podría haber a priori scripts en Javascript, podemos utilizar un payload muy simple que incluya un «alert()» para resolver el laboratorio:

<script>alert(1)</script>

Explotación de Cross-Site Scripting (XSS) reflejado

Como vemos, el script es incrustado en la respuesta HTML y si renderizamos el contenido de la misma, se ejecutará mostrando un pop-up al usuario al que enviemos la URL completa.

Lab2 (Practicioner) – Reflected XSS into HTML context with most tags and attributes blocked

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a cross-site scripting attack that bypasses the WAF and calls the print() function.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «print()».

Lanzamos de nuevo una búsqueda en el blog que nos aparece en la aplicación y vemos cómo el valor de nuestro parámetro «search» usado para la búsqueda aparece reflejado en la respuesta HTML:

Obtención de parámetro reflejado en la respuesta

Como volvemos a estar en un contexto entre dos tags «<h1>», podemos intentar utilizar el paylaod anterior, inyectando de manera directa un script en la respuesta:

<script>print(1)</script>

En este caso, sin embargo, la respuesta es explícita y nos indica que los tags que estamos utilizando no están permitidos. Debemos encontrar, por tanto, otros tags en los que podamos inyectar nuestro código. Para ello, nos apoyaremos en la siguiente CheatSheet de PortSwigger, que es muy completa: https://portswigger.net/web-security/cross-site-scripting/cheat-sheet.

Lo que haremos, en este caso, es recoger el listado de todos los «tags» y probar cuáles están permitidos por el supuesto WAF de la aplicación. Automatizamos el ataque, obviamente, con Burp Intruder:

Configuración de Burp Intruder para buscar tags válidos

De las respuestas, filtramos aquellas que nos indican que el tag no es válido y nos quedamos con las que sí lo es:

Dado que el tag válido es «<body>» a través de la CheatSheet obtenemos un payload para ejecutar la función «print()» pedida:

<body+onload%3dalert(1)>

Intento de inyección con atributo onload

Pero, como vemos, una nueva barrera. El atributo que hemos elegido «onload» no se puede utilizar dado que es bloqueado por el WAF. Seguimos mismo procedimiento, automatizando con Burp Intruder y obteniendo el listado de atributos utilizables:

Configuración de Burp Intruder para enumerar atributos

Podemos, por tanto, elegir entre varios atributos. Revisamos en la CheatSheet de nuevo, ya que nos interesa utilizar alguno de estos que no requiera interacción por parte del usuario. Tras revisarlos, nos quedamos con el siguiente payload:

%22%3E%3Cbody%20onresize=print()%3E

Como vemos, si lanzamos una petición de este payload en Burp Suite Professional, aparece reflejado bypasseando el WAF. Asimismo, accediendo a la respuesta en el navegador (usando Burp Suite también) y haciendo resize de la ventana podemos ver que se ejecuta la función «print()» pedida:

Explotación de Cross-Site Scripting reflejado

Y ahora, finalmente, podemos incluir el siguiente contenido en nuestro «Exploit Server» para que cuando el usuario acceda, ejecute el script malicioso que hemos inyectado debido a que hace un resize automático de la ventana a 100 píxels:

<iframe src="https://0a24009f03c4554e80f7f99b00b500e1.web-security-academy.net/?search=%22%3E%3Cbody%20onresize=print()%3E" onload=this.style.width='100px'>

Tras almacenarlo, se lo enviamos al usuario final y… ¡Laboratorio resuelto!

Lab3 (Practicioner) – Reflected XSS into HTML context with all tags blocked except custom ones

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a cross-site scripting attack that injects a custom tag and automatically alerts document.cookie.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert(document.cookie)».

De nuevo, identificamos que el parámetro vulnerable es «search» en la búsqueda dentro del blog, ya que los valores incluidos en él se ven reflejados en las respuestas:

Valor de parámetro de entrada obtenido reflejado en la respuesta

Sin embargo, ahora el WAF filtra adecuadamente todas las etiquetas estándar. Por ello, debemos usar etiquetas «custom» o personalizadas. Esto no supone un problema, puesto que la CheatSheet ya nos permite seleccionar este tipo de etiquetas para su uso. Filtramos por aquellas válidas para Chrome sin interacción del usuario y obtenemos un payload válido:

<xss+autofocus+tabindex%3d1+onfocus%3dalert(document.cookie)></xss>

Verificamos que funciona en Chrome:

Y una vez que lo tenemos todo funcional, generamos el siguiente script para que cuando la víctima acceda a él sea redirigida al XSS:

<meta http-equiv="refresh" content="0;https://0a7000da03bee0ca814148fd00470072.web-security-academy.net/?search=<xss+autofocus+tabindex%3d1+onfocus%3dalert(document.cookie)></xss>">

Lo almacenamos en el «Exploit Server», lo enviamos y laboratorio resuelto. Ojo, aquí NO podemos utilizar iframes para enviar el exploit dado que la cabecera «X-Frame-Options» en el servidor original adquiere el valor «SAMEORIGIN». Por tanto, no es posible embeber dicha aplicación en iframes, aunque no supone un problema porque podemos redirigir con HTML automáticamente al usuario.

Lab4 (Expert) – Reflected XSS with event handlers and `href` attributes blocked

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a cross-site scripting attack that injects a vector that, when clicked, calls the alert function.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()» cuando se haga click en el enlace.

Comenzamos, de nuevo, identificando el punto vulnerable:

Tratamos de identificar los tags que se encuentran habilitados para su explotación, ya que como podemos ver incluyendo tags simples como «script», algunos están bloqueados. De nuevo, usamos Burp Intruder para ello:

La etiqueta «a» puede ser utilizada, por lo que lo más sencillo sería un payload tipo:

<a+href%3d"">Click+me</a>

Sin embargo, el atributo «href» también está bloqueado. Buscamos alternativas en la CheatSheet:

<a+onclick%3d"alert(1)"+style%3ddisplay%3ablock>Click%2bme</a>

Por desgracia, todos los atributos están igualmente bloqueados. Intentamos evaluar cómo el WAF está filtrando los atributos, sobre todo el «href». Nos damos cuenta, usando los siguientes payloads, de que probablemente hay una expresión regular buscando «href=» entre «<>»

<a+href => OK
<a+href> => OK
<a+href=> => Bloqueado

Por tanto, buscamos en la CheatSheet algún payload que nos permita no usar el «=» tras el «href».

<svg><animate xlink:href=#xss attributeName=href values=javascript:alert(1) /><a id=xss><text x=20 y=20>XSS</text></a>

Lo adaptamos, eliminando la parte que nos detecta el WAF y que no es necesaria. Además, adaptamos el código para que el elemento animado sea de tipo «<a>», pero no sea concretamente el elemento con ID «xss».

<svg><a><animate attributeName=href values=javascript:alert(1) /><text x=20 y=20>Click me</text></a>

Lanzamos el payload en el navegador (codificado). Hacemos click sobre el «Click me» y laboratorio resuelto.

Esto funciona, básicamente porque:

Generamos un atributo «svg», que es animable
Generamos un atributo «a» dentro del «svg»
Animamos el anchor del atributo «a» (implícito al no especificar qué atributo queremos animar) y asignamos a dicho anchor la ejecución de un alert
Generamos una posición y tamaño para el texto
Cerramos el atributo «a»

Por tanto, estamos animando el anchor del atributo «a» sin necesidad de usar la cadena «href=» que teníamos vetada.

Lab5 (Practicioner) – Reflected XSS with some SVG markup allowed

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a cross-site scripting attack that calls the alert() function.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()».

Comenzamos, de nuevo, identificando el punto vulnerable, que no es otro que la búsqueda dentro del blog:

Identificación de punto vulnerable a Cross-Site Scripting (XSS) reflejado

Al igual que hicimos en laboratorios anteriores, probamos el payload más simple que podemos de primeras:

<script>alert(1)</script>

Realizamos de nuevo el proceso de identificación de etiquetas válidas con Burp Intruder (se omite la configuración al poder ser vista en laboratorios anteriores), aprovechando la lista de etiquetas de la CheatSheet:

Como vemos, la etiqueta «svg» está permitida, así que utilizaremos también un payload básico haciendo uso de ella:

<svg+onload%3dalert(1)>

En esta nueva iteración, vemos que lo que no es permitido es el evento «onload». Realizamos con Burp Intruder una identificación de los eventos válidos (siguiendo un patrón similar y extrayéndolos de la CheatSheet):

Procedemos a generar un nuevo payload, teniendo en cuenta los tags y los eventos disponibles (fíjate en las negritas):

<svg><animatetransform onbegin=alert(1) attributeName=transform>

¡Laboratorio resuelto!

Lab6 (Apprentice) – Reflected XSS into attribute with angle brackets HTML-encoded

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve this lab, perform a cross-site scripting attack that injects an attribute and calls the alert function.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()».

Comenzamos mapeando la superficie de exposición de la aplicación y vemos que el elemento vulnerable es una vez más la búsqueda del blog. Sin embargo, en este caso, tenemos dos apariciones del valor del parámetro reflejado: una de ellas dentro de etiquetas HTML y otra en el valor de un atributo de una etiqueta «input». En este caso, nos centraremos en esta segunda aparición:

Identificación de vulnerabilidad XSS reflejado

En este caso, vamos a incluir un payload que rompa el contexto donde se incluye «randomvalue» y que todo quede funcional. Fíjate en el siguiente recuadro donde tenemos todo el contexto y, en negrita, el payload. Verás que el contexto es completamente válido:

<input type=text placeholder='Search the blog...' name=search value="random" autofocus onfocus=alert(1) x="">

Tomando esta referencia, el payload ya codificado sería:

random"+autofocus+onfocus%3dalert(1)+x%3d"

Accediendo a la URL, vemos que el laboratorio queda resuelto.

Lab7 (Practicioner) – Reflected XSS in canonical link tag

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a cross-site scripting attack on the home page that injects an attribute that calls the alert function.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()».

En este caso, nos indican que podemos asumir que el usuario va a pulsar las siguientes teclas: «ATL+SHIFT+X», «CTRL+ALT+X» y «ALT+X». Por tanto, en este caso, podemos usar eventos basados en pulsaciones de teclado. Comenzamos como siempre mapeando la aplicación y vemos que el recurso vulnerable en este caso es la raíz del blog, donde si incluimos un payload en parámetros se ve reflejado en la respuesta:

Descubrimiento de vulnerabilidad de XSS reflejado

En este caso, aprenderemos un truco bastante importante y es que no hacen falta espacios para que el HTML sea sintácticamente válido si las comillas hacen los atributos no ambiguos. Fíjate en el siguiente payload extraído de la CheatSheet:

<link rel="canonical" accesskey="X" onclick="alert(1)" /> (Press ALT+SHIFT+X on Windows) (CTRL+ALT+X on OS X)

Este payload sería igualmente válido y no contiene espacios.

<link rel="canonical"accesskey="X"onclick="alert(1)"/> (Press ALT+SHIFT+X on Windows) (CTRL+ALT+X on OS X)

Adaptamos, por tanto, nuestro payload a utilizar para que al reflejarse en la salida se construya una sintaxis similar a la mostrada antes y obtenemos:

foo=foo'accesskey='X'onclick='alert(1)'

Y, por tanto, accediendo a una URL como la siguiente, resolvemos el laboratorio:

https://0a9500ad045fd42094e1486900e9008a.web-security-academy.net/?foo=foo'accesskey='X'onclick='alert(1)'

Muy importante cómo en este laboratorio no necesitamos los espacios para poder inyectar atributos. Esto es porque los navegadores, en general, aunque el HTML tenga errores intentan ser «buenos» a la hora de parsearlo.

Lab8 (Practicioner) – Reflected XSS into a JavaScript string with single quote and backslash escaped

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve this lab, perform a cross-site scripting attack that breaks out of the JavaScript string and calls the alert function.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()».

Comenzamos, de nuevo, mapeando la superficie de exposición de la aplicación y observamos que el valor del parámetro de búsqueda se ve reflejado en la respuesta, esta vez dentro de un script de Javascript ya creado:

Identificación de vulnerabilidades de XSS reflejado

Dado que estamos dentro de un elemento de script, simplemente debemos cerrarlo en primer lugar e incluir un payload que se cargue automáticamente al acceder a la URL generada. Podemos usar un payload como el siguiente:

</script><img src=x onerror=alert(1)>

Obtención de payload reflejado en la respuesta y ejecución del mismo

Como vemos, cerramos el script y simplemente accediendo a la siguiente URL se resuelve el laboratorio:

https://0aa00030032a980080ae355d0092006e.web-security-academy.net/?search=%3C/script%3E%3Cimg%20src=x%20onerror=alert(1)%3E

Lab9 (Apprentice) – Reflected XSS into a JavaScript string with angle brackets HTML encoded

Detección de vulnerabilidad de XSS reflejado

Este caso es muy sencillo, dado que debemos inyectar contenido Javascript solamente con tener cuidado de no romper el script original. Fíjate en el siguiente payload y en cómo el script queda correcto, pero con el «alert(1)» incluido:

randomvalue';alert(1);var+foo='

Simplemente lanzando esa petición y observando la respuesta en el navegador, vemos que el laboratorio queda resuelto.

Lab10 (Practicioner) – Reflected XSS into a JavaScript string with angle brackets and double quotes HTML-encoded and single quotes escaped

Podemos utilizar, por segunda ocasión, el siguiente payload:

randomvalue';alert(1);var+foo='

Pero, en este caso, la salida es la siguiente:

var searchTerms = 'randomvalue\';alert(1);var foo=\'';

Como se puede ver, ese backslash fue añadido por la aplicación junto a nuestra comilla. El backslash es el carácter de escape Javascript. Sin embargo, intentaremos introducir un doble backslash, de forma que el primero sea incluido por nosotros para interpretar el segundo como un string literal. Tal que así:

var searchTerms = 'randomvalue\\';alert(1);//

En teoría, dicho fragmento de código ejecuta la alerta ya que el backslash está escapando el siguiente backslash y no la comilla. Además, tras el alert incluimos un comentario en la siguiente línea. Convertimos, por tanto, el payload al siguiente y resolvemos el laboratorio:

randomvalue\';alert(1);//

Simplemente viendo la respuesta en el navegador, habremos resuelto el laboratorio.

Lab11 (Expert) – Reflected XSS in a JavaScript URL with some characters blocked

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a cross-site scripting attack that calls the alert function with the string 1337 contained somewhere in the alert message.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()» con el mensaje «l33t».

Comenzamos, de nuevo, mapeando la superficie de exposición de la aplicación y observamos que cuando se accede a un post cualquiera, el enlace de vuelta a la raíz del laboratorio se genera mediante contenido Javascript en el anchor de dicho enlace:

En este laboratorio, podemos inyectar contenido en dicho enlace a través del parámetro «postId» (y de la ruta, en general, pero usaremos el parámetro). Disponemos, inicialmente, del siguiente contenido, marcando como negrita la parte que controlamos:

<a href="javascript:fetch('/analytics', {method:'post',body:'/post%3fpostId%3d<controlledvalue>'}).finally(_ => window.location = '/')">

Necesitamos, por tanto, generar un payload que se escape de dicho contexto y pueda ejecutar el «alert()» deseado.

<a href="javascript:fetch('/analytics', {method:'post',body:'/post%3fpostId%3d4&%27},x=x=%3E{throw/**/onerror=alert,1337},toString=x,window%2b%27%27,{x:%27

Fíjate que el siguiente código hará que el contenido se convierta en lo siguiente:

<a href=»javascript:fetch(‘/analytics’, {method:’post’,body:’/post%3fpostId%3d4&%27},x=x=%3E{throw/**/onerror=alert,1337},toString=x,window%2b%27%27,{x:%27′}).finally(_ => window.location = ‘/’)»>

Y, decodificando todo:

<a href="javascript:fetch('/analytics', {method:'post',body:'/post?postId=4&'},x=x=>{throw/**/onerror=alert,1337},toString=x,window+'',{x:''}).finally(_ => window.location = '/')">

Lanzamos el payload en negrita de arriba en la propia URL y resolvemos el laboratorio:

Aunque fetch() solo recibe dos parámetros, en este caso metemos varios más que son interpretados por el compilador Javascript. Lo que hacemos es crear una función denominada «x» que genere la alerta deseada sin utilizar caracteres como «(» o «)» y posteriormente forzamos su uso mediante conversiones de datos. Con ello, conseguimos ejecutar el alert.

Lab12 (Practicioner) – Reflected XSS into a template literal with angle brackets, single, double quotes, backslash and backticks Unicode-escaped

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve this lab, perform a cross-site scripting attack that calls the alert function inside the template string». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Scripting (XSS) reflejado, lanzando un «alert()».

El apartado vulnerable es, una vez más, la búsqueda dentro del blog:

Dado que el reflejo del parámetro se da dentro de una plantilla literal (template literals), podemos usar la siguiente estructura para inyectar código Javascript que será interpretado en dicha plantilla:

${<js code>}

Por tanto, podemos usar el siguiente payload:

${alert(1)}

Accediendo a la URL vemos que resolvemos el laboratorio:

~km0xu95