---
url: https://docs.ogmabox.com/it/app/utilities/race-smuggling.md
description: >-
  Verifica race condition e il comportamento di HTTP request smuggling con le
  utilità di Ogma.
---

# Race e Smuggling {#race-and-smuggling}

Race / Smuggling offre due strumenti specializzati per attacchi HTTP sensibili alla temporizzazione e a livello di protocollo.

## Race condition {#race-conditions}

La scheda Race invia più copie di una richiesta simultaneamente allo stesso endpoint e consente di confrontare risposte e tempi tra le esecuzioni parallele.

### Quando usarla {#when-to-use-it}

* **TOCTOU (momento del controllo/momento dell'uso)**: verifica se richieste concorrenti possono inserirsi tra un controllo e un'operazione che modifica lo stato.
* **Manipolazione degli account**: invia modifiche del saldo, riscatti di coupon o operazioni soggette a limiti in modo concorrente per verificare doppie spese o riscatti in eccesso.
* **Aggiramento dei limiti di voto o frequenza**: conferma se i limiti per utente sono applicati in modo atomico.

### Eseguire un test di race condition {#running-a-race-test}

1. Crea la richiesta bersaglio nella scheda Race o inviala a questa scheda.
2. Imposta il valore di **concorrenza**, cioè il numero di copie da inviare in parallelo.
3. Fai clic su **Invia Race**. Tutte le copie vengono inviate il più simultaneamente possibile.
4. Esamina la tabella delle risposte: codice di stato, corpo e tempo trascorso per ogni copia.
5. Le differenze tra le risposte (codici di stato diversi, corpi di risposta diversi, successo inatteso nelle copie 2+) indicano una finestra temporale sfruttabile per una race condition.

### Race condition HTTP/2 con pacchetto singolo {#http-2-single-packet-racing}

Quando il bersaglio supporta HTTP/2, abilita la **modalità HTTP/2**. HTTP/2 multiplexa tutte le richieste parallele su una connessione, eliminando la variabilità dei tempi di rete e rendendo più affidabile l'arrivo concorrente al server.

## HTTP request smuggling {#http-request-smuggling}

La scheda Smuggling verifica come un server gestisce le intestazioni ambigue `Content-Length` e `Transfer-Encoding` per rilevare desincronizzazioni tra frontend e backend.

### Contesto {#background}

Quando un proxy inverso e un server backend non concordano su dove termina una richiesta e inizia la successiva, un prefisso introdotto tramite smuggling dalla richiesta A può essere anteposto alla richiesta B. L'impatto va dall'avvelenamento della cache all'aggiramento dell'autenticazione e all'iniezione di richieste arbitrarie.

### Varianti di desincronizzazione {#desync-variants}

| Variante | Descrizione |
|---|---|
| CL.TE | Il frontend usa Content-Length; il backend usa Transfer-Encoding |
| TE.CL | Il frontend usa Transfer-Encoding; il backend usa Content-Length |
| TE.TE | Entrambi usano Transfer-Encoding, ma rispondono diversamente a un'intestazione offuscata |

### Eseguire una sonda di smuggling {#running-a-smuggling-probe}

1. Seleziona l'endpoint bersaglio nella scheda Smuggling.
2. Scegli la variante di desincronizzazione da verificare.
3. Fai clic su **Invia sonda**. Lo strumento invia la richiesta preparata e misura la risposta.
4. Un timeout o una risposta inattesa alla seconda richiesta della sequenza indica una possibile desincronizzazione.
5. Conferma manualmente prima di creare un rilievo di sicurezza: si verificano falsi positivi quando le condizioni di rete causano un timeout non correlato alla sonda.

## Pagine correlate {#related-pages}

* [Ripetizione](../replay.md)
* [Intercettazione](../intercept.md)
* [Risultati](../findings.md)