HTTP Request Smuggling: techniczny test desync

HTTP Request Smuggling, nazywany również atakiem HTTP desync, powstaje wtedy, gdy co najmniej dwa komponenty obsługujące ten sam strumień ruchu inaczej wyznaczają granicę żądania. Reverse proxy może uznać wiadomość za zakończoną, podczas gdy serwer aplikacyjny potraktuje część tych samych bajtów jako początek kolejnego żądania. W efekcie kontrola bezpieczeństwa na brzegu i logika backendu przestają analizować ten sam komunikat.

Najkrótsza odpowiedź: skuteczny pentest HTTP Request Smuggling nie polega na masowym wysyłaniu znanych payloadów. Najpierw odtwarza pełny łańcuch CDN–WAF–load balancer–gateway–backend, następnie porównuje sposób ramkowania HTTP/1.1 i translacji HTTP/2, a na końcu potwierdza rozbieżność na izolowanym połączeniu i unikalnym zasobie testowym. Dowodem powinien być kontrolowany efekt dotyczący wyłącznie kont i danych testera, a nie zatrucie kolejki żądań prawdziwego użytkownika.

To podatność szczególnie istotna dla aplikacji za wieloma warstwami proxy. Każdy komponent może normalizować nagłówki, dokonywać downgrade’u protokołu, buforować ciało lub ponownie używać połączenia do originu. Dlatego identyczna aplikacja może być bezpieczna bezpośrednio, a podatna dopiero po włączeniu konkretnego CDN albo reguły routingu.

Co dokładnie desynchronizuje się w stosie HTTP

HTTP jest bezstanowy na poziomie semantyki, ale HTTP/1.1 często przesyła wiele kolejnych żądań jednym połączeniem TCP lub TLS. Odbiorca musi zatem jednoznacznie wiedzieć, gdzie kończy się ciało bieżącej wiadomości. RFC 9112, sekcja 6.3 definiuje kolejność ustalania długości wiadomości, a sekcja 11.2 wprost opisuje request smuggling jako skutek różnic parserów.

W praktycznej architekturze występują co najmniej cztery perspektywy:

Warstwa	Decyzja wpływająca na bezpieczeństwo	Typowa luka obserwacyjna
CDN lub WAF	czy żądanie jest poprawne i jaka jest jego długość	widzi tylko komunikat przed translacją
Reverse proxy	jak przepisać HTTP/2 albo HTTP/3 do protokołu upstream	może dodać, usunąć lub znormalizować ramkowanie
Gateway aplikacyjny	do którego backendu skierować strumień	może ponownie używać połączeń między klientami
Serwer aplikacji	ile bajtów należy do bieżącego żądania	interpretuje już zmieniony komunikat

Klasyczne oznaczenia CL.TE oraz TE.CL opisują, czy front-end i back-end preferują odpowiednio Content-Length albo kodowanie chunked. Nie są jednak kompletnym modelem współczesnego ryzyka. Trzeba uwzględnić również CL.0, zachowanie po przedwczesnej odpowiedzi, pause-based desync, różnice przy wielokrotnych nagłówkach oraz konwersję HTTP/2 do HTTP/1.1. Badania HTTP/2: The Sequel Is Always Worse pokazały, że protokół z jednoznacznym ramkowaniem może stać się źródłem podatności w chwili niepoprawnego downgrade’u.

Wniosek dla zespołu technicznego jest prosty: nie testuje się „serwera Nginx” albo „aplikacji Java” w izolacji. Testuje się konkretną kompozycję parserów, ustawień i tras produkcyjnych.

Dlaczego wpływ może być krytyczny

Rozbieżność granic nie musi od razu oznaczać przejęcia systemu. Stanowi jednak prymityw, który może zmienić kontekst kolejnego żądania. Rzeczywisty wpływ zależy od współdzielenia połączeń, routingu i dostępnych „gadżetów” aplikacyjnych. Możliwe klasy skutków obejmują:

ominięcie reguły WAF, jeżeli backend zobaczy żądanie, którego front-end nie analizował jako osobnej wiadomości;
pomylenie odpowiedzi i żądań na ponownie używanym połączeniu;
zatrucie cache, gdy zmieniona odpowiedź zostanie zapisana pod kluczem publicznego zasobu;
dostęp do ścieżki wewnętrznej osiągalnej dla proxy, lecz nie dla klienta zewnętrznego;
przejęcie sesji lub danych, jeżeli fragment żądania innego użytkownika zostanie związany z kontrolowaną odpowiedzią;
trwały błąd dostępności, gdy serwery oczekują różnej liczby bajtów i blokują pulę połączeń.

Nie każdy timeout jest podatnością, a sama rozbieżność bez osiągalnego skutku może mieć ograniczoną wagę. Raport powinien oddzielić trzy poziomy: anomalię parsera, potwierdzoną desynchronizację i wpływ biznesowy. Takie rozróżnienie chroni przed zawyżaniem severity i ułatwia naprawę we właściwej warstwie.

Zakres i zasady bezpiecznego testu

Request smuggling jest testem o podwyższonym ryzyku, ponieważ stan połączenia może dotknąć następnego klienta. Przed rozpoczęciem trzeba pisemnie ustalić:

hosty, regiony CDN, adresy originu i wersje protokołów w zakresie;
środowisko przeznaczone do testu oraz możliwość wyłączenia ruchu realnych użytkowników;
okno testowe, osobę kontaktową i warunek natychmiastowego przerwania;
identyfikatory kont, tenantów, ścieżek i nagłówków-canary należących wyłącznie do testera;
dopuszczalną liczbę połączeń, timeout oraz zakaz testów dostępności bez osobnej zgody;
dostęp do logów front-endu i backendu, aby potwierdzić interpretację bez eskalowania ataku;
sposób opróżnienia cache i puli połączeń po zakończeniu.

Najbezpieczniejszym celem jest staging wiernie odwzorowujący produkcyjny łańcuch. Jeżeli test musi odbyć się na produkcji, należy korzystać z dedykowanej domeny, odseparowanego backendu lub trasy kierowanej wyłącznie do testowej puli. Sam osobny użytkownik aplikacji nie wystarcza, jeśli reverse proxy współdzieli połączenia upstream między klientami.

Pełny proces warto osadzić w szerszej metodyce testów penetracyjnych aplikacji webowych. Request smuggling jest jednym z elementów oceny, a nie zamiennikiem testów autoryzacji i logiki biznesowej.

Techniczna metodyka pentestu HTTP desync

1. Zbuduj mapę wszystkich parserów

Zacznij od diagramu rzeczywistej ścieżki żądania. Zapisz negocjowany protokół od klienta do edge, protokół między kolejnymi hopami, terminację TLS, ustawienia keep-alive, buforowanie i retry. Sprawdź oddzielnie główną domenę, API, panel administracyjny, uploady i trasy serverless — często używają innych originów.

W trybie black-box pomocne są nagłówki diagnostyczne, różnice odpowiedzi, ALPN i kontrolowane błędy, ale nie powinny zastępować konfiguracji. W trybie grey-box przejrzyj reguły CDN, ingress controller, service mesh, proxy aplikacyjne i framework HTTP. Szczególną uwagę zwróć na miejsca, w których protokół jest tłumaczony albo nagłówki są przepisywane.

2. Ustal czysty profil bazowy

Dla każdej trasy wyślij poprawne żądania z ciałem i bez ciała, różnymi metodami oraz przez wszystkie obsługiwane wersje HTTP. Zmierz czas odpowiedzi, sposób zamykania połączenia, kod błędu i zachowanie następnego poprawnego żądania na tym samym kanale. Baseline ogranicza fałszywe alarmy powodowane przez rate limiting, zimny start funkcji, retry originu albo niestabilną sieć.

Rejestruj surowe bajty po obu stronach proxy, jeżeli środowisko na to pozwala. Widok narzędzia na stacji testera nie pokazuje tego, co po normalizacji otrzymał backend.

3. Badaj sprzeczności pojedynczo

Testuj jedną hipotezę naraz: niejednoznaczną długość, wielokrotny nagłówek, nietypową metodę, przedwczesną odpowiedź lub translację protokołu. Używaj minimalnego, nieszkodliwego ciała i unikalnego identyfikatora. Obserwuj, czy front-end i backend raportują różną liczbę wiadomości, długość albo kod błędu.

Bezpieczny dowód nie wymaga dodawania operacyjnego żądania do cudzego strumienia. W wydzielonej puli można zestawić kontrolowane połączenie A, wysłać sondę i następnie własne żądanie B do nieistniejącej ścieżki z losowym canary. Jeżeli log backendu wiąże canary z inną granicą niż log proxy, potwierdza to desynchronizację bez danych osoby trzeciej.

OWASP WSTG opisuje cel i podstawy testu. Automatyczne rozszerzenia mogą pomóc w pokryciu wariantów, lecz na produkcji powinny pracować z wyłączonymi ryzykownymi trybami i niską współbieżnością.

4. Sprawdź granice HTTP/2 i HTTP/3

Zweryfikuj nie tylko protokół widoczny w przeglądarce. CDN może przyjmować HTTP/2 lub HTTP/3, a do originu wysyłać HTTP/1.1. Oceniaj, czy pseudo-nagłówki, długość ramki i zwykłe nagłówki są przepisywane do jednej kanonicznej reprezentacji. Niepoprawne wartości muszą być odrzucone przed forwardingiem, a po błędzie połączenie upstream powinno zostać zamknięte.

HTTP/2 end-to-end istotnie redukuje klasyczne konflikty długości, ale nie usuwa błędów implementacji, request tunnelling ani problemów przy kolejnej translacji. Stwierdzenie „mamy HTTP/2 na CDN” nie jest więc dowodem bezpieczeństwa.

5. Potwierdź minimalny wpływ

Dopiero po wykazaniu rozbieżności sprawdź, czy wpływa ona na kontrolowany zasób. Bezpieczne cele to własna odpowiedź testowa, dedykowany endpoint diagnostyczny albo cache key zawierający losowy parametr dostępny wyłącznie testerowi. Nie używaj endpointów logowania, płatności i danych klientów. Nie próbuj przechwytywać żądania obcej sesji.

Jeśli nawet minimalna walidacja może przenieść stan między użytkownikami, zatrzymaj test na dowodach telemetrycznych. Dobre logi z dwóch warstw są mocniejszym i bezpieczniejszym dowodem niż efekt pokazany na prawdziwym użytkowniku.

6. Wykonaj retest całego łańcucha

Naprawa jednej reguły WAF nie wystarcza. Po zmianie trzeba powtórzyć test przez każdy protokół i trasę, sprawdzić zachowanie błędów oraz potwierdzić, że niejednoznaczne wiadomości są odrzucane i połączenie nie jest ponownie używane. Następnie wykonaj regresję poprawnych uploadów, webhooków i dużych żądań, aby hardening nie zepsuł funkcji biznesowych.

Detekcja HTTP Request Smuggling

Pojedynczy log access nie pokazuje konfliktu interpretacji. Potrzebna jest korelacja edge–origin za pomocą identyfikatora nadanego przed normalizacją i przeniesionego do backendu. Alarm powinny podnosić między innymi:

różna liczba żądań z tym samym identyfikatorem po obu stronach proxy;
niezgodność metody, ścieżki lub deklarowanej długości między edge i originem;
wiele błędów 400, 408 lub resetów połączenia po nietypowym ramkowaniu;
odpowiedź przypisana do innego request ID niż żądanie oczekiwane przez front-end;
niespodziewane teksty przypominające linię żądania w polach nagłówków albo logach parsera;
skoki liczby połączeń backendowych oczekujących na ciało;
cache miss lub hit niezgodny z kanonicznym adresem i metodą.

Warto logować wersję protokołu na każdym hopie, decyzję o długości, wynik normalizacji oraz przyczynę odrzucenia. Treść ciał może zawierać dane wrażliwe, dlatego telemetria powinna ograniczać się do metadanych, skrótów i bezpiecznych próbek. Reguły detekcyjne muszą być sprawdzone na ruchu legalnych klientów, ponieważ biblioteki uploadu i stare integracje potrafią generować nietypowe, ale poprawne wiadomości.

Hardening: jak usunąć klasę podatności

Najsilniejsza zasada brzmi: jedna kanoniczna interpretacja przed przekazaniem dalej. W praktyce oznacza to:

korzystanie z aktualnych, wspieranych serwerów HTTP i proxy;
utrzymanie HTTP/2 lub HTTP/3 end-to-end tam, gdzie architektura na to pozwala;
rygorystyczne odrzucanie niejednoznacznego ramkowania zamiast próby „naprawienia” wiadomości;
usuwanie hop-by-hop headers zgodnie ze specyfikacją i niedopuszczanie ich do warstwy aplikacji;
identyczną normalizację nazw, białych znaków i wielokrotnych nagłówków w całym łańcuchu;
zamykanie połączenia po błędzie parsowania, przedwczesnej odpowiedzi lub niepełnym ciele;
wyłączenie niepotrzebnego downgrade’u i testowanie każdej wymaganej konwersji;
ograniczenie ponownego użycia połączeń jako warstwę redukującą wpływ, a nie jedyną poprawkę;
osobne polityki cache dla odpowiedzi dynamicznych i uwierzytelnionych;
testy zgodności parserów w CI/CD po zmianie proxy, ingressu lub CDN.

RFC 9112 wymaga między innymi traktowania wiadomości zawierającej zarówno Transfer-Encoding, jak i Content-Length jako potencjalnego request smuggling i nakazuje odpowiednie postępowanie przed forwardingiem. WAF oparty wyłącznie na sygnaturze kilku znanych wariantów nie zapewnia tej zgodności.

Kontrole warto powiązać z wymaganiami OWASP ASVS 5, zwłaszcza w obszarze walidacji danych, architektury i komunikacji. Dla interfejsów usługowych przydatna jest również checklista pentestu REST, GraphQL i OAuth, bo desync może jedynie otworzyć drogę do właściwego błędu autoryzacji API.

Co powinno znaleźć się w raporcie

Raport musi umożliwiać zespołowi odtworzenie przyczyny bez uruchamiania niebezpiecznego exploita. Powinien zawierać diagram hopów, negocjowane protokoły, wersje i konfiguracje, różnicę interpretacji, dowody z logów obu stron, warunki konieczne do wpływu oraz minimalny bezpieczny PoC. Należy rozdzielić rekomendację natychmiastową — na przykład wyłączenie problematycznej trasy — od docelowej poprawki parsera lub translacji.

Ocena ryzyka powinna uwzględniać współdzielenie połączeń, dostęp do ofiar, stabilność prymitywu, osiągalny endpoint i możliwość ominięcia dodatkowych kontroli. Sam napis „CL.TE” bez wyjaśnienia przepływu nie pomaga ani programiście, ani administratorowi CDN.

Jeśli problem obejmuje endpointy chmurowe i service mesh, rozszerz analizę o pentest środowiska AWS, Azure lub GCP. Z kolei ogólny model priorytetów API opisuje artykuł bezpieczeństwo API według OWASP Top 10.

Checklista dla zespołu technicznego

Źródła techniczne

Potrzebujesz bezpiecznie sprawdzić wielowarstwowy stos HTTP? Autoryzowany test powinien objąć dokładną konfigurację CDN, WAF, proxy i backendu, a nie tylko publiczny adres. Zakres z kontrolowanym środowiskiem, dowodami telemetrycznymi i retestem pozwala potwierdzić ryzyko bez narażania użytkowników.