CSRF žetonų piratavimas naudojant CSS istoriją

Atnaujinimas: Saugumo tyrinėtojai Sirdarckcat ir Gareth buvo malonūs, kad čia galėtų pasidalyti gryno CSS pagrindu veikiančio CSRF prieigos rakto ieškiklio kodu. Tai slaptesnis nei mano toliau pateiktas „PoC“, kuriame buvo naudojamas tiek JS, tiek CSS derinys. Taigi, ji vis tiek veiks, net jei išjungsite „javascript“ ir būsite nesaugūs :(:( . Kad šis „PoC“ geriau reaguotų į klientą, naudodami importavimo komandą turite naudoti keletą CSS stiliaus lentelių. Vienintelė problema, kurią matau naudojant šį grynai CSS pagrįstą požiūrį, yra tinklo vėlavimas, susijęs su didelėmis raktų erdvėmis, nes jūsų didelę CSS stiliaus lentelę turės atsisiųsti jūsų naršyklė..


Aš galvojau apie tarpvalstybinių užklausų klastojimo problemą ir dabartines pramonėje naudojamas švelninimo strategijas. Daugelyje realių programų, kurias iki šiol išbandžiau, matau, kad atsitiktiniai žetonai naudojami kaip URL dalis. Jei užklausoje nepateikiama jokio prieigos rakto arba nepateikiama neteisinga reikšmė, užklausa atmetama. Tai apsaugo nuo CSRF ar bet kokio neteisėto funkcijos vykdymo tarp domenų.

Iki šiol buvo laikoma, kad užpuolikui neįmanoma rasti jūsų CSRF prieigos rakto naudojant „Brute Force Attacks“ serveryje..

Priežastys:

  1. Tai generuoja daug triukšmo tinkle ir yra lėtas. Taigi greičiausiai IDS ar žiniatinklio programų ugniasienė pasirinks kenksmingą elgesį ir užblokuos jūsų IP. Pavyzdžiui, „Base16“ CSRF prieigos raktas, kurio ilgis 5 simboliai (pradedant simboliu) sugeneruos maždaug 393 216 užklausas.
  2. Daugelis programų yra užprogramuotos negaliojančiu jūsų sesijos po to, kai jis aptinka daugiau nei tam tikrą skaičių užklausų su netinkamomis prieigos rakto reikšmėmis. E. g. 30.

Aš pakeisiu šį įsitikinimą parodydamas jums būdą, kaip greitai rasti CSRF žetonus, nesukeliant įspėjimų. Ši technika yra kliento pusės ataka, taigi beveik nesudaromas tinklo srautas, todėl jūsų serveris ir IDS / „Web App“ ugniasienės laimėjo’visai to nepastebi. Ši ataka paremta populiariu CSS History Hack, kurį prieš 3 metus rado Jeremiah Grossman.

Šiuo išnaudojimu mes atrandame csrf prieigos raktą, smarkiai priversdami įvairius URL naršyklės istorijoje. Pabandysime įterpti skirtingas csrf prieigos rakto reikšmes kaip URL dalį ir patikrinsime, ar vartotojas aplankė tą URL. Jei taip, yra didelė tikimybė, kad vartotojas dabartiniame aktyviame seanse naudoja tą patį CSRF prieigos raktą arba galėjo jį naudoti ankstesnėje sesijoje. Kai turėsime visų tokių žetonų sąrašą, galime tiesiog išbandyti savo csrf ataką serveryje naudodami tą mažą sąrašą. Šiuo metu ši ataka yra įmanoma žetonams, kurių ilgis yra 5 ar trumpesni. Aš jį išbandžiau ant „base16“ ilgio 5 ilgio stygų ir per mažiau nei 2 minutes sugebėjau pergudrauti visą rakto vietą.

Tam tikros šios priepuolio prielaidos yra arba

  1. CSRF prieigos raktas tam pačiam vartotojo seansui išlieka tas pats. pvz. csrf token = maišos (session_id) ARBA
  2. Priimamas CSRF prieigos raktas, pateiktas senesnėmis formomis tam pačiam seansui. Daugybė kartų taip yra, nes padidina vartotojo patirtį ir leidžia naudoti naršyklės mygtukus pirmyn ir atgal.

Koncepcijos įrodymas galima rasti čia.
Prieš paleisdami „PoC“, turite pakeisti URL ir csrftoken parametrų reikšmes.

Norėdami išbandyti naudodami numatytuosius nustatymus, pirmiausia turite apsilankyti viename iš šių URL, pvz.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [pakeiskite b59fe į bet kurią 5 skaitmenų bazinę 16 eilutę, pradedant simboliu, t.y., didesne nei a0000]
  2. http://tinyurl.com/l2lwgd [301 peradresavimas į ankstesnį URL].

Pastaba: Saugojant naršyklės istoriją, http://www.securethoughts.com ir https://securethoughts.com yra traktuojami skirtingai..

Bandomasis bėgimas atrodys taip -

CSRF žetonai naudojant CSS istorijąCSRF žetonai naudojant CSS istoriją

Dėl šios atakos neįmanoma,

Serverio pusės sprendimas (kūrėjams):

  • Padarykite savo CSRF žetonus pakankamai ilgus (8 ar daugiau ženklų), kad jie būtų neįmanomi CLIENT SIDE priepuoliui. Dėl vis didėjančios duomenų apdorojimo galios šią ataką bus galima įgyvendinti ir ilgesniems žetonams.
  • Laikykite savo CSRF prieigos raktą kaip paslėpto formos lauko dalį, o ne įkelkite URL.
  • Kiekvienam formos pateikimui naudokite skirtingą atsitiktinį prieigos raktą ir nepriimkite pasenusio prieigos rakto, net tam pačiam seansui.

Kliento sprendimas (jūsų klientams / vartotojams):

  • Naudokite naršyklės papildinį, pvz., „SafeHistory“, kuris apsaugo nuo lankomų nuorodų stebėjimo metodų.
  • Naršyklėje naudokite privataus naršymo režimą.

Ir paskutinis, bet ne mažiau svarbus dalykas - XSS panaikina visas įmanomas CSRF apsaugos priemones. Taigi pirmiausia atsikratykite XSS.

Norėčiau padėkoti Jeremijui už jo įžvalgų atsiliepimą apie šį įrašą.

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