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

1. 8. 2020 22:30:39

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

1. 8. 2020 22:30:39

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459108

node

(5 hodnocení)

2. 8. 2020 00:16:05

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

samozrejme sa pocita s tym ze na identifikaciu usera sa pouziva cookie a ktora je taktiez spravne nastavena

2. 8. 2020 00:16:05

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459107

TomasX

(4 hodnocení)

2. 8. 2020 08:33:13

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

Napsal node;1592454
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.

2. 8. 2020 08:33:13

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459106

(22 hodnocení)

2. 8. 2020 10:03:52

Napsal node;1592454
ak je user prihlaseny, tak riesit csrf tokeny je uplne zbytocne.

prave naopak, ak je prihlaseny tak csrf je este nebezpecnejsie

2. 8. 2020 10:03:52

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459105

node

(5 hodnocení)

2. 8. 2020 12:49:41

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.

2. 8. 2020 12:49:41

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459104

TomasX

(4 hodnocení)

2. 8. 2020 13:14:41

Napsal node;1592486
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.

2. 8. 2020 13:14:41

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459103

(20 hodnocení)

2. 8. 2020 13:54:39

node sry, ale to ani nemuzes myslet vazne... A ja myslel ze delas v IT, to delas uklizecku v avastu nebo jak? Machas tu vzdycky cisly kde jakej neberes plat a pak nam tu budes tvrdt ze osetreni CSRF je zbytecny... To ze to za tebe delaj frameworky, jestli vubec, te fakt neomlouva, to z tebe akorat dela script kidda...

2. 8. 2020 13:54:39

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459102

node

(5 hodnocení)

3. 8. 2020 10:11:00

ales, lichoti mi, ze si prisiel do tejto temy komentovat na moju osobu a neprispel nicim k povodnej otazke. ale mohol by si ma uz prestat spehovat, nie je to dobre pre tvoje dusevne zdravie.

.. pisal som ze tieto veci(ie. web/html frontend) uz dlho nerobim(ie. 5-6 rokov), asi si uz od toho navalu adrenalinu pocas pisania komentaru zabudol aj citat. taktiez tu nikde o mojom plate nespamujem, "Machas tu vzdycky" je znacne premrstene, kedze som o tomto napisal len jeden jediny komentar za celu historiu co som na webtrhu a aj to len genericky, bez specifickych udajov. mam pocit ze som sa ti zabyval v psyché a nevies prestat na mna mysliet od kedy som tu zacal davat prispevky o globalnom ekonomickom podvode zvanom covid-19 a vies ze mam pravdu ale ego ti nedovoli si to priznat :)

3. 8. 2020 10:11:00

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459101

crs

(1 hodnocení)

3. 8. 2020 17:36:01

Napsal ne;1592469
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?

3. 8. 2020 17:36:01

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459100

TomasX

(4 hodnocení)

3. 8. 2020 17:53:14

Napsal crs;1592644
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í

3. 8. 2020 17:53:14

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459099

(22 hodnocení)

3. 8. 2020 20:31:47

Napsal crs;1592644
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

3. 8. 2020 20:31:47

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459098

TomasX

(4 hodnocení)

4. 8. 2020 12:08:28

tady je třeba aktuální napadení Zoom konferencí, kdy chyba byla způsobena špatnou implementací CSRF a neomezeným počtem pokusů na heslo (pin). https://www.tomanthony.co.uk/blog/zoom-security-exploit-crack-private-meeting-passwords

Učebnicová chyba, kterou udělala firma s 2500 zaměstnanci, valuací v desítkách mld poskytující primárně online služby. Tady se řeší, že CSRF nemá smysl pro přihlášené uživatele...

4. 8. 2020 12:08:28

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459097

crs

(1 hodnocení)

8. 8. 2020 12:19:16

https://www.tomanthony.co.uk/blog/zoom-security-exploit-crack-private-meeting-passwords

"Error 522 - Connection timed out"

8. 8. 2020 12:19:16

https://webtrh.cz/diskuse/csrf-pro-vice-otevrenych-stejnych-formularu/#reply1459096

crs

(1 hodnocení)

8. 8. 2020 12:19:31