Administrativní subdoména nezastaví CSRF: čtyři kontroly před spuštěním

Přesun administrativního rozhraní na admin.example.com je skutečné zlepšení: drží administrativní cookies mimo veřejné stránky, dává oběma aplikacím oddělené cache a umožňuje nasměrovat přísnější síťovou politiku na jedno jméno hostitele. Není to ale kontrola proti CSRF a nečiní kód veřejného webu bezpečným pro ponechání otevřený přihlášenému správci. Oddělení mění to, co prohlížeč považuje za hranici, ne to, co kontroluje server, proto proveďte tyto čtyři kontroly, než to prohlásíte za hotové.

Čtěte origin a web jako dvě různá slova

Origin je schéma, hostitel a port, takže https://www.example.com a https://admin.example.com jsou různé originy. Web ve smyslu SameSite je schéma plus registrovaná doména, takže tato dvě jména hostitele jsou obvykle stejný web. Ten rozdíl je celá past: atribut SameSite vám nepomůže mezi sesterskými subdoménami, protože prohlížeč požadavek vůbec nepovažuje za cross-site. Nasměrujte administrativní rozhraní na skutečně jinou registrovanou doménu, například admin-example.net, a požadavek se skutečně stane cross-site, a právě tam začne SameSite=Lax nebo Strict dělat práci, na kterou se lze spolehnout.

Otestujte to v prohlížeči, místo abyste o tom uvažovali.

Načtěte veřejný web, otevřete vývojářské nástroje a podívejte se, které cookies prohlížeč přiloží k požadavku na administrativního hostitele. Pokud cookie nemá atribut Domain, je jen pro hostitele a zůstává na svém jménu; pokud nese Domain=example.com, putuje ke každému sestru a nová subdoména vám pro tuto cookie nic nepřinesla.

Oddělte může přečíst odpověď od může poslat požadavek

Politika stejného originu omezuje čtení odpovědí mezi originy. Nezastavuje odeslání požadavku a nebrání formuláři nést přihlašovací údaje, které prohlížeč už má. Jednoduchý požadavek, s typem obsahu formuláře nebo obyčejným GET, se doručí bez předběžné kontroly; CORS pak rozhodne, zda volající skript smí odpověď číst. CSRF žije zcela na straně odesílání.

Proto server potřebuje výslovnou kontrolu pro operace měnící stav. Synchronizační token vázaný na relaci, nebo cookie dvojího odeslání porovnávaná na serveru, pokrývá případ; porovnání Origin nebo Referer stojí za to přidat jako druhou bránu, ale ne jako jedinou, protože ne každý požadavek nese hlavičku a ne každý proxy ji zachová. Pokyny OWASP k prevenci CSRF považují SameSite za jednu vrstvu mezi několika právě proto.

Rozhodněte, co síťová brána skutečně dokazuje

Seznam povolených výstupů VPN před administrativním hostitelem je dobrá kontrola a slabé tvrzení o identitě. Dokazuje, že požadavek přišel z adresy, kterou VPN přiděluje, kterou mohou sdílet všichni na tomto výstupu, a nic neříká o tom, kdo za ní stojí. Berte ho jako vstupní filtr, ne jako autentizaci.

Udržujte ho nezávislý na kontrolách na úrovni požadavku. Pokud je seznam jediná věc mezi útočníkem a koncovým bodem měnícím stav, jedna špatně nakonfigurovaná trasa, jeden klient se split-tunnel nebo jeden půjčený notebook kontrolu zcela odstraní.

Zaznamenávejte i odmítnutí mimo očekávané rozsahy. Jejich nápor je nejužitečnější signál, že někdo zkoumá hranici, kterou jste právě postavili, a ticho je signál, že se filtr vůbec nezasahuje.

Udržujte cookies, přihlášení a autorizaci výslovné

Rozsah cookie rozhoduje většinu výsledku. Cookie rodičovské domény se posílá administrativnímu hostiteli, takže injektáž skriptu na veřejném webu může jednat s relací správce; cookie jen pro hostitele nemůže. Preferujte formu jen pro hostitele, přidejte atribut Secure a použijte prefix __Host-, kde ho platforma podporuje, protože tento prefix vyžaduje Secure, Path=/ a žádný atribut Domain. Čtěte hlavičku odpovědi, ne sklenici cookies: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, bez atributu Domain. Prohlížeč zahodí cookie __Host- s Domain, takže cookie, která se stále objevuje na sesterských hostitelích, je důkaz, že prefix nebyl nikdy použit.

Potom držte autorizaci na serveru, pro každý požadavek, na každém administrativním koncovém bodu, ne jen při přihlášení. Požadavek z povolené sítě musí být stále autentizován a autorizován pro operaci, kterou žádá; jméno hostitele není aktér. Pokud veřejná a administrativní aplikace sdílejí přihlašovací tok nebo úložiště relací, zapište ten vztah, protože je to nejkratší cesta od chyby na veřejném webu k administrativní akci.

Znovu zkontrolujte hranici po oddělení

Spusťte negativní testy, ne jen šťastnou cestu: cross-site formulář bez tokenu musí být odmítnut, token z jiné relace musí být odmítnut a žádný GET nesmí měnit stav. Zkontrolujte atributy cookies ve vývojářských nástrojích, potvrďte, že kontrola Origin se spustí u neodpovídajícího požadavku, a zkuste administrativního hostitele zvenčí rozsahu VPN, abyste viděli filtr v akci.

Nic z toho neodstraňuje chybu XSS uvnitř samotné administrativní aplikace. Oddělené jméno hostitele je hranice izolace na straně prohlížeče se skutečnou hodnotou a není náhradou za prevenci nebezpečného spouštění kódu ani za ochranu požadavků na straně serveru. Po oddělení je seznam kratší, než vypadá: odlišný origin, cookies jen pro hostitele, token na každou změnu, vstupní filtr, kterému nevěříte jako identitě, a autorizace rozhodovaná pro každý požadavek.