Learn & practice AWS Hacking:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**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.
1.**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.
2.**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.
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:
* [**SameSite cookies**](hacking-with-cookies/#samesite): Questo attributo impedisce al browser di inviare cookie insieme a richieste cross-site. [Maggiori informazioni sui cookie SameSite](hacking-with-cookies/#samesite).
* [**Cross-origin resource sharing**](cors-bypass.md): La politica CORS del sito vittima può influenzare la fattibilità dell'attacco, specialmente se l'attacco richiede di leggere la risposta dal sito vittima. [Scopri di più sul bypass CORS](cors-bypass.md).
* **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.
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**.
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).
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.
Questa vulnerabilità consente agli attaccanti di effettuare richieste non autorizzate per conto della vittima, sfruttando il **meccanismo di convalida del token inadeguato** dell'applicazione.
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**_
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.
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.
Secondo [**questo**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), per **evitare richieste preflight** utilizzando il metodo **POST**, questi sono i valori di Content-Type consentiti:
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`**_._
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:
1.**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.
2.**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`.
3.**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](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
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:
La prima parte di [**questo CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) spiega che [il codice sorgente di Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), 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**.
Se un **token CSRF** viene utilizzato come **difesa**, puoi provare a **esfiltrarlo** abusando di una vulnerabilità [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) o di una vulnerabilità [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
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)
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):
Impara e pratica Hacking AWS:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Impara e pratica Hacking GCP: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.