Special HTTP headers

Wordlists & Tools

• https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers
• https://github.com/rfc-st/humble

Headers to Change Location

Rewrite IP source:

• X-Originating-IP: 127.0.0.1
• X-Forwarded-For: 127.0.0.1
• X-Forwarded: 127.0.0.1
• Forwarded-For: 127.0.0.1
• X-Forwarded-Host: 127.0.0.1
• X-Remote-IP: 127.0.0.1
• X-Remote-Addr: 127.0.0.1
• X-ProxyUser-Ip: 127.0.0.1
• X-Original-URL: 127.0.0.1
• Client-IP: 127.0.0.1
• X-Client-IP: 127.0.0.1
• X-Host: 127.0.0.1
• 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)

Rewrite location:

• X-Original-URL: /admin/console
• X-Rewrite-URL: /admin/console

Hop-by-Hop headers

Um cabeçalho hop-by-hop é um cabeçalho que é projetado para ser processado e consumido pelo proxy que está lidando com a solicitação, em vez de um cabeçalho de ponta a ponta.

• Connection: close, X-Forwarded-For

{{#ref}} ../../pentesting-web/abusing-hop-by-hop-headers.md {{#endref}}

HTTP Request Smuggling

• Content-Length: 30
• Transfer-Encoding: chunked

{{#ref}} ../../pentesting-web/http-request-smuggling/ {{#endref}}

Cache Headers

Cabeçalhos de Cache do Servidor:

• 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:

• Clear-Site-Data: Cabeçalho para indicar o cache que deve ser removido: Clear-Site-Data: "cache", "cookies"
• Expires: Contém a data/hora quando 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"

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.

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.

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.

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:

• 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

Server Info

• Server: Apache/2.4.1 (Unix)
• X-Powered-By: PHP/5.3.3

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.

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:

Content-Disposition: attachment; filename="filename.jpg"

Isso significa que o arquivo chamado "filename.jpg" é destinado a ser baixado e salvo.

Cabeçalhos de Segurança

Content Security Policy (CSP)

{{#ref}} ../../pentesting-web/content-security-policy-csp-bypass/ {{#endref}}

Tipos Confiáveis

Ao impor Tipos Confiáveis através do CSP, as aplicações podem ser protegidas contra ataques XSS no DOM. 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.

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
});
}

// Assignment of raw strings is blocked, ensuring safety.
el.innerHTML = "some string" // Throws an exception.
const escaped = policy.createHTML("<img src=x onerror=alert(1)>")
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.

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.

X-Frame-Options: DENY

Política de Recursos de Origem Cruzada (CORP) e Compartilhamento de Recursos de Origem Cruzada (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.

Cross-Origin-Resource-Policy: same-origin
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Política de Incorporação entre Origens (COEP) e Política de Abertura entre Origens (COOP)

COEP e COOP são essenciais para habilitar o isolamento entre origens, reduzindo significativamente o risco de ataques semelhantes ao Spectre. Eles controlam o carregamento de recursos entre origens e a interação com janelas entre origens, respectivamente.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin-allow-popups

HTTP Strict Transport Security (HSTS)

Por fim, o 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.

Strict-Transport-Security: max-age=3153600

Header Name Casing Bypass

HTTP/1.1 define os nomes dos campos de cabeçalho como case-insensitive (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 case-sensitively, um atacante pode contorná-las simplesmente enviando o mesmo cabeçalho com uma capitalização diferente.

Situações típicas onde esse erro aparece:

• Listas de permissão/negação personalizadas 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 reverse-proxy (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.

Abusando o 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 (misturada ou em 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 forma case-insensitive (a maioria faz), ele aceitará o valor controlado pelo atacante.

Exemplo: 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.

# 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.

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 endpoints de gerenciamento 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://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• https://web.dev/security-headers/
• https://web.dev/articles/security-headers