Et angrep på front-end-back-end-systemer som lar oss kile inn forespørsler fra tredjeparter

Avslørt detaljer om et nytt angrep på nettsteder som bruker en front-end-back-end-modell, for eksempel de som kjører gjennom innholdsleveringsnettverk, lastbalansere eller proxyer. Angrepet tillater, ved å sende visse forespørsler, å kile seg inn i innholdet i andre forespørsler behandlet i samme tråd mellom frontend og backend. Den foreslåtte metoden ble vellykket brukt til å organisere et angrep som gjorde det mulig å avskjære autentiseringsparametrene til brukere av PayPal-tjenesten, som betalte forskere rundt 40 tusen dollar som en del av et program for å informere om tilstedeværelsen av uopprettede sårbarheter. Angrepet gjelder også nettsteder som bruker Akamais innholdsleveringsnettverk.

Problemets kjerne er at frontends og backends ofte gir ulike nivåer av støtte for HTTP-protokollen, men samtidig kapsler inn forespørsler fra ulike brukere i en felles kanal. For å koble frontend-mottaksforespørsler og backend-behandlingsforespørsler, etableres en langvarig TCP-forbindelse, gjennom hvilken brukerforespørsler overføres, overført langs kjeden etter hverandre, atskilt ved hjelp av HTTP-protokollen. For å skille forespørsler, overskriftene "Content-Length" (bestemmer den totale størrelsen på dataene i forespørselen) og "Overføringskoding: biter"(lar deg overføre data i deler, spesifisere blokker av forskjellige størrelser i formatet "{størrelse}\r\n{blokk}\r\n{størrelse}\r\n{blokk}\r\n0").

Problemet oppstår hvis frontend bare støtter "Content-Length", men ignorerer "Transfer-Encoding: chunked" (for eksempel Akamai CDN gjorde dette) eller omvendt. Hvis Transfer-Encoding: chunked støttes på begge sider, kan implementeringsfunksjonene til HTTP-header-parsere brukes til et angrep (for eksempel når grensesnittet ignorerer linjer 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", og backend behandler dem vellykket).

I dette tilfellet kan en angriper sende en forespørsel som inneholder både "Content-Length" og "Transfer-Encoding: chunked"-hodene, men størrelsen i "Content-Length" tilsvarer ikke størrelsen på den delte kjeden, som er mindre enn den faktiske verdien. Hvis frontend behandler og videresender forespørselen i henhold til "Content-Length" og backend venter på at blokkeringen skal fullføres basert på "Transfer-Encoding: chunked", vil slutten av dataene basert på "Transfer-Encoding: chunked" bestemmes tidligere og den gjenværende delen av forespørselen vil angriperen være i begynnelsen av neste forespørsel, dvs. angriperen vil kunne legge ved vilkårlige data til begynnelsen av en annens forespørsel som sendes neste gang.

For å fastslå problemet i den brukte frontend-backend-kombinasjonen, kan du sende en forespørsel som dette via frontend:

POST /om HTTP/1.1
Vert: example.com
Overføringskoding: biter
Content-Length: 4

1
Z
Q

Problemet er tilstede hvis backend ikke umiddelbart behandler forespørselen og venter på ankomsten av den endelige nullgrensende blokken med biter av data. For en mer fullstendig sjekk forberedt et spesielt verktøy som også tester mulige metoder for å skjule "Transfer-Encoding: chunked"-headeren fra frontend.

Å utføre et reelt angrep avhenger av egenskapene til det angrepne nettstedet, for eksempel når du angriper Trello-nettapplikasjonen, kan du erstatte begynnelsen av forespørselen (erstatte data som "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) og send en melding som inkluderer den opprinnelige forespørselen fra en tredjepartsbruker og autentiseringsinformasjonskapselen spesifisert i den. For et angrep på saas-app.com viste det seg å være mulig å erstatte JavaScript-kode i svaret ved å erstatte den i en av forespørselsparameterne. For angrepet på redhat.com ble en intern behandler brukt til å omdirigere til angriperens nettsted (en forespørsel på skjemaet "POST /search?dest=../assets/idx?redir=//[e-postbeskyttet]/ HTTP/1.1").

Bruk av metoden for innholdsleveringsnettverk gjorde det mulig å ganske enkelt erstatte det forespurte nettstedet ved å erstatte "Host:"-overskriften. Angrepet kan også brukes til å forgifte innholdet i innholdsbufringssystemer og trekke ut bufrede konfidensielle data. Toppen av metoden var organiseringen av et angrep på PayPal, som gjorde det mulig å avskjære passord sendt av brukere under autentisering (iframe-forespørselen ble endret for å kjøre JavaScript i sammenheng med paypal.com/us/gifts-siden, for hvilken CSP (Content Security Policy) som ikke ble brukt).

Interessant nok var det i 2005 foreslått en i hovedsak lik forespørselsspoofing-teknikk som lar deg forfalske data i caching-proxyer (Tomcat, squid, mod_proxy) eller omgå brannmurblokkering ved å spesifisere flere "GET" eller "POST"-forespørsler i én HTTP-økt.

Kilde: opennet.ru