HTTP Request Smuggling Deep Dive Series
AAAAA isso vai ser insano Tenho minhas suspeitas que ele vai trazer algumas headers que não são usadas geralmente por nenhum parser de HTTP (até mesmo 100% ignoradas por alguns parsers)
/* MAS SAO INTERPRETADAS PELO PROXIMO SERVIDOR EM CURSO A RECEBÊ-LA*/ e que essa inconsistência pode gerar requests smuggling por padrão.
Que esse desync pode causar DOS e muitas vezes leaking de dados de requisições de outros usuários
Essas vulnerabilidades a nível de integrações / entre servidores, na minha visão são umas das mais chatas de corrigir (e por consequência uma das mais negligenciadas e sucetíveis a vulnerabilidades).
Imagina, tu quer chamar uma API terceira e tem que antes de tudo saber como o servidor que serve ela manuseia todas as headers que tu ignora, ou trata elas diferente. Tudo por que cada parser interpreta a RFC de um jeito diferente
Quando falo em RFC (aquela parada chata de ler, mas necessária) falo na RFC 7230 (https://datatracker.ietf.org/doc/html/rfc7230)
Ela fala para as pessoas que criam tecnologia como o protocolo HTTP nesses interpretadores deveria ser lido: “If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message MUST NOT be forwarded by a proxy or gateway.”
Fala sobre não repassar o valor a diante. Mas daqui a pouco tem um cenário que umas headers são necessárias serem repassadas para o correto funcionamento de uma API no fim da rota e o sysadmin vai lá e faz todas serem encaminhadas, ou um api gateway não faz esse processo de sobrescrever a header, logo o próximo servidor que receber esse request forwarding é impactado e vai ler onde começa e onde termina uma requisição de um jeito diferente, causando uma dessincronização na fila das requisições a serem processadas pelo servidor web
Webpage: RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing - https://datatracker.ietf.org/doc/html/rfc7230 Para ler ++
https://blog.malicious.group/the-quiet-side-channel-smuggling-with-cl-0-for-c2/ The Quiet Side Channel… Smuggling with CL.0 for C2
HTTP Request Smuggling Explained (with James Kettle)
Watch the full video here 👉🏼
[Documento Anexado: http1-must-die.pdf]
Olha, vocês vão ter que me aguentar falando de novo do mesmo cara e assunto! Primeiro porquê sou fã demais do James Kettle E segundo por que essa pesquisa dele tem uma proposta muito ousada e que já tem um movimento importante em jogo: acabar com o protocolo http/1.1
Tu não leu o paper dele que enviei no grupo? Tudo bem Não viu a talk dele na Defcon que enviei aqui? Tudo bem tambem Não fez ainda os labs da portswigger que explora a vulnerabilidade que ele demonstrou? Beleza
⚠Agora ele simplesmente vai resolver o lab ao vivo. É só abrir o vídeo e pegar a pipoca.
📅 Sexta-feira (15 de agosto 2025) às 15hs
Link da live no dia que tu vai acessar: https://www.youtube.com/live/B7p8dIB7bFg?si=GaeBuHlNvFuHe4KR
Curtiu ser lembrado? Interage aqui com o post! Isso motiva a trazer mais conteúdo disso e saber que estão curtindo o que tô postando! É um ótimo feedback do nosso trabalho aqui. TMJ
Para ler depois ++ https://medium.com/@zodiacHacker/http-request-smuggling-in-bug-bounty-hunting-abf0e4e75b73 Valeu pela indicação @matheus_wnc HTTP Request Smuggling In Bug Bounty Hunting
HTTP pipelining ou request smuggling?
Saiba como diferenciar:
https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling
