a front-end-back-end modellt használó webhelyek elleni új támadás részletei, például azok, amelyek tartalomszolgáltató hálózatokon, terheléselosztókon vagy proxykon futnak. A támadás bizonyos kérések elküldésével beékelődik más kérések tartalmába, amelyeket ugyanabban a szálban dolgoznak fel a frontend és a backend között. A javasolt módszerrel sikeresen megszervezték azt a támadást, amely lehetővé tette a PayPal szolgáltatás felhasználóinak hitelesítési paramétereinek lehallgatását, amely mintegy 40 ezer dollárt fizetett a kutatóknak egy program részeként, hogy tájékoztassák a javítatlan sérülékenységek jelenlétéről. A támadás az Akamai tartalomszolgáltató hálózatot használó webhelyekre is alkalmazható.
A probléma lényege, hogy a frontendek és a háttérrendszerek gyakran különböző szintű támogatást nyújtanak a HTTP protokollhoz, ugyanakkor a különböző felhasználóktól érkező kéréseket egy közös csatornába foglalják. A frontend fogadó kérések és a háttér feldolgozó kérések összekapcsolására egy hosszú élettartamú TCP kapcsolat jön létre, amelyen keresztül a felhasználói kérések továbbítása, egymás után, a lánc mentén, HTTP protokollal elválasztva történik. A kérelmek elkülönítéséhez a „Content-Length” (meghatározza a kérelemben szereplő adatok teljes méretét) és a „"(lehetővé teszi az adatok részenkénti átvitelét, különböző méretű blokkokat ad meg a következő formátumban: "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").
A probléma akkor jelentkezik, ha a frontend csak a „Content-Length”-t támogatja, de figyelmen kívül hagyja a „Transfer-Encoding: chunked” (például az Akamai CDN ezt tette) vagy fordítva. Ha a Transfer-Encoding: chunked mindkét oldalon támogatott, a HTTP-fejléc-elemzők megvalósítási funkciói használhatók támadásokhoz (például amikor a kezelőfelület 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", és a háttérrendszer sikeresen feldolgozza őket).
Ebben az esetben a támadó küldhet egy kérést, amely tartalmazza a "Content-Length" és a "Transfer-Encoding: chunked" fejlécet is, de a "Content-Length" mezőben lévő méret nem egyezik meg a darabolt lánc méretével. kisebb, mint a tényleges érték. Ha a frontend a "Content-Length" szerint dolgozza fel és továbbítja a kérelmet, és a backend a "Transfer-Encoding: chunked" alapján várja a blokk befejezését, akkor a "Transfer-Encoding: chunked" alapján az adatok vége korábban kell meghatározni, és a kérés hátralévő vége a támadó a következő kérés elején lesz, azaz. a támadó tetszőleges adatot tud csatolni valaki más által továbbított kérés elejéhez.
A használt frontend-backend kombináció problémájának meghatározásához a következőhöz hasonló kérést küldhet a frontenden keresztül:
POST /a HTTP-ről/1.1
Házigazda: example.com
Átviteli kódolás: darabolt
Content-Length: 4
1
Z
Q
A probléma akkor jelentkezik, ha a háttérrendszer nem dolgozza fel azonnal a kérést, és várja a darabolt adatok végső nulla határoló blokkjának megérkezését. A teljesebb ellenőrzés érdekében egy speciális segédprogram, amely a „Transfer-Encoding: chunked” fejléc elrejtésének lehetséges módszereit is teszteli a frontendről.
A valódi támadás végrehajtása a megtámadott webhely képességeitől függ, például a Trello webalkalmazás megtámadásakor lecserélheti a kérés elejét (helyettesítő adatok, például „PUT /1/members/1234... x=x&csrf =1234&felhasználónév=testzzz&bio=cake”), és küldjön egy üzenetet egy harmadik fél felhasználó eredeti kérelmével és az abban megadott hitelesítési cookie-val. A saas-app.com elleni támadásnál kiderült, hogy a válaszban a JavaScript-kódot be lehet cserélni az egyik kérési paraméterben. A redhat.com elleni támadásnál egy belső kezelőt használtak a támadó webhelyére való átirányításra (a következő formátumú kérés: „POST /search?dest=../assets/idx?redir=//[e-mail védett]/ HTTP/1.1").
A tartalomszolgáltató hálózatokra vonatkozó módszer használata lehetővé tette a kért webhely egyszerű cseréjét a „Host:” fejléc helyettesítésével. A támadás a tartalom-gyorsítótárazó rendszerek tartalmának mérgezésére és a gyorsítótárazott bizalmas adatok kinyerésére is használható. A módszer csúcsát a PayPal elleni támadás megszervezése jelentette, amely lehetővé tette a felhasználók által a hitelesítés során küldött jelszavak lehallgatását (az iframe kérést úgy módosították, hogy a paypal.com/us/gifts oldal kontextusában JavaScriptet hajtson végre, melyik CSP-t (Tartalombiztonsági szabályzatot) nem alkalmazták).
Érdekes módon 2005-ben volt egy lényegében hasonló kéréshamisítási technika, amely lehetővé teszi a gyorsítótárazó proxykban (Tomcat, squid, mod_proxy) lévő adatok meghamisítását vagy a tűzfal blokkolásának megkerülését azáltal, hogy egy HTTP-munkameneten belül több „GET” vagy „POST” kérést ad meg.
Forrás: opennet.ru