Jsou CSRF stále aktuální?

Napsal TomášX;1592372

... Útočník může vzít token z formuláře a cookies se zašifrovaným tokenem (token lze získat třeba přes XSS zranitelnost, reklamní banery) ...

ziskanie tokenu cez XSS je ale chybou fatalnou.. pokial by utocnik vedel ziskat cookies, tak sa na csrf vykasle a rovno pouzije session cookie na ziskanie identity a vykonavanie zelanych akcii pokial je na webe XSS diera, tak vsetky obrany idu do haja a nemopoze nic.. v momente utoku si cez XSS vytiahnes session cookie obete, s cookie zavolas stranku s formom a mas token na zlatom podnose.. ale ako pisem, je to zbytocne, kedze mam session cookie

I reklamní baner má často přístup na stránku a ne všechny reklamy jsou řádně kontrolovány, viz i zde, zranitelný může být plugin v prohlížeči atd. Stejně tak si útočník může stránku otevřít sám, uložit si cookies a token a opakovaně posílat formulář, to je také případ, kterému má CSRF bránit, ač původně kvůli tomu nevznikl. XSS i CSRF mají společné to, že se jedná o zranitelnosti, které jsou vykonány na straně klienta, kde mohu očekávat různě dobře či špatně konfigurované prostředí.Proto je důležité, aby CSRF token měl jednorázovou platnost a byl omezen časem, tím se brání replay či delay útokům. V logách aplikace bych pak měl být schopný svázat konkrétní vygenerovaný formulář s jeho konkrétním a jediným odesláním, tím dávám zodpovědnost aplikaci, aby měla kontrolu nad daty, které dostane do formuláře.Varianta, kterou jsi navrhl s tokenem a jeho šifrováním do cookies není obecně špatná, jen jsem chtěl upozornit, že v takovéhle jednoduché podobně nebrání všemu, nic víc nic mín. Ani můj příklad, který jsem uvedl není dokonalý. Správně implementovat CSRF není snadné a dá to dost práce. Pokud se dělají javascriptové klientské aplikace, ve velkém se právě používá šifrování tokenu a poslání přes cookies nebo přes vlastní http hlavičku. Klíč pro šifrování je pak součástí klientské aplikace a pravidelně se refreshuje, aby se snížilo okno pro únik a tím vektor útoku.

Napsal TomášX;1592351

Jdeš správným směrem. Neměl bys používat stejný pro každý formulář v rámci sezení, ale generovat nový při každém použití formuláře, jinak to není dostatečně účinné.

random_bytes je zbytečně drahá funkce, může to vést k DoS útokům na tvůj web jen tím, že se bude načítat stránka s formulářem. Doporučuji použít raději openssl_random_pseudo_bytes(24, false), která používá neblokový /dev/urandom (vždy dostaneš nějaká data bez ohledu na množství entropie v OS, není vhodné pro generování klíčů, ale u tokenů, kde jejich predikovatelnost není tak velká zranitelnost to je přijatelný kompromis). hash_equals je funkce s konstantním čase porovnávání (tj. pomalá), která se používá v kryptografii, aby útočník nemohl odhadnout, jak je blízko správné variantě, u porovnávání tokenů, které jsou jednorázové to nedává smysl, naopak lepší je to řešit nějakým QoS.

Token bys měl vztahovat k action adrese formuláře (pokud je uživatel přihlášen nebo má session, tak ještě k uživateli/session) a nedovolit, aby jeden token mohl být použit vícekrát (při první ověření ho musíš smazat) nebo aby se dal použít pro jiný formulář. Stejně tak bys měl učinit rozhodnutí, jestli chceš kvůli formulářům generovat session (cookies a soubor na disku) nebo CSRF uděláš přes databázi. Na některých webech může být session zbytečná brzda a luxus.

Lehká varianta by mohla vypadat nějak takhle, ber to jako inspriaci a ne produkční kód. Osobně bych tam třeba řešil i promazání starých tokenů, abych jich neměl uložen příliš a nebyl to další vektor útoků - zaplnit session storage.

$form_url = "/login.php";

if (!isset($_SESSION)) $_SESSION = array();

if (!sset($_SESSION)) $_SESSION = array();

// login.php - render formu

$token = bin2hex(openssl_random_pseudo_bytes(24, false));

$_SESSION[] = $token

// login.php - process form

$valid_token = false;

if (isset($_POST)) {

foreach($_SESSION as $i => $token) {

if (strcmp($token, $_POST)) {

$valid_token = true;

unset($_SESSION);

}

}

}

// zpracovani formure podle #vaid_token

Jste úžasný, děkuji za Váš čas :) Všem ostatním taky!!!! Abych se přiznal, učím se v Laravelu, ale zatím nejsem v takové pozici, abych si troufl své projekty překopat právě do něj :) proto u současných projektů musím zajistit takovou aktualizaci, aby odpovídala dnešním bezpečnostním standartům a SVÉPOMOCÍ. A to musím udělat tak, jak to zatím umím, ručně psané php.

Napsal TomášX;1592377

... Varianta, kterou jsi navrhl s tokenem a jeho šifrováním do cookies není obecně špatná, jen jsem chtěl upozornit, že v takovéhle jednoduché podobně nebrání všemu, nic víc nic mín. Ani můj příklad, který jsem uvedl není dokonalý ....

tak tak.. bohuzial ziadna ochrana nie je 100% a v podstate vsade sa da najst nejaka slabina ktora sa da zneuzit. Cim zlozitejsia aplikacia, tym viac chyb

Napsal ne;1592415

tak tak.. bohuzial ziadna ochrana nie je 100% a v podstate vsade sa da najst nejaka slabina ktora sa da zneuzit. Cim zlozitejsia aplikacia, tym viac chyb

Jsem zastáncem toho, že bych měl bránit všem známým variantám a ty neznámé být schopný aspoň auditovat a minimalizovat jejich dopady. Proto zabezpečení aplikací (a SW) obecně je vrstvené, rozdělené do perimetrů, které mají každý svoji roli. CSRF a XSS patří do zranitelností na klientské straně, kdy klient se vmanipuluje do chování, které není běžné a ani cílené. V žádném případě nezabezpečují samotný SW a ani by to tak nemělo být, samotný SW by měl být bezpečný i bez nich, ale s nimi ho není možné zneužít na straně klienta k jinému účelu. Např. zde by CSRF nemělo být jedinou obranou proti robotickému zneužití formuláře, ale samotný formulář by měl mít vlastní QoS (či rate limiting, block list). Nepletl bych dohromady složitost aplikace (byznysovou) a její vnitřní členění, jedno je možné od druhého oddělit a mít byznysově složitou aplikaci, která má jasnou strukturu, vnitřní logiku a z toho plynoucí bezpečnost. Wordpress a jiné redakční systémy jsou úspěšným příkladem toho, jak se aplikace z pohledu zabezpečení nemá strukturovat. Vertikální integrace vrstev je dnes přežitek. Naopak třeba linuxový kernel je ukázkovým příkladem jak byznysově složitou aplikaci je možné dělit do horizontálních perimetrů a zachovat zřetelnou strukturu a jednoduché členění. Nepřu se s tebou, máš v tom také pravdu a nemám pocit, že bychom si v tom nerozuměli, jen to chci vysvětlit pro jiné čtenáře, když už se tady to téma objevilo.

suhlasim..len dodam, ze je az s podivom, kolko webov, a to aj weby ktore pracuju s peniazmi, kreditom a pod. nema csrf vobec poriesene..

Hele, jestli se učíš s laravelem, tak si nemusíš vymýšlet vlastní řešení, už je to vymyšlené za tebe https://laravel.com/docs/7.x/csrf