it-swarm-eu.dev

Měl bych používat AntiForgeryToken ve všech formách, dokonce i přihlašovací a registrační?

Každý den provozuji poměrně velké stránky s tisíci návštěvami a poměrně velkou uživatelskou základnu. Od chvíle, kdy jsem začal migrovat na MVC 3, vkládám AntiForgeryToken do řady forem, které upravují chráněná data atd.

Některé jiné formuláře, jako je přihlášení a registrace, také používají AntiForgeryToken nyní, ale já si v první řadě pochybuji o jejich potřebě, a to z několika důvodů ...

Přihlašovací formulář vyžaduje, aby plakát znát správné přihlašovací údaje. Opravdu nemůžu vymyslet žádný způsob, jak by tu byl útok CSRF prospěšný, zejména pokud zkontroluji, že žádost přišla od stejného hostitele (kontrola záhlaví Referera).

Token AntiForgeryToken generuje různé hodnoty při každém načtení stránky. Pokud mám při otevření přihlašovací stránky dvě karty a pokusím se je zveřejnit, první se úspěšně načte. Druhá selže s AntiForgeryTokenException (nejprve načtěte obě stránky a poté je zkuste zveřejnit). S bezpečnějšími stránkami - to je evidentně nezbytné zlo, se přihlašovacími stránkami - vypadá to, že je zbytečné, a prostě žádá o potíže.

Existují možná i jiné důvody, proč by měl být token používán nebo nepoužíván v těch formách. Mám pravdu v předpokladu, že použití tokenu v každé poštovní formě je nadměrné, a pokud ano - jaké formy by z toho měly prospěch a které z nich by rozhodně nebyly prospěšné?

P.S. Tato otázka je také položena na StackOverflow, ale nejsem úplně přesvědčená. Myslel jsem, že bych si to vyžádal zde, pro větší bezpečnostní pokrytí

82
Artiom Chilaru

Ano, je důležité do přihlašovacích stránek zahrnout tokeny proti padělání.

Proč? Vzhledem k možnosti útoků „přihlášení CSRF“. Při přihlašovacím útoku CSRF útočník přihlásí oběť na cílový web pomocí účtu útočníka. Uvažujme například o útoku na Alici, která je uživatelem Paypal, zlým útočníkem Evelynem. Pokud Paypal nechránil své přihlašovací stránky před útoky CSRF (např. Pomocí anti-padělání tokenu), může útočník tiše přihlásit Alice prohlížeč na účet Evelyn na Paypal. Alice se dostane na web Paypal a Alice je přihlášena, ale přihlášena jako Evelyn. Předpokládejme, že Alice poté klikne na stránku a propojí její kreditní kartu s jejím Paypal účtem a zadá její číslo kreditní karty. Alice si myslí, že propojuje svou kreditní kartu se svým účtem Paypal, ale ve skutečnosti ji propojila s účtem Evelyn. Nyní si Evelyn může koupit věci a nechat si ji připsat na Alice kreditní kartu. Jejda. Je to jemné a trochu temné, ale natolik vážné, že byste měli zahrnout tokeny proti padělání pro cíl akce, který se používá k přihlášení. Viz tento článek , kde jsou další podrobnosti a některé příklady skutečného světa zranitelnosti.

Kdy je v pořádku vynechat token proti padělání? Obecně platí, že pokud je cílem adresa URL a přístup k této adrese nemá žádné vedlejší účinky, nemusíte do této adresy URL zahrnout token proti padělání.

Hrubé pravidlo je: do všech žádostí POST žádostí) přidejte token proti padělání, ale pro žádosti GET ho nepotřebujete. Toto hrubé pravidlo je však velmi hrubým přiblížením „Předpokládá se, že požadavky GET budou všechny bez vedlejších účinků. V dobře navržené webové aplikaci by to snad mělo být, ale v praxi někdy návrháři webových aplikací nedodržují tyto pokyny a implementují obsluhy GET. které mají vedlejší účinek (to je špatný nápad, ale není to neobvyklé). Proto navrhuji vodítko založené na tom, zda žádost bude mít vedlejší účinek na stav webové aplikace, nebo ne, namísto na základě GET vs POŠTA.

72
D.W.

Tam, kde by mohlo být nutné mít token na přihlašovací stránce, je potřeba zabránit tomu, aby vás někdo nebezpečně přihlásil na web se zvláštními přihlašovacími údaji. Vidím, že tomu tak je, pokud je někdo orámován pro něco, co vyžaduje přihlášení s konkrétním uživatelem. S tím bylo řečeno, je to trochu vymyslený příklad.

2
Steve