---
url: https://docs.ogmabox.com/pt/app/utilities/race-smuggling.md
description: >-
  Teste condições de corrida e o comportamento de HTTP request smuggling com os
  utilitários do Ogma.
---

# Condição de corrida e Smuggling {#race-and-smuggling}

Condição de corrida / Smuggling oferece duas ferramentas especializadas para ataques HTTP sensíveis ao tempo e no nível de protocolo.

## Condições de corrida {#race-conditions}

A aba Condições de corrida envia várias cópias de uma requisição simultaneamente ao mesmo endpoint e permite comparar respostas e tempos entre as execuções paralelas.

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

* **TOCTOU (tempo de verificação/tempo de uso)**: teste se requisições concorrentes podem se intercalar entre uma verificação e uma operação de mudança de estado.
* **Manipulação de contas**: envie mudanças de saldo, resgates de cupons ou operações com limites de forma concorrente para testar gasto duplo ou excesso de resgates.
* **Contornar limites de votos ou de taxa**: confirme se os limites por usuário são aplicados de forma atômica.

### Executar um teste de condição de corrida {#running-a-race-test}

1. Monte a requisição-alvo na aba Condições de corrida ou envie-a para essa aba.
2. Defina o valor de **concorrência**: quantas cópias paralelas enviar.
3. Clique em **Enviar corrida**. Todas as cópias são enviadas o mais simultaneamente possível.
4. Revise a tabela de respostas: código de status, corpo e tempo decorrido para cada cópia.
5. Diferenças entre as respostas (códigos de status diferentes, corpos de resposta diferentes, sucesso inesperado nas cópias 2+) indicam uma janela de condição de corrida.

### Condições de corrida com um único pacote HTTP/2 {#http-2-single-packet-racing}

Quando o alvo aceitar HTTP/2, habilite o **modo HTTP/2**. HTTP/2 multiplexa todas as requisições paralelas em uma única conexão, o que elimina a variação de latência da rede e torna mais confiável a chegada concorrente ao servidor.

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

A aba Smuggling testa como um servidor trata cabeçalhos ambíguos `Content-Length` e `Transfer-Encoding` para detectar dessincronização entre frontend e backend.

### Contexto {#background}

Quando um proxy reverso e um servidor backend discordam sobre onde uma requisição termina e a próxima começa, um prefixo introduzido por smuggling na requisição A pode ser colocado antes da requisição B. O impacto vai de envenenamento de cache a contornar autenticação e injetar requisições arbitrárias.

### Variantes de dessincronização {#desync-variants}

| Variante | Descrição |
|---|---|
| CL.TE | O frontend usa Content-Length; o backend usa Transfer-Encoding |
| TE.CL | O frontend usa Transfer-Encoding; o backend usa Content-Length |
| TE.TE | Ambos usam Transfer-Encoding, mas respondem de forma diferente a um cabeçalho ofuscado |

### Executar uma sondagem de smuggling {#running-a-smuggling-probe}

1. Selecione o endpoint-alvo na aba Smuggling.
2. Escolha a variante de dessincronização a testar.
3. Clique em **Enviar sondagem**. A ferramenta envia a requisição preparada e mede a resposta.
4. Um tempo limite excedido ou uma resposta inesperada na segunda requisição da sequência indica uma possível dessincronização.
5. Confirme manualmente antes de criar um achado; falsos positivos ocorrem quando as condições da rede causam um tempo limite excedido sem relação com a sondagem.

## Páginas relacionadas {#related-pages}

* [Reenvio](../replay.md)
* [Interceptação](../intercept.md)
* [Achados](../findings.md)