diff --git a/pentesting-web/race-condition.md b/pentesting-web/race-condition.md index 6f6783763..0940f3faf 100644 --- a/pentesting-web/race-condition.md +++ b/pentesting-web/race-condition.md @@ -321,26 +321,26 @@ Ci sono molte variazioni di questo tipo di attacco, tra cui: Sfruttare condizioni di gara complesse spesso comporta approfittare di brevi opportunità per interagire con stati macchina nascosti o **non intenzionali**. Ecco come affrontare questo: 1. **Identificare Potenziali Stati Nascosti** -* Inizia individuando endpoint che modificano o interagiscono con dati critici, come profili utente o processi di reset della password. Concentrati su: +* Inizia individuando endpoint che modificano o interagiscono con dati critici, come profili utente o processi di reimpostazione della password. 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 reset. -2. **Condurre Probing Iniziale** +* **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 del tempismo preciso coinvolto. ### Attacchi Sensibili al Tempo -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 reset della password basati su timestamp potrebbe consentire token identici per richieste simultanee. +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. **Per Sfruttare:** -* Usa un tempismo preciso, come un attacco a pacchetto singolo, per effettuare richieste di reset della password concorrenti. Token identici indicano una vulnerabilità. +* Usa un tempismo preciso, come un attacco a pacchetto singolo, per effettuare richieste di reimpostazione della password simultanee. Token identici indicano una vulnerabilità. **Esempio:** -* Richiedi due token di reset della password contemporaneamente e confrontali. Token corrispondenti suggeriscono un difetto nella generazione dei token. +* Richiedi due token di reimpostazione della password contemporaneamente e confrontali. Token corrispondenti 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.** @@ -362,7 +362,7 @@ Secondo [**questa ricerca**](https://portswigger.net/research/smashing-the-state ### Stati Nascosti del Database / Bypass di 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 **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 viene scritto. Questo significa che per un breve periodo il **token per confermare un account è nullo**. 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 **confermare un account** dove non controlli l'email. @@ -370,7 +370,7 @@ Pertanto, **registrare un account e inviare diverse richieste con un token vuoto ### Bypass 2FA -Il seguente pseudo-codice è vulnerabile a una race condition perché in un tempo molto breve il **2FA non è applicato** mentre la sessione è creata: +Il seguente pseudo-codice è vulnerabile a una race condition perché in un tempo molto breve il **2FA non è applicato** mentre la sessione viene creata: ```python session['userid'] = user.userid if user.mfa_enabled: @@ -381,7 +381,7 @@ 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: "_L'applicazione \ vuole accedere alle tue informazioni, vuoi permetterlo?_" +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?_" #### Race Condition in `authorization_code` @@ -402,10 +402,11 @@ In [**WS\_RaceCondition\_PoC**](https://github.com/redrays-io/WS\_RaceCondition\ * [https://hackerone.com/reports/55140](https://hackerone.com/reports/55140) * [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/) {% hint style="success" %} -Impara e pratica Hacking AWS:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ -Impara e pratica Hacking GCP: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte) +Impara e pratica AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ +Impara e pratica GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
@@ -421,7 +422,7 @@ Impara e pratica Hacking GCP:
\ -Usa [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition) per costruire e **automatizzare facilmente i flussi di lavoro** alimentati dagli strumenti della comunità **più avanzati** al mondo.\ +Usa [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition) per costruire e **automatizzare flussi di lavoro** facilmente, alimentati dagli **strumenti comunitari più avanzati** al mondo.\ Ottieni accesso oggi: {% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=race-condition" %}