Frontend-backend támadás, amely lehetővé teszi a harmadik fél kéréseinek megszakítását.

Kibővült a új támadás részletei olyan webhelyek ellen, amelyek a front-end-back-end modellt használják, például a tartalomszolgáltató hálózatokon, terhelésmegosztókon vagy proxykon keresztül működnek. A támadás lehetővé teszi, hogy bizonyos kérések küldésével beékelődjenek más kérések tartalmába, amelyeket ugyanabban a folyamatban dolgoznak fel a front-end és a back-end között. A javasolt módszert sikeresen alkalmazták egy olyan támadás létrehozására, amely lehetővé teszi a PayPal szolgáltatás felhasználóinak hitelesítési paramétereinek elfogását, amely körülbelül 40 ezer dollárt fizetett a kutatóknak a javítatlan sebezhetőségek jelentési program keretében. A támadás alkalmazható az Akamai tartalomszolgáltató hálózatot használó webhelyek számára is.

A probléma lényege, hogy a front-endek és a back-endek gyakran eltérő szintű HTTP protokoll támogatást nyújtanak, miközben különböző felhasználók kéréseit egy közös csatornába zárják. A kérdéseket fogadó front-end és a válaszokat feldolgozó back-end között egy tartós TCP-kapcsolat jön létre, amelyen keresztül a felhasználói kérések sorban, az HTTP protokoll eszközeivel elválasztva továbbítódnak. A kérések elválasztásához használhatók a „Content-Length” fejléc (amely meghatározza az adatkeresés összesített méretét) és aTransfer-Encoding: chunked” (amely lehetővé teszi az adatok darabokban történő átadását, különböző méretű blokkok megadásával a következő formátumban: „{méret}\r\n{blokk}\r\n{méret}\r\n{blokk}\r\n0”).

A probléma akkor jelentkezik, ha a front-end csak a „Content-Length” támogatását biztosítja, miközben figyelmen kívül hagyja a „Transfer-Encoding: chunked” (például az Akamai CDN így járt el) vagy fordítva. Ha mindkét oldal támogatja a „Transfer-Encoding: chunked”-t, a támadás során a HTTP fejléc feldolgozóinak implementációs sajátosságait használják ki (például amikor a front-end figyelmen kívül hagyja az olyan sorokat, mint a „Transfer-Encoding: xchunked”, „Transfer-Encoding: chunked”, „Transfer-Encoding:[tab]chunked”, „X: X[\n]Transfer-Encoding: chunked”, „Transfer-Encoding[\n]: chunked” vagy „Transfer-Encoding : chunked”, míg a back-end sikeresen feldolgozza azokat).

Ebben az esetben a támadó olyan kérést küldhet, amelyben egyszerre szerepel a „Content-Length” fejléc és a „Transfer-Encoding: chunked”, de a „Content-Length” mérete nem felel meg a chunked-lánc méretének, amely kisebb a tényleges értéknél. Ha a frontend a „Content-Length” szerint dolgozza fel és továbbítja a kérést, míg a backend a „Transfer-Encoding: chunked” alapján várja a blokk végét, akkor az adatok vége a „Transfer-Encoding: chunked” alapján hamarabb meg lesz határozva, és a támadó kérésének hátralevő része a következő kérés elején fog megjelenni, azaz a támadó lehetőséget kap arra, hogy tetszőleges adatokat fűzzön egy idegen kérés elejéhez, amelyet következőleg továbbítottak.

A frontend-backend kombinációban felmerülő probléma meghatározásához a frontend segítségével egy ilyen kérdést lehet küldeni:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

A probléma jelen van, ha a backend azonnal nem dolgozza fel a kérést, és várja a chunked-adatok végső nullás határoló blokk jövőbeli megérkezését. A teljesebb ellenőrzés érdekében elkészült speciális eszköz, amely teszteli a „Transfer-Encoding: chunked” fejléc frontend általi elrejtésének lehetséges módjait.

A valódi támadás végrehajtása a támadott weboldal képességeitől függ. Például a Trello webalkalmazás ellen támadva módosítani lehetett a kérés kezdetét (például az „PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake” formátum felhasználásával) és elküldeni egy üzenetet, amely tartalmazza egy külső felhasználó eredeti kérését és az abban szereplő hitelesítési Cookie-kat. A saas-app.com elleni támadás során lehetséges volt JavaScript-kód beszúrását végrehajtani a válaszban, egy a kérés paraméterei közé történő beillesztéssel. A redhat.com elleni támadás során egy belső feldolgozót használtak a támadó weboldalára való átirányításhoz (például a „POST /search?dest=../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1” kérés megadásával).

A tartalomkiszolgáló hálózatok alkalmazásának módszere lehetővé tette a kért webhely egyszerű helyettesítését a „Host:” fejléc helyettesítésével. A támadás szintén alkalmazható a tartalomelőszűrő rendszerek manipulálására és bizalmas adatok cache-elt másolataiból való kinyerésére. A módszer csúcspontját a PayPal elleni támadás képezte, amely lehetővé tette a felhasználók által azonosításkor elküldött jelszavak elfogását (az iframe kérések megváltoztatásával JavaScript futtatása a paypal.com/us/gifts oldal keretein belül, amelyre nem vonatkozott a CSP (Content Security Policy)).

Érdekes módon 2005-ben volt a egy hasonló technika, amely lehetővé tette a kérések helyettesítését, és az adatokat cache-elő proxykban (Tomcat, squid, mod_proxy) vagy tűzfalak megkerülését, több „GET” vagy „POST” kérést megadva egy HTTP-munkamenen belül.

Forrás: opennet.ru