Pokyny ke zmírnění hrozeb pro vykreslování na straně statického serveru ASP.NET Core Blazor

Tento článek vysvětluje aspekty zabezpečení, které by vývojáři měli vzít v úvahu při vývoji Blazor Webových aplikací se statickým vykreslováním na straně serveru.

Blazor kombinuje tři různé modely v jednom pro psaní interaktivních webových aplikací. Tradiční vykreslování na straně serveru, což je model požadavků a odpovědí založený na protokolu HTTP. Interaktivní vykreslování na straně serveru, což je model vykreslování založený na SignalR. Nakonec vykreslování na straně klienta, což je model vykreslování založený na WebAssembly.

Všechny obecné aspekty zabezpečení definované pro režimy interaktivního vykreslování platí Blazor pro Web Apps, pokud existují interaktivní součásti vykreslování v jednom z podporovaných režimů vykreslování. Následující části popisují aspekty zabezpečení specifické pro neinteraktivní vykreslování na straně serveru ve Blazor Službě Web Apps a konkrétní aspekty, které platí při vzájemné interakci s režimy vykreslování.

Obecné aspekty vykreslování na straně serveru

Model vykreslování na straně serveru (SSR) je založený na tradičním modelu požadavků a odpovědí protokolu HTTP. Mezi SSR a protokolem HTTP požadavku/odpovědi jsou proto běžné obavy. Obecné aspekty zabezpečení a konkrétní hrozby se musí úspěšně zmírnit. Architektura poskytuje integrované mechanismy pro správu některých z těchto hrozeb, ale jiné hrozby jsou specifické pro kód aplikace a musí je zpracovat aplikace. Tyto hrozby je možné kategorizovat následujícím způsobem:

• Ověřování a autorizace: Aplikace musí zajistit, aby byl uživatel ověřený a autorizovaný pro přístup k aplikaci a prostředkům, které zveřejňuje. Architektura poskytuje integrované mechanismy pro ověřování a autorizaci, ale aplikace musí zajistit, aby byly mechanismy správně nakonfigurované a používány. Integrované mechanismy ověřování a autorizace jsou popsány v Blazor uzlu zabezpečení serveru v dokumentaci a v uzlu zabezpečení aIdentitydokumentace ASP.NET Core, takže se zde nezabývá.

• Ověření vstupu a sanitizace: Před použitím musí být ověřen a sanitizován veškerý vstup přicházející z klienta. Jinak může být aplikace vystavená útokům, jako je injektáž SQL, skriptování mezi weby, padělání požadavků mezi weby, otevřené přesměrování a další formy útoků. Vstup může pocházet z libovolného místa v požadavku.

• Správa relací: Správná správa uživatelských relací je důležitá, aby se zajistilo, že aplikace není vystavená útokům, jako je oprava relace, napadení relace a další útoky. Informace uložené v relaci musí být správně chráněné a zašifrované a kód aplikace musí zabránit škodlivému uživateli v odhadování nebo manipulaci s relacemi.

• Zpracování chyb a protokolování: Aplikace musí zajistit správné zpracování a protokolování chyb. Jinak může být aplikace vystavená útokům, jako je zpřístupnění informací. K tomu může dojít, když aplikace v odpovědi vrátí citlivé informace nebo když aplikace vrátí podrobné chybové zprávy s daty, která se dají použít k útoku aplikace.

• Ochrana dat: Citlivá data musí být správně chráněná, což zahrnuje logiku aplikace při spuštění ve službě WebAssembly, protože je možné je snadno zpětně analyzovat.

• Odepření služby: Aplikace musí zajistit, aby nebyla vystavena útokům, jako je odepření služby. K tomu dochází například v případě, že aplikace není správně chráněná proti útokům hrubou silou nebo když akce může způsobit, že aplikace spotřebuje příliš mnoho prostředků.

Ověřování vstupu a sanitizace

Veškerý vstup přicházející z klienta musí být považován za nedůvěryhodný, pokud nebyly informace generovány a chráněny na serveru, jako je token CSRF, ověřování cookie, identifikátor relace nebo jakákoli jiná datová část chráněná ověřeným šifrováním.

Vstup je pro aplikaci obvykle dostupný prostřednictvím procesu vazby, například prostřednictvím atributu nebo[SupplyParameterFromForm] atributu[SupplyParameterFromQuery]. Před zpracováním tohoto vstupu musí aplikace zajistit, aby data byla platná. Aplikace například musí potvrdit, že při mapování dat formuláře na vlastnost komponenty nedošlo k žádným chybám vazby. Jinak může aplikace zpracovávat neplatná data.

Pokud se vstup používá k přesměrování, musí aplikace zajistit, aby vstup byl platný a že neodkazuje na doménu, která je považována za neplatnou nebo na neplatnou dílčí cestu v rámci základní cesty aplikace. Jinak může být aplikace vystavena útokům na otevřené přesměrování, kde útočník může vytvořit odkaz, který přesměruje uživatele na škodlivý web.

Pokud se vstup používá k provedení databázového dotazu, aplikace musí potvrdit, že vstup je platný a že aplikaci nevystavuje útokům prostřednictvím injektáže SQL. Jinak může útočník vytvořit škodlivý dotaz, který se dá použít k extrakci informací z databáze nebo k úpravě databáze.

Data, která mohou pocházet ze vstupu uživatele, musí být před zahrnutím do odpovědi také sanitizována. Vstup může například obsahovat kód HTML nebo JavaScript, který lze použít k provádění skriptování mezi weby, které lze použít k extrakci informací od uživatele nebo k provádění akcí jménem uživatele.

Architektura poskytuje následující mechanismy, které vám pomůžou s ověřováním vstupu a sanitizací:

• Všechna data vázaného formuláře jsou ověřena pro základní správnost. Pokud se vstup nedá analyzovat, proces vazby hlásí chybu, kterou aplikace může zjistit před provedením jakékoli akce s daty. Před vyvoláním zpětného volání formuláře tuto součást EditForm bere v úvahu integrovaná komponenta OnValidSubmit . Blazor zabraňuje provádění zpětného volání, pokud existuje jedna nebo více chyb vazby.
• Architektura používá antiforgery token k ochraně před útoky proti padělání požadavků mezi weby. Další informace najdete v tématu ASP.NET Blazor Základní ověřování a autorizace a přehled formulářů ASP.NET CoreBlazor.

Všechny vstupy a oprávnění musí být na serveru ověřeny v době provedení dané akce, aby se zajistilo, že jsou data v daném okamžiku platná a přesná a že uživatel může akci provést. Tento přístup je konzistentní s pokyny zabezpečení, které jsou k dispozici pro interaktivní vykreslování na straně serveru.

Správa relací

Správu relací zpracovává architektura. Architektura používá relaci cookie k identifikaci uživatelské relace. cookie Relace je chráněná pomocí rozhraní API ASP.NET Core Data Protection. Relace cookie není přístupná pro javascriptový kód spuštěný v prohlížeči a uživatel ji nemůže snadno odhadnout ani manipulovat.

Pokud jde o jiná data relace, jako jsou data uložená v rámci služeb, měla by být data relace uložená v rámci služeb s vymezeným oborem, protože služby s vymezeným oborem jsou jedinečné pro danou uživatelskou relaci, a ne služby s jednímtonem, které jsou sdíleny napříč všemi relacemi uživatelů v dané instanci procesu.

Pokud jde o SSR, ve většině případů není mezi vymezeným a přechodným službami moc rozdíl, protože životnost služby je omezená na jeden požadavek. Ve dvou scénářích je rozdíl:

• Pokud je služba vložena do více než jednoho umístění nebo v různých časech během požadavku.
• Pokud může být služba použita v kontextu interaktivního serveru, kde přežije více vykreslení a její základní význam, že je služba vymezena na uživatelskou relaci.

Zpracování chyb a protokolování

Architektura poskytuje integrované protokolování pro aplikaci na úrovni architektury. Rozhraní protokoluje důležité události, jako je například v případě, že se token antiforgery pro formulář nepodaří ověřit, kdy se kořenová komponenta začne vykreslovat a kdy je odeslána akce. Aplikace zodpovídá za protokolování všech dalších událostí, které by mohly být důležité k zaznamenání.

Architektura poskytuje integrované zpracování chyb pro aplikaci na úrovni architektury. Architektura zpracovává chyby, ke kterým dochází při vykreslování komponenty, a buď používá mechanismus hranic chyb k zobrazení popisné chybové zprávy, nebo umožňuje chybě bubliny až do middlewaru pro zpracování výjimek, který je nakonfigurovaný tak, aby vykresloval chybovou stránku.

Chyby, ke kterým dochází při vykreslování streamování po zahájení odeslání odpovědi klientovi, se v konečné odpovědi zobrazí jako obecná chybová zpráva. Podrobnosti o příčině chyby jsou zahrnuty pouze během vývoje.

Ochrana dat

Tato architektura nabízí mechanismy pro ochranu citlivých informací pro danou uživatelskou relaci a zajišťuje, aby integrované komponenty používaly tyto mechanismy k ochraně citlivých informací, jako je ochrana identity uživatele při použití cookie ověřování. Mimo scénáře zpracovávané architekturou zodpovídá kód pro vývojáře za ochranu dalších informací specifických pro aplikace. Nejběžnější způsob, jak to udělat, je prostřednictvím rozhraní API ASP.NET Core Data Protection nebo jakékoli jiné formy šifrování. Obecně platí, že aplikace zodpovídá za:

• Ujistěte se, že uživatel nemůže zkontrolovat nebo upravit soukromé informace jiného uživatele.
• Ujistěte se, že uživatel nemůže upravovat uživatelská data jiného uživatele, například interní identifikátor.

Pokud jde o ochranu dat, musíte jasně pochopit, kde se kód spouští. Pro statické vykreslování na straně serveru (statické SSR) a interaktivní vykreslování na straně serveru (interaktivní SSR) je kód uložen na serveru a nikdy nedosáhne klienta. V režimu interaktivního vykreslení WebAssembly kód aplikace vždy dosáhne klienta, což znamená, že všechny citlivé informace uložené v kódu aplikace jsou dostupné komukoli, kdo má k aplikaci přístup. Obfuskace a další podobné techniky pro "ochranu" kódu nejsou efektivní. Jakmile kód dosáhne klienta, můžete ho zpětně analyzovat tak, aby extrahovali citlivé informace.

Odepření služby

Na úrovni serveru poskytuje architektura omezení parametrů požadavků a odpovědí, jako je maximální velikost požadavku a velikosti hlavičky. Pokud jde o kód aplikace, Blazorsystém mapování formulářů definuje omezení podobná omezením definovaným systémem vazeb modelu MVC:

• Omezte maximální počet chyb.
• Omezte maximální hloubku rekurze pro pořadač.
• Omezte maximální počet prvků vázaných v kolekci.

Kromě toho jsou pro formulář definována omezení, například maximální velikost klíče formuláře a velikost hodnoty a maximální počet položek.

Obecně platí, že aplikace musí vyhodnotit, kdy existuje šance, že požadavek aktivuje asymetrickou práci serverem. Mezi příklady patří, když uživatel odešle parametrizovaný skupinou N a server provede operaci v odpovědi, která je nkrát nákladná, kde N je parametr, který uživatel řídí a může natrvalo růst. Za normálních okolností musí aplikace buď uložit limit maximálního počtu N, který je ochotný zpracovat, nebo zajistit, aby jakákoli operace byla buď menší, rovna nebo dražší než požadavek konstantním faktorem.

Tento aspekt má větší význam s rozdílem v růstu mezi prací, kterou klient provádí, a prací, kterou server provádí, než s konkrétním porovnáním 1→N. Klient může například odeslat pracovní položku (vkládání prvků do seznamu), která trvá několik jednotek času, ale server potřebuje k zpracování N^2^ (protože by mohl dělat něco velmi naivního). Je to rozdíl mezi N a N^2^, na čem záleží.

Proto existuje omezení toho, kolik práce musí být server ochotný, což je specifické pro aplikaci. Tento aspekt platí pro úlohy na straně serveru, protože prostředky jsou na serveru, ale nemusí se ve většině případů v klientovi vztahovat na úlohy WebAssembly.

Dalším důležitým aspektem je, že to není pouze vyhrazeno pro čas procesoru. Platí také pro všechny prostředky, jako je paměť, síť a místo na disku.

U úloh WebAssembly je obvykle málo starostí o množství práce, kterou klient provádí, protože klient je obvykle omezen prostředky dostupnými v klientovi. Existují však některé scénáře, kdy může být ovlivněn klient, pokud například aplikace zobrazuje data od jiných uživatelů a jeden uživatel může přidat data do systému, který vynutí klienty, kteří zobrazují data, aby provedli určitou práci, která není úměrná množství dat přidaných uživatelem.

Doporučený (nekompatiční) kontrolní seznam

• Ujistěte se, že je uživatel ověřený a autorizovaný pro přístup k aplikaci a prostředkům, které zveřejňuje.
• Před použitím ověřte a sanitujte všechny vstupy přicházející z klienta.
• Správně spravujte uživatelské relace, abyste měli jistotu, že se stav nesdílí omylem mezi uživateli.
• Správně zpracovávat a protokolovat chyby, abyste se vyhnuli zveřejnění citlivých informací.
• Protokolování důležitých událostí v aplikaci za účelem identifikace potenciálních problémů a akcí auditu provedených uživateli
• Ochrana citlivých informací pomocí rozhraní API ASP.NET Core Data Protection nebo jedné z dostupných komponent (Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage, PersistentComponentState).
• Ujistěte se, že aplikace rozumí prostředkům, které můžou daný požadavek využívat, a má omezení, aby se zabránilo útokům na dostupnost služby.