Jsou CSRF stále aktuální?

Dobrý den, snažil jsem se si něco o CSRF přešíst, vše, co mi google nabídl, jsou články 2008 - 2012. Něajký pořádný článek 19/20 jsem nenašel a tak se ptám. Ošetřujete své formuláře tokenama? Jak? Má to smysl? Ptám se, protože doba významně pokročila a třeba už dneska běžné CSRF útoky nefungují díky PHP 7 (používám php 7.3) nebo se to ošetřuje na straně nastavení webhostingů či prohlížečů. Opravdu o tomto tématu moc nevím. Se session pracuji na denní bázi a budu rád, když mi řeknete, jak so ošetřujete vstupní formuláře (login hlavně) vy a zda-li bych se měl CSRF zabývat více také či se už není čeho bát :) Děkuji

Vetsina asi pouziva frameworky. Napr. ja delam svoje projekty v Symfony a tam CSRF jede.

CSRF je nutné používat, každý to bere asi už jako samozřejmost, frameworky to mají jako nativní součást. PHP 7 nic samo neošetřuje, nemá jak.

Urcite stale aktualni a nutno osetrit. Jak jsi prisel na to, ze si s tim php7 samo poradi?

Ano, a moderní frameworku to řeší automaticky ( např nette, symfony)

CSRF řeší CORS. To je řešení na straně prohlížeče, lze obejít. Pozor na technologie jako jsou Websockets, na ty se CORS nevztahuje.Jinými slovy, stále je třeba používat token.

Zdravím, děkuji za zpětné vazby. Na něco málo jsem se koukal. Našel jsem velice jednoduché řešení, ALE....! Stačí, když v login.php si na začátku dokumentu vytvořil token, pro příklad uvádím toto: $_SESSION = bin2hex(random_bytes(24)); a tento token si dal do hidden pole ve formuláři, po odeslání formuláře si v souboru, kde zpracovávám formulář napsal něco ve smyslu tohoto... if (hash_equals($_SESSION, $_POST)) { // je platný } else { // není platný } a tím je hotovo? Vskutku je to tak jednoduché nebo v tomto vidíte problém? Děkuji pěkně za doporučení, rady, tipy. M.

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

Napsal josef.jebavy;1592331

Ano, a moderní frameworku to řeší automaticky ( např nette, symfony)

nette to praveze automaticky neriesi, je nutne csrf zapinat pre kazdy formular rucne (aspon to tak bolo) ... berem spat, vidim, ze uz to konecne prerobili

Napsal ne;1592358

nette to praveze automaticky neriesi, je nutne csrf zapinat pre kazdy formular rucne (aspon to tak bolo)

To neplatí od myslím Nette 3.0, kdy je CSRF zapnutý automaticky a je možné ho volitelně deaktivovat, viz aktuální dokumentace https://doc.nette.org/cs/3.0/vulnerability-protection. Stejně tak to je automaticky zapnuté u Symfony i Laravel. Všichni asi usoudili, že bezpečnost by měla být ve výchozím stavu zapnutý a vypínat jí, když vím proč a nikoliv naopak.

asi najjednoduchsie riesenie je vygenerovat token, symetricky zasifrovat, ulozit ho do cookies zo samesite Strict ..pri generovani form-u zobrat tuto cookie, desifrovat a jej obsah pouzit ako token (pripadne posolit, zahashovat)..po odoslani formu overit prichadzajuci token s tokenom v cookies..netreba potom ziadne session, databazu a pod... v principe je to neprestrelne---------- Příspěvek doplněn 31.07.2020 v 12:06 ----------

Napsal TomášX;1592359

To neplatí od myslím Nette 3.0, kdy je CSRF zapnutý automaticky a je možné ho volitelně deaktivovat, viz aktuální dokumentace https://doc.nette.org/cs/3.0/vulnerability-protection. Stejně tak to je automaticky zapnuté u Symfony i Laravel. Všichni asi usoudili, že bezpečnost by měla být ve výchozím stavu zapnutý a vypínat jí, když vím proč a nikoliv naopak.

ano, z pohladu bezpecnosti je lepsie, ak ma formular automaticku ochranu, ktoru zabudnem vypnut, ako vynutenu, ktoru zabudnem zapnut.. je fajn, ze uz to upravili---------- Příspěvek doplněn 31.07.2020 v 12:12 ----------

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é.

....

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ář.

v tomto pripade ale musis dbat nato, aby kazdy vygenerovany token bol platny a zneplatnit iba ten pouzity.. a to kvoli moznosti, ze uzivatel bude mat formular otvoreny viac krat (vo viac taboch) ... tu ale potom vidim problem v riziku velkeho mnozstva vygenerovanych tokenov, ktore sa nasledne nepouziju

Napsal ne;1592361

asi najjednoduchsie riesenie je vygenerovat token, symetricky zasifrovat, ulozit ho do cookies zo samesite Strict ..

pri generovani form-u zobrat tuto cookie, desifrovat a jej obsah pouzit ako token (pripadne posolit, zahashovat)..

po odoslani formu overit prichadzajuci token s tokenom v cookies..

netreba potom ziadne session, databazu a pod... v principe je to neprestrelne

hashovat nebo jinak zamaskovat původní hodnotu, kterou mám u sebe je samozřejmě dobré, při ukládání do databáze to nemá smysl řešit jinak. U cookies je pak nezbytné nastavit SameSite=Strict nebo aspoň lax flag, jinak je obrana nedostatečná. Při šifrování token do cookies je potřeba správně zvolit nonce a sůl, aby se zabránilo replay útoku, což je největší slabina tohoto algoritmu, dělá se v tom příliš chyb a pak je obrana neúspěšná.Nechtěl jsem do tohoto způsobu řešení CSRF zabředávat, přináší to mnohem více pastí než pamatování tokenů a jejich validace. Při revizích zabezpečení webových aplikací je právě při použití encryption nebo HMAC nejvíce nalezených chyb (české prostředí enterprise aplikací). Dokonce z dnešního pohledu ani ukázková poslední stabilní implementace od OWASP (CSRFGuard) v javě není dobře udělaná.

Napsal ne;1592361

v tomto pripade ale musis dbat nato, aby kazdy vygenerovany token bol platny a zneplatnit iba ten pouzity.. a to kvoli moznosti, ze uzivatel bude mat formular otvoreny viac krat (vo viac taboch) ... tu ale potom vidim problem v riziku velkeho mnozstva vygenerovanych tokenov, ktore sa nasledne nepouziju

Jednorázové použití v ukázkovém kódu řeším, přetečení uložiště tokenů jen zmiňuji. Proto je lepší použít databázi, kde ta kapacita je vyšší a je více času promazání. U session je musí omezovat počet, případně doplnit timestamp a dělat retenci při každém přidání nového. V produkčních aplikacích nasazujeme třeba Redis či jinou databázi, která má TTL a tokeny se generují jen s pár minutovou platností a pak se promazávají. Jeden redis cluster pak dává kapacitu i 100m tokenů za hodinu.

pri samesite Strict aplikacia nedostane cookie s tokenom, neni co s cim porovnat, formular je neplatnybez samesite ho sice dostane, ale utocnik by musel poslat spravny token, co pri nejakej rozumnej dlzke je nerealnesamozrejme ale za podmienky, ze token v cookies neunikne cez XSS (httponly) a pod.. ak je spravne zasifrovany, tak v podstate ani unik nevadi (berem spat - toto by vlastne vadilo :D )netvrdim, ze je tento sposob dokonaly (to urcite nie), ale pokryje potrebu 99% webov..---------- Příspěvek doplněn 31.07.2020 v 12:34 ----------

Napsal Michael91;1592320

... Se session pracuji na denní bázi a budu rád, když mi řeknete, jak so ošetřujete vstupní formuláře (login hlavně) vy a zda-li bych se měl CSRF zabývat více také či se už není čeho bát :)

Děkuji

login nebyva predmetom utoku csrf.. podstata csrf spociva v nevedomom vykonavani akcii uz prihlaseneho uzivatela, ktorych o tychto akciach netusi, z cudzich stranok.. napr. odoslanie penazi, zmena uctu, udajov a pod...samozrejme aj akcie neprihlasenych uzivatelov (fake nakupy v konkurencom eshope a pod)

Ano, Samesite=strict znamená, že formulář musím mít na stejné stránce jako action pro něj, např. login.php musí zajišťovat oboje (vykreslení i zpracování).Ú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) a provádět tzv. replay attack, o tom jsem mluvil, bránit se tomu dát tak, že token šifruji se solí, která pochází ze session uživatele a k tomu tam je třeba časový údaj. Pokud dovolím vícekrát použít stejný token, pořád je možný útok na jakémkoliv cizím webu ve stylu , prohlížeč pošle odpovídající cookies s token, které má uložené, stačí aby návštěvník již na tom webu před tím byl.Správně by token tedy měl být nepředvídatelný, použitelný pouze jednou a pro konkrétní formulář (ideálně svázaný i s readonly hodnotami), jinak jeho funkce není dostatečná. Webová aplikace by také měla bránit opakovaným (třeba 100+) pokusům o poslání formuláře s neplatným tokenem.