Tihotapljenje zahtev in HTTP HEAD Content-Length

HTTP odjemalec običajno s strežnika prejema datoteke tako, da mu pošlje zahtevo z metodo GET. Poleg nje pa obstaja tudi metoda HEAD. Strežnik na zahtevo z metodo HEAD odgovori tako, kot bi odgovoril na zahtevo GET, le da v odgovor ne vključi telesa (dejanske vsebine zahtevane datoteke). Odjemalec se lahko tako seznani s tipom datoteke (Content-Type), datumom spremembe (Last-Modified) in podobnimi metapodatki, ne da bi moral prenesti celo datoteko. Med metapodatki pa strežnik lahko pošlje tudi Content-Length (in ponavadi ga), torej dolžino vsebine datoteke.

Sedaj pa na prizorišče prispejo posredniški strežniki za HTTP. Slednje ponavadi postavijo pred aplikacije, ki same strežejo HTTP, recimo z namenom dodajanja avtentikacije, predpomnjenjem odzivov ali pa za izdelavo navideznih strežnikov, ki zahtevo posredujejo aplikaciji glede na podatek Host v zaglavju zahteve.

Ko govorimo o informacijski varnosti in se opredelimo na aplikacije za posredniškimi strežniki, najprej omenimo napade tihotapljenja zahtev. Za te napade je značilno to, da posredniški strežniki in aplikacije za njimi različno obravnavajo dva načina, s katerima lahko pošiljatelj specificira, kako dolgo je telo zahteve, ki jo pošilja. To stori s podatki v zaglavju -- Content-Length in Transfer-Encoding: chunked. Slednji je namenjen zahtevam, pri katerih pošiljatelj ob začetku zahteve še ne ve, kako velike bodo -- telo zahteve pošilja po kosih, vsakič pa navede, kako velik bo prihajajoči kos, vse dokler ne pride do zadnjega kosa.

Če odjemalec pošlje zahtevo z obema podatkoma v zaglavju, se lahko zgodi, da bo posredniški strežnik upošteval drug način podajanja velikosti zahteve kot zaledna aplikacija. Tako se lahko v kritičnem primeru zgodi, da medtem ko posredniški strežnik misli, da je nek podatek še vedno del telesa zahteve, aplikacija zadaj to vidi kot dve ločeni zahtevi. To tehniko lahko napadalec uporabi, da v cevovod zahtev iz posredniškega strežnika vrine svojo zahtevo tja, kjer bi morala biti samo ena zahteva, s čimer desinhronizira posrednika in aplikacijo zadaj, ko za komunikacijo ohranjata eno TCP povezavo med različnimi zahtevami. Če je namen posredniškega strežnika zagotavljanje avtorizacije, je napadalcu uspelo vriniti zahtevo brez avtorizacije. Poleg tega lahko z desinhronizacijo pripravi HTTP strežnik, da pošlje odgovor na njegovo zahtevo nekemu drugemu odjemalcu.

Več o klasičnem napadu si preberite na anglešlki Wikipediji: en.wikipedia.org/wiki/HTTP_request_smuggling

Meni manj znan način napada storitev s tihotapljenjem zahtev pa je izkoriščanje zahtev HEAD. Ker odgovor na zahtevo z metodo HEAD vsebuje identično zaglavje kot enaka zahteva z metodo GET (GET in HEAD se obnašata funkcionalno -- ne smeta spremeniti nobenega stanja), torej tudi Content-Length, a je brez vsebine, je edini način, da posredniški strežnik izve, da podatki za zaglavjem, prejeti od aplikacije, niso več del tega odgovora, to, da si zapomni, da je prejel in posredoval zahtevo z metodo HEAD. Tihotapljenje zahteve z metodo HEAD zato prinaša dodatne preglavice, ker lahko tako napadalec pošlje odjemalcem popolnoma poljuben odgovor (nastavlja lahko tudi zaglavje).

Za to zanimivo dejstvo in potencialen način izkoriščanja sem izvedel, ko sem gledal posnetek predavanja Martina Doyhenarda z lanske konference DEF CON 30 z naslovom "Exploiting Interprocess Communication": youtu.be/pLosVyt8L9Q?t=1398 (ob času 23:18)