CSRF pro více otevřených stejných formulářů

Zdravím.
Jaká je nejlepší praktické řešení CSRF pro více otevřených oken se stejným formulářem? (příklad: admin si otevře 5 formulářů pro přidání nového záznamu, plní je a v náhodném pořadí odesílá).

Já něco podobného řešil tím, že formulářové tokeny jsem držel v poli - kontrola tokenu tak byla kontrolou, zda-li se odeslaný token nachází v tomto poli.
Je to vhodné řešení? Je nějaké lepší?
Je nutné párovat token s jeho konkrétním formulářem vzhledem k vysokému počtu kombinací (např. 32 bitů = 1 : 4 mld.)?
Jak byste řešili (vzhledem k uvedenému příkladu s adminem s pěti formuláři), kdyby ten některé z těch oken zavřel. Mám řešit, že některé z tokenů nebudou nikdy zpárovány a obslouženy?
Díky

ak je user prihlaseny, tak riesit csrf tokeny je uplne zbytocne.

Pamatovat si všechny v poli s časem a url formuláře, po nějaké době je promaž (hodin, den). Většinou je implementuji v databázi, kde jsou pro všechny uživatele a kam ukládám jen jejich osolený hash, aby nebylo možné nikdy získat všechny tokeny. Pro admin rozhraní má databáze větší smysly, těch tokenů může být aktivních hodně a lépe se řeší retence než když jsou v session.

Za mě je důležité, aby každý formulář na každé otevřené stránce měl svůj unikátní token. Někdy to sice lze nějak sdružovat, aby se bezpečnostní úroveň udržela vysoko, ale je to pak zbytečně komplexní a může tak vzniknout fatální chyba. Každý otevřený formulář = unikátní token dobře pamatuje i implementuje, prostě při renderu formuláře ten token vytvořím, uložím a hotovo.

Malý tip, tokeny pak mají i jinou výhodu, jednoznačně mi identifikuji formulář, takže tím brání duplicitním příspěvkům, jak se třeba dějí tady.

V některých admin rozhraních, které jsou více SPA než cokoliv jiného, tak tokeny si načítám dopředu nebo po každém poslání formuláře v odpovědi stránka dostane novou sadu tokenû. Ani počet uživatelů není problém, takovýhle system používá interně třwba jeden z našich operátorů.

Původně odeslal node ↪

ak je user prihlaseny, tak riesit csrf tokeny je uplne zbytocne.

To je hodně špatná rada, jako domácí úkol si jdi na wiki a nastuduj si co vůbec CSRF je. Pokud se totiž do nějaké služby přihlásíš, CSRF brání tomu, aby na cizí stránce nemohl nikdo posílat vyplněné formuláře tvým jménem. V prohlížeči, když něco pošleš ze stránky B na stránku A, pošlou se tam cookies ke stránce A, tj. i včetně session cookies, takže pak ze stránky B můžeš posílat vyplněné formuláře. Např. u facebooky by jakákoliv jiná stránka mohla posílat tvým jménem nové příspěvky, komentovat či dělat cokoliv, kdyby facebook neměl implementovaný CSRF.

Původně odeslal node ↪

ak je user prihlaseny, tak riesit csrf tokeny je uplne zbytocne.

prave naopak, ak je prihlaseny tak csrf je este nebezpecnejsie

hadat sa nebudem. urcite je lepsie pridat viac zabezpecnia nez menej, len mi to proste pride torsku zbytocne....ale tieto veci uz dost dlho, manualne, neriesim, takze asi preto mam "bias".

anyway, k povodnej otazke - do formularu vygenerujes nahodny string(napriklad uuid), ten vezmes, spojis ho s url alebo id formularu(a kludne aj usera), ktory riesis. k tomu das nejaky staticky salt/secret a vygenerujes hash ktory bude sluzit ako csrf token. oba posles s formularom userovi a pri odoslani formularu userom len znovu vygenerujes hash a porovnas s prijatym stringom a tokenom.

pripadne to mozes zjednodusit len s jednym jwt namiesto dvoch, pripadne len nejakym znakom(.) oddelis obe hodnoty ak nechces mat dva skryte inputy ale iba jeden.

v skratke ide len o hmac. teda user ma jeden kluc(ten prvy nahodny string) a hash a ty mas na servery druhy kluc(salt).

ten nahodny string sluzi ako identifikacia requestu/instancie/udalosti, preto musi byt unikatny. cize ked si admin otvori 5 formularov tak bude mat 5 roznych klucov a pri odoslani forularu sa validuje ci odoslane udaje su zhodne s instanciu formularu ktory bol vygenerovany.

Původně odeslal node ↪

hadat sa nebudem. urcite je lepsie pridat viac zabezpecnia nez menej, len mi to proste pride torsku zbytocne....ale tieto veci uz dost dlho, manualne, neriesim, takze asi preto mam "bias".

Právě naopak, u přihlášení teprve CSRF nabývá na důležitosti a je to primární cíl proč vznikl. Přihlášená stránka v jiném tabu/okně prohlížeče byla takhle zranitelná a proto se jednu dobu doporučovalo odhlašovat se z webů, když jdu jinám. Dnes na to máme CSRF, který efektivně zabraňuje zneužití.

Na stránkách OWASPu máš třeba popsaný jednoduchý vektor útoku, kterýmu CSRF brání. https://owasp.org/www-community/attacks/csrf#examples

Je chybné to zlehčovat na úroveň, že podle tebe to je zbytečné. V počítačové bezpečnosti nikdo neumí každou zranitelnost zneužít a proto se musí primárně dodržovat společná pravidla pro zabezpečení a nikoliv dodržovat pouze to, čemu já rozumím. Útočník je zpravidla chytřejší než autoři daného SW, protože se na ty zranitelnosti specializuje.

HMAC je jen jeden z možných algoritmů a osobně ho nedoporučuji, protože zavádí složist, při CI a častých změnách to zbytečně komplikuje provoz a je náchylný na vyzrazení příliš moc informací a tak predikovatelný token.

Původně odeslal ne ↪

prave naopak, ak je prihlaseny tak csrf je este nebezpecnejsie

Můžeš prosím popsat, jak je CSRF ještě nebezpečnější po přihlášení uživatele?

Původně odeslal crs ↪

Můžeš prosím popsat, jak je CSRF ještě nebezpečnější po přihlášení uživatele?

přečti si moje odpovědi, kde to vysvětluji, v posledním příspěvku jsem dal i odkaz, kde ty jednoduché typy útoků ukazují

Původně odeslal crs ↪

Můžeš prosím popsat, jak je CSRF ještě nebezpečnější po přihlášení uživatele?

To je vtip? Precitaj si podstatu, princip, ucel, csrf utoku