En attack mot front-end-back-end-system som gör att vi kan kila in i förfrågningar från tredje part

Avslöjat detaljer om en ny attack på webbplatser som använder en front-end-back-end-modell, till exempel de som körs genom innehållsleveransnätverk, lastbalanserare eller proxyservrar. Attacken tillåter, genom att skicka vissa förfrågningar, att kila in i innehållet i andra förfrågningar som behandlas i samma tråd mellan frontend och backend. Den föreslagna metoden användes framgångsrikt för att organisera en attack som gjorde det möjligt att avlyssna autentiseringsparametrarna för användare av PayPal-tjänsten, som betalade forskare cirka 40 tusen dollar som en del av ett program för att informera om förekomsten av opatchade sårbarheter. Attacken är även tillämplig på webbplatser som använder Akamais innehållsleveransnätverk.

Kärnan i problemet är att frontends och backends ofta ger olika nivåer av stöd för HTTP-protokollet, men samtidigt kapslar in förfrågningar från olika användare i en gemensam kanal. För att koppla ihop frontend-mottagningsförfrågningarna och backend-bearbetningsförfrågningarna upprättas en långlivad TCP-anslutning, genom vilken användarförfrågningar sänds, sänds längs kedjan en efter en, åtskilda med hjälp av HTTP-protokollet. För att separera förfrågningar, rubrikerna "Content-Length" (bestämmer den totala storleken på data i begäran) och "Överföringskodning: chunked"(låter dig överföra data i delar, ange block av olika storlekar i formatet "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Problemet uppstår om frontend bara stöder "Content-Length" men ignorerar "Transfer-Encoding: chunked" (till exempel Akamai CDN gjorde detta) eller vice versa. Om Transfer-Encoding: chunked stöds på båda sidor, kan implementeringsfunktionerna för HTTP-header-parsers användas för en attack (till exempel när gränssnittet ignorerar rader som "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked" ”, “Transfer-Encoding” :[tab]chunked”, "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" eller "Transfer-Encoding: chunked", och backend bearbetar dem framgångsrikt).

I det här fallet kan en angripare skicka en begäran som innehåller både rubrikerna "Content-Length" och "Transfer-Encoding: chunked", men storleken i "Content-Length" motsvarar inte storleken på den chunked kedjan, vilket är mindre än det faktiska värdet. Om frontend bearbetar och vidarebefordrar begäran enligt "Content-Length" och backend väntar på att blocket ska slutföras baserat på "Transfer-Encoding: chunked", kommer slutet av data baserat på "Transfer-Encoding: chunked" att fastställas tidigare och den återstående svansen av begäran kommer angriparen att vara i början av nästa begäran, dvs. angriparen kommer att kunna bifoga godtycklig data till början av någon annans begäran som skickas nästa.

För att fastställa problemet i den använda frontend-backend-kombinationen kan du skicka en begäran så här via frontend:

POST /om HTTP/1.1
Värd: example.com
Överföringskodning: chunked
Content-Length: 4

1
Z
Q

Problemet uppstår om backend inte omedelbart bearbetar begäran och väntar på ankomsten av det sista nollgränsande blocket med bitar av data. För en mer komplett kontroll beredd ett speciellt verktyg som också testar möjliga metoder för att dölja rubriken "Transfer-Encoding: chunked" från frontend.

Att utföra en riktig attack beror på kapaciteten hos den attackerade webbplatsen, till exempel när du attackerar Trello webbapplikation kan du ersätta början av begäran (ersätt data som "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) och skicka ett meddelande inklusive den ursprungliga begäran från en tredjepartsanvändare och autentiseringskakan som anges i den. För en attack mot saas-app.com visade det sig vara möjligt att ersätta JavaScript-kod i svaret genom att ersätta den i en av förfrågningsparametrarna. För attacken på redhat.com användes en intern hanterare för att omdirigera till angriparens webbplats (en begäran av formen "POST /search?dest=../assets/idx?redir=//[e-postskyddad]/ HTTP/1.1").

Att använda metoden för innehållsleveransnätverk gjorde det möjligt att helt enkelt ersätta den begärda webbplatsen genom att ersätta rubriken "Host:". Attacken kan också användas för att förgifta innehållet i innehållscachesystem och extrahera cachad konfidentiell data. Toppen av metoden var organiseringen av en attack mot PayPal, som gjorde det möjligt att avlyssna lösenord som skickats av användare under autentisering (iframe-begäran modifierades för att exekvera JavaScript i sammanhanget för paypal.com/us/gifts-sidan, för vilken CSP (Content Security Policy) som inte tillämpades).

Intressant nog fanns det 2005 erbjöd en i huvudsak liknande förfrågningsförfalskningsteknik som låter dig förfalska data i cachingproxyer (Tomcat, squid, mod_proxy) eller kringgå brandväggsblockering genom att ange flera "GET"- eller "POST"-förfrågningar inom en HTTP-session.

Källa: opennet.ru