Hakiranje tokenjev CSRF z uporabo zgodovine CSS

Posodobitev: Raziskovalca za varnost Sirdarckcat in Gareth sta bila dovolj prijazna, da sta tukaj lahko delila kodo za čisto iskalno žetone CSRF na osnovi CSS. To je bolj skrbno kot moj PoC spodaj, ki je uporabil kombinacijo JS in CSS. Tako bo še vedno delovalo, tudi če onemogočite JavaScript in niste več varni :(:( . Če želite, da je ta PoC bolj odziven na odjemalca, morate z ukaznim uvozom uporabiti več tabel slog CSS. Edina težava, ki jo vidim pri tem čistem pristopu, ki temelji na CSS, je, da bodo omrežne zamude vključene v velike ključne prostore, ker bo vaš brskalnik moral prenesti velik tabelo stilov CSS.


Razmišljal sem o problematiki krivotvorenja spletnih strani in trenutnih strategijah za ublažitev posledic, ki se uporabljajo v industriji. V številnih aplikacijah iz resničnega sveta, ki sem jih doslej preizkusil, vidim uporabo naključnih žetonov, priloženih kot del URL-ja. Če zahteva ne posreduje nobenega žetona ali poda token z napačno vrednostjo, potem je zahteva zavrnjena. S tem preprečite nepooblaščeno izvrševanje funkcij CSRF ali kakršne koli navzkrižne domene.

Nazadnje se je napadalcu zdelo, da je z uporabo Brute Force Attacks na strežniku odkril vaš žeton CSRF..

Razlogi so:

  1. To ustvarja veliko hrupa v omrežju in je počasen. Tako bo najverjetneje požarni zid IDS ali spletna aplikacija pobral zlonamerno vedenje in blokiral vaš ip. Na primer, žeton CSRF Base16 v dolžini 5 znakov (začenši z znakom) bo ustvaril približno 393 216 zahtev.
  2. Veliko programov je programiranih razveljavi sejo ko zazna več kot določeno število zahtev z neveljavnimi vrednostmi žetona. Npr. 30.

To prepričanje bom spremenil tako, da vam bom pokazal tehniko za hitro iskanje žetonov csrf brez generiranja opozoril. Ta tehnika je strankin napad, tako da skoraj ni ustvarjenega omrežnega prometa, zato so zmagali vaš strežnik in požarni zidovi IDS / Web App’sploh ne opazim. Ta napad temelji na priljubljenem zgodovinskem kraku CSS, ki ga je pred tremi leti našel Jeremiah Grossman.

V tem izkoriščanju odkrijemo žeton csrf tako, da silovito prisili različni nabor URL-jev v zgodovini brskalnika. Poskusili bomo vdelati različne vrednosti žetona csrf kot del URL-ja in preverili, ali ga je uporabnik obiskal. Če je odgovor pritrdilen, obstaja velika verjetnost, da uporabnik bodisi uporablja isti žeton CSRF v trenutni aktivni seji ali pa je to žeton uporabil v prejšnji seji. Ko imamo seznam vseh takšnih žetonov, lahko preprosto poskusimo naš napad csrf na strežnik s tem majhnim seznamom. Trenutno je ta napad izvedljiv za žetone z dolžino 5 znakov ali krajše. Preizkusil sem ga na nizu16, dolžine 5, in uspel je s silovitim pritiskom celoten ključni prostor v manj kot 2 minutah.

Nekateri predpogoji za ta napad so enaki

  1. Oznaka CSRF ostane enaka za določeno uporabniško sejo. npr. csrf token = hash (session_id) ALI
  2. Oznaka CSRF, poslana v starejših obrazcih za isto sejo, je sprejeta. To je že večkrat, saj izboljšuje uporabniško izkušnjo in omogoča uporabo gumbov brskalnika naprej in nazaj.

Dokaz koncepta je na voljo tukaj.
Preden zaženete PoC, morate spremeniti vrednosti parametrov URL in csrftoken.

Če želite preizkusiti uporabo privzetih nastavitev, morate najprej obiskati enega od naslednjih URL-jev, npr.

  1. https://secureoughts.com/?param1=val1&csrftoken = b59fe [spremenite b59fe v kateri koli 5-mestni niz 16, ki se začne z znakom, tj. večji od a0000]
  2. http://tinyurl.com/l2lwgd [kar je 301 preusmeritev na prejšnji URL].

Opomba: Med shranjevanjem v zgodovini brskalnika http://www.secureoughts.com in https://secureoughts.com obravnavata drugače.

Vzorčni poizkus bo videti tako -

kramp csrf žetone z uporabo css history hackkramp csrf žetone z uporabo css history hack

Ker je ta napad neizvedljiv,

Rešitev na strani strežnika (za razvijalce):

  • Naj bodo vaše žetone CSRF dovolj dolge (8 ali več znakov), da niso možne za napad na KLIJENT SIDE. Vedno večja procesorska moč bo ta napad izvedljiva tudi za daljše žetone.
  • Žeton CSRF shranite kot del skritega obrazca, namesto da vstavite URL.
  • Za vsako oddajo obrazca uporabite drugačen naključni žeton in ne sprejmite nobenega zastarelega žetona, niti za isto sejo.

Odjemalska rešitev (za vaše stranke / uporabnike):

  • Uporabite vtičnik brskalnika, kot je SafeHistory, ki se brani pred tehnikami sledenja na podlagi obiskanih povezav.
  • V brskalniku uporabite način zasebnega brskanja.

In nenazadnje, XSS odpravi vse možne zaščite CSRF. Torej, najprej se znebite XSS.

Rad bi se zahvalil Jeremiji za ta, da je preučil mnenje o tej objavi.

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