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

Napsal node;1592454

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

Vás bych nechtěl mít jako dodavatele webu nebo aplikace.

@ne: @TomášX: Pardon - místo CSRF jsem myslel a měl v hlavě "opatření proti CSRF". To byl zdroj nedorozumění. Má chyba.

Napsal TomášX;1592748

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

Asi máš na mysli implementací proti CSRF, předpokládám.Odkaz už konečně funguje a mohl jsem si to přečíst. A ne, toto konkrétně není případ, kde by opatření proti CSRF zamezilo danému útoku; autor to výslovně zmiňuje.

The failure on the CSRF token made it even easier to abuse than it would be otherwise, but fixing that wouldn’t provide much protection against this attack.

Také nedůsledně zaměňuji CSRF a ochranu proti CSRF, většinou ale jako důsledek zkratky v diskuzi, kdy je jasné o čem se mluví.CSRF je vyloženě klientská strana a ochrana pouze přidává bariéry proti zneužití. U Zoomu byl hlavní problém možnost zkoušet neomezené pokusy při hádání hesla. Chybějící CSRF jen výrazně ulehčilo útok, zároveň má Zoom implementovanou ochranu proti robotickému opakování načtení stránky, ale pouze pro GET a nikoliv POST, takže se řádně implementovaným CSRF by to útok prodloužilo pravděpodobně na dny a nikoliv na minuty. O tom se již v článku ale nezmiňuje moc konkrétně.U Zoomu jde vidět hlavní problém, díky neúčinné ochraně proti CSRF mohl útočník zkoušet neomezeně pokusy na heslo aniž by musel načíst nejdříve stránku a projít běžnou validací při generování stránky s formulářem, tím elegantně obešel i ty malé ochrany co Zoom měl. Pořád ale platí, že by veškeré formuláře měly mít implementovanou ochranu proti hromadnému využívání (QoS, rate limiting, blocklist či cokoliv) a to bez ohledu na implementaci ochrani CSRF.

Napsal TomášX;1593312

Také nedůsledně zaměňuji CSRF a ochranu proti CSRF, většinou ale jako důsledek zkratky v diskuzi, kdy je jasné o čem se mluví.

CSRF je vyloženě klientská strana a ochrana pouze přidává bariéry proti zneužití. U Zoomu byl hlavní problém možnost zkoušet neomezené pokusy při hádání hesla. Chybějící CSRF jen výrazně ulehčilo útok, zároveň má Zoom implementovanou ochranu proti robotickému opakování načtení stránky, ale pouze pro GET a nikoliv POST, takže se řádně implementovaným CSRF by to útok prodloužilo pravděpodobně na dny a nikoliv na minuty. O tom se již v článku ale nezmiňuje moc konkrétně.

U Zoomu jde vidět hlavní problém, díky neúčinné ochraně proti CSRF mohl útočník zkoušet neomezeně pokusy na heslo aniž by musel načíst nejdříve stránku a projít běžnou validací při generování stránky s formulářem, tím elegantně obešel i ty malé ochrany co Zoom měl. Pořád ale platí, že by veškeré formuláře měly mít implementovanou ochranu proti hromadnému využívání (QoS, rate limiting, blocklist či cokoliv) a to bez ohledu na implementaci ochrani CSRF.

V podstatě říkáš "CSRF by útok ztížilo, ale nezabránilo by mu." Na tom se shodneme. (Takže příklad, který jsi uvedl, není ten, kde by selhání CSRF zapříčinilo únik dat nebo útok.)

Dovolim si nechapat.. Csrf nema nic spolocne s brute force utokom, co bol asi primarny problem.. Teda predpokladam o co slo v zoome.. Tu csrf zohralo zanedbatelnu ulohu, utok by vysiel aj bez neho

Zoom má na formulář pro zadávání hesla do konverzace rate limiting, captchu a nedovolí stažení stovek stránek zasebou, to je tak ochrana. Při CSRF ochraně je nutné tu stránku pokaždé stáhnout a až poté poslat post, od toho je CSRF, je to jen malá bariéra. S ní je potřeba útok distribuovat a rozložit v čase.CSRF je opravdu jen na ochranu klientské strany a nikoliv backendů, tam může pomoc, ale nesmí se na to spoléhat.