CSRF tokenek hackelése a CSS History Hack használatával

Frissítés: Sirdarckcat és Gareth biztonsági kutatók olyan kedvesek voltak, hogy megosszák a tiszta CSS alapú CSRF token kereső kódját. Ez lopakodóbb, mint az alábbiakban szereplő PoC-m, amelyben mind a JS, mind a CSS kombinációját használtam. Tehát akkor is működni fog, ha letiltja a javascriptet, és már nem vagy biztonságban :(:( . Annak érdekében, hogy ez a PoC jobban reagáljon az ügyféllel, több CSS stíluslapot kell használnia az import paranccsal. Az egyetlen probléma, amelyet ezzel a tiszta CSS-alapú megközelítéssel látok, a hálózati késés a nagy kulcsterületekkel jár, mivel a nagy CSS stíluslapot a böngészőnek kell letöltenie..


Gondolkodtam a helyszíni kérés-hamisítás problémájára és az iparágban alkalmazott jelenlegi enyhítési stratégiákra. Az eddig tesztelt valós alkalmazások közül sokban véletlenszerű tokenek használatát látom az url részeként. Ha a kérelem nem nyújt semmilyen jogkivonatot, vagy nem ad helytelen értékű tokent, akkor a kérelmet elutasítják. Ez megakadályozza a CSRF vagy bármilyen domain közötti jogosulatlan funkció végrehajtását.

Mostanáig lehetetlennek tartották, hogy a támadók felfedezzék a CSRF-tokent a kiszolgálón lévő Brute Force Attacks segítségével..

Ennek okai:

  1. Ez generál sok zaj van a hálózaton, és lassú. Tehát valószínűleg az IDS vagy a Web App tűzfal felveszi a rosszindulatú viselkedést és blokkolja az ip-t. Például egy 5 karakterből álló Base16 CSRF token (karakterrel kezdve) körülbelül 393 216 kérést generál.
  2. Számos alkalmazás van beprogramozva érvényteleníti a munkamenetet miután bizonyos számú kérést érvénytelen token értékkel észlel. Például. 30.

Meg fogom változtatni ezt a hiedelmet, bemutatva egy technikát, amellyel gyorsan cserf tokeneket találhat riasztások generálása nélkül. Ez a technika a ügyféloldali támadás, tehát szinte nincs hálózati forgalom, így a szerver és az IDS / Web App tűzfalak nyertek’egyáltalán nem veszi észre. Ez a támadás a népszerű CSS History Hack-en alapul, amelyet Jeremiah Grossman 3 évvel ezelőtt talált.

Ebben a kihasználásban felfedezzük a csrf jogkivonatot azzal, hogy brutálisan kényszerítjük a böngésző előzményeiben a különböző URL-halmazokat. Megpróbáljuk beágyazni a csrf token értékeit az url részeként, és ellenőrizni fogjuk, hogy a felhasználó meglátogatta-e az URL-t. Ha igen, akkor nagy esély van arra, hogy a felhasználó ugyanazt a CSRF-jogkivonatot használja az aktuális aktív munkamenetben, vagy előfordulhat, hogy ezt a jogkivonatot egy előző munkamenetben is felhasználta. Miután megvan egy lista az ilyen jogkivonatokról, csak kipróbálhatjuk a csrf támadást a szervernél az a kis lista segítségével. Jelenleg ez a támadás legfeljebb öt karakter hosszú tokenek esetében lehetséges. Kipróbáltam egy base16 hosszúságú, 5 hosszúságú húron, és kevesebb, mint 2 perc alatt meg tudtam erőltetni a teljes kulcsterületet.

Ennek a támadásnak néhány előfeltétele vagy

  1. A CSRF token változatlan marad egy adott felhasználói munkamenetnél. például. csrf token = hash (session_id) VAGY
  2. Ugyanazon üléshez régebbi formában benyújtott CSRF-token elfogadásra kerül. Sokszor ez a helyzet, mivel javítja a felhasználói élményt, és lehetővé teszi az előre és a hátsó böngésző gombjainak használatát.

A koncepció igazolása itt érhető el.
A PoC futtatása előtt meg kell változtatnia az url és a csrftoken paramater értékeket.

Az alapértelmezés szerinti teszteléshez először meg kell látogatnia a következő URL-ek egyikét, pl.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [változtassa meg a b59fe-t bármely 5 számjegyű 16 karakterláncra, kezdve karakterrel, azaz nagyobb, mint a0000]
  2. http://tinyurl.com/l2lwgd [ami 301 átirányítás az előző URL-re].

Jegyzet: A http://www.securethoughts.com és a https://securethoughts.com eltérően kezelik, miközben a böngésző előzményeiben tárolják.

A mintafuttatás így néz ki -

hackelés a csrf tokenekkel css előzményekkelhackelés a csrf tokenekkel css előzményekkel

Azért, mert ez a támadás lehetetlenné vált,

Szerveroldali megoldás (fejlesztők számára):

  • Tegye CSRF tokeneit elég hosszúra (8 vagy több karakter) ahhoz, hogy a CLIENT SIDE támadáshoz lehetetlenné váljanak. Az egyre növekvő feldolgozási teljesítmény lehetővé teszi ezt a támadást hosszabb tokenek számára is.
  • Tárolja a CSRF-tokent rejtett űrlapmező részeként, ahelyett, hogy beírná az URL-t.
  • Használjon különféle véletlenszerű jogkivonatot minden űrlap benyújtásához, és ne fogadjon el elavult jogkivonatot, még ugyanazon munkamenetnél.

Ügyféloldali megoldás (az ügyfelek / felhasználók számára):

  • Használjon olyan böngésző-bővítményt, mint például a SafeHistory, amely megvédi a látogatott linkeken alapuló nyomkövetési technikákat.
  • Használja a böngésző privát böngészési módját.

És utoljára, de nem utolsósorban, az XSS megsemmisíti az összes lehetséges CSRF-védelmet. Tehát először megszabaduljon az XSS-től.

Szeretnék köszönetet mondani Jeremiahnak, aki áttekinthető visszajelzést adott erről a postráról.

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me