Hacking CSRF Tokeny pomocí CSS History Hack

Aktualizace: Bezpečnostní vědci Sirdarckcat a Gareth byli natolik laskaví, že zde mohli sdílet kód pro čistě vyhledávač tokenů CSRF založený na CSS. To je složitější než můj PoC níže, který používal kombinaci obou JS a CSS. Takže to bude fungovat, i když zakážete javascript a už nejste v bezpečí :(:( . Chcete-li, aby toto PoC lépe reagovalo na klienta, musíte použít více stylů CSS stylů pomocí příkazu import. Jediný problém, který vidím s tímto čistě přístupem založeným na CSS, spočívá v tom, že s velkým prostorem klíčů bude docházet k latenci sítě, protože váš velký styl stylů CSS bude muset stáhnout váš prohlížeč..


Přemýšlel jsem o problému padělání na různých stránkách a o současných strategiích zmírňování používaných v průmyslu. V mnoha aplikacích skutečného světa, které jsem doposud testoval, vidím použití náhodných tokenů připojených jako součást adresy URL. Pokud požadavek neposkytne žádný token nebo neposkytne token s nesprávnou hodnotou, žádost se zamítne. Tím se zabrání CSRF nebo jakémukoli neautorizovanému provádění funkcí napříč doménami.

Doposud bylo pro útočníka považováno za nemožné objevit váš token CSRF pomocí útoků Brute Force Attacks na serveru..

Důvody jsou:

  1. Vytváří se hodně šumu v síti a je pomalý. Pravděpodobně tedy IDS nebo webová aplikace Firewall zachytí škodlivé chování a zablokuje váš IP. Například token Base16 CSRF o délce 5 znaků (počínaje znakem) vygeneruje přibližně 393 216 požadavků.
  2. Je naprogramováno mnoho aplikací zneplatnit vaši relaci poté, co zjistí více než určitý počet požadavků s neplatnými hodnotami tokenu. Např. 30.

Tuto víru změním tím, že vám ukážu techniku, jak rychle najít tokeny csrf bez generování výstrah. Tato technika je útok na straně klienta, takže nedochází téměř k síťovému provozu, a proto váš server a brány firewall IDS / Web App vyhrály’vůbec si toho nevšiml. Tento útok je založen na populárním hacku CSS History Hack, který našel Jeremiah Grossman před 3 lety.

V této exploitaci objevíme token csrf tak, že násilím nutíme různé sady adres URL v historii prohlížeče. Jako součást adresy URL se pokusíme vložit různé hodnoty tokenů CSRF a zkontrolujeme, zda uživatel navštívil tuto adresu URL. Pokud ano, existuje dobrá šance, že uživatel v aktuální aktivní relaci použije stejný token CSRF nebo jej mohl použít v předchozí relaci. Jakmile máme seznam všech takových tokenů, můžeme zkusit náš csrf útok na server pomocí tohoto malého seznamu. V současné době je tento útok proveditelný pro tokeny s délkou 5 nebo méně znaků. Vyzkoušel jsem to na řetězci base16 o délce 5 a dokázal jsem brutálně vynutit celý klíčový prostor za méně než 2 minuty.

Některé z předpokladů, aby tento útok fungoval, jsou buď

  1. Token CSRF zůstává stejný pro konkrétní relaci uživatele. např. csrf token = hash (session_id) OR
  2. Token CSRF odeslaný ve starších formulářích pro stejnou relaci je přijat. Mnohokrát je tomu tak proto, že to zvyšuje uživatelský komfort a umožňuje použití tlačítek prohlížeče vpřed a vzad.

Ověření konceptu je k dispozici zde.
Před spuštěním PoC musíte změnit hodnoty parametrů URL a csrftoken.

Pro testování pomocí výchozích nastavení musíte nejprve navštívit jednu z následujících adres URL, např.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [změňte b59fe na libovolný 5místný řetězec základní 16 začínající znakem, tj. větší než a0000]
  2. http://tinyurl.com/l2lwgd [což je 301 přesměrováno na předchozí adresu URL].

Poznámka: Při ukládání do historie prohlížeče se s http://www.securethoughts.com a https://securethoughts.com zachází odlišně..

Ukázkový běh bude vypadat takto:

pomocí tokenů CSS historiepomocí tokenů CSS historie

Za to, že tento útok nebyl proveditelný,

Řešení na straně serveru (pro vývojáře):

  • Udělejte své tokeny CSRF dostatečně dlouho (8 a více znaků), aby byly pro útok KLIENTSKÉ STRANY nepoužitelné. Stále se zvyšující výkon zpracování umožní tento útok provést i pro delší tokeny.
  • Ukládejte token CSRF jako součást skrytého pole formuláře, nikoli do adresy URL.
  • Pro každý odeslaný formulář použijte jiný náhodný token a nepřijměte žádný zastaralý token, a to ani pro stejnou relaci.

Řešení na straně klienta (pro vaše zákazníky / uživatele):

  • Použijte plugin prohlížeče, jako je SafeHistory, který se brání proti technikám sledování založených na navštívených odkazech.
  • Používejte v prohlížeči režim soukromého prohlížení.

A v neposlední řadě XSS eliminuje všechny možné ochrany CSRF. Nejprve se tedy zbavte XSS.

Chtěl bych poděkovat Jeremiášovi za poskytnutí jeho bystré zpětné vazby k tomuto příspěvku.

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