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

Tento článek vysvětluje, jak zmírnit bezpečnostní hrozby na straně Blazorinteraktivního serveru .

Aplikace přijímají stavový model zpracování dat, kde server a klient udržují dlouhodobý vztah. Trvalý stav udržuje okruh, který může zahrnovat připojení, která jsou také potenciálně dlouhodobá.

Když uživatel navštíví lokalitu, server vytvoří okruh v paměti serveru. Okruh označuje prohlížeč, jaký obsah se má vykreslit a reagovat na události, například když uživatel vybere tlačítko v uživatelském rozhraní. K provedení těchto akcí okruh vyvolá funkce JavaScriptu v prohlížeči uživatele a metodách .NET na serveru. Tato obousměrná interakce založená na JavaScriptu se označuje jako interoperabilita JavaScriptu (JSinterop).

Vzhledem k tomu, že JS spolupráce probíhá přes internet a klient používá vzdálený prohlížeč, aplikace sdílejí většinu problémů se zabezpečením webových aplikací. Toto téma popisuje běžné hrozby pro aplikace na straně Blazor serveru a poskytuje pokyny pro zmírnění hrozeb zaměřené na internetové aplikace.

V omezených prostředích, jako jsou podnikové sítě nebo intranety, některé pokyny pro zmírnění rizik buď:

• Nevztahuje se v omezeném prostředí.
• Nestojí za to implementovat, protože bezpečnostní riziko je nízké v omezeném prostředí.

Interaktivní součásti serveru s povolenou kompresí WebSocket

Komprese může aplikaci vystavit bočním útokům proti šifrování protokolu TLS připojení, jako jsou útoky CRIME a BREACH. Tyto typy útoků vyžadují, aby kybernetický útočník:

• Vynutit, aby prohlížeč vydal požadavky s datovou částí, kterou řídí kyberútočník, na ohrožený web prostřednictvím publikování formuláře napříč stránkami nebo zajištění vložení webu do prvku iframe jiného webu.
• Sledujte délku komprimované a šifrované odpovědi v síti.

Aby byla aplikace zranitelná, musí v odpovědi odrazit zátěž od kyberútočníka, například tím, že do odpovědi zapíše cestu nebo řetězec dotazu. S využitím délky odpovědi může kyberútočník libovolné informace o odpovědi uhodnout a obejít tak šifrování připojení.

Obecně řečeno, Blazor aplikace mohou povolit kompresi přes připojení WebSocket s příslušnými bezpečnostními opatřeními:

• Aplikace může být zranitelná, když přebírá obsah z požadavku (například cestu nebo řetězec dotazu), který může ovlivnit cyberattacker a reprodukuje ho do kódu HTML stránky nebo ho jinak vytvoří jako součást odpovědi.

• Blazor automaticky použije následující bezpečnostní opatření:

  • Při nastavení komprese Blazor automaticky blokuje, aby byla aplikace vložena do prvku iframe, což brání tomu, aby se počáteční (nekomprimovaná) odpověď ze serveru vykreslila, a znemožňuje zahájení připojení WebSocket.

  • Omezení vložení aplikace do prvku iframe může být uvolněné. Uvolnění omezení ale zpřístupňuje aplikaci k útoku, pokud se dokument pro vložení zneškodní prostřednictvím chyby zabezpečení skriptování mezi weby, protože to umožňuje kyberútoku způsob, jak útok provést.

• Za normálních okolností, aby se tento typ útoku uskutečnil, musí aplikace opakovaně reprodukovat obsah odpovědí, aby cyberattacker mohl odpověď odhadnout. Vzhledem k tomu, jak Blazor se vykresluje (vykresluje jednou a pak vytváří rozdíly obsahu pouze pro prvky, které se změnily), je pro kyberútočníka obtížné to provést. Přesto to pro kyberútočníka není nemožné, takže je třeba dbát opatrnosti, aby nedošlo k vykreslení citlivých informací spolu s externími informacemi, které může kyberútočník manipulovat. Tady je několik příkladů:

  • Vykreslujte identifikovatelné osobní údaje (PII) na stránce současně s vykreslováním databázových dat, která přidal jiný uživatel.

  • Vykreslení informací o PII na stránce současně s daty přicházejícími od jiného uživatele prostřednictvím JS zprostředkovatele komunikace nebo místní jednoúčelové služby na serveru

Obecně doporučujeme vyhnout se vykreslování komponent, které obsahují citlivé informace spolu s komponentami, které mohou vykreslovat data z nedůvěryhodných zdrojů jako součást stejné dávky vykreslování. Mezi nedůvěryhodné zdroje patří parametry směrování, řetězce dotazů, data z JS interoperability a jakýkoli jiný zdroj dat, který může uživatel třetí strany řídit (databáze, externí služby).

Sdílený stav

Serverové Blazor aplikace žijí v paměti serveru a více relací aplikací je hostováno ve stejném procesu. Pro každou relaci Blazor aplikace spustí proces s vlastním oborem injekčního kontejneru závislostí, takže služby s vymezeným oborem jsou jedinečné pro relaci Blazor.

Upozornění

Nedoporučujeme, aby aplikace na stejném serveru sdílely stav pomocí singletonových služeb, pokud není věnována mimořádná péče, protože to může představovat bezpečnostní rizika, například únik stavu uživatele mezi různými okruhy.

Stavové singleton služby můžete v Blazor aplikacích používat, pokud jsou speciálně navrženy. Například použití jednoúčelové mezipaměti paměti je přijatelné, protože mezipaměť paměti vyžaduje klíč pro přístup k dané položce. Za předpokladu, že uživatelé nemají kontrolu nad klíči mezipaměti, které se používají s mezipamětí, nedojde k úniku stavu uloženého v mezipaměti mezi okruhy.

Obecné pokyny ke správě stavu najdete v tématu ASP.NET Blazor Základní správa stavu.

IHttpContextAccessor/HttpContext

Další informace najdete v tématu IHttpContextAccessor/HttpContext v aplikacích ASP.NET Core Blazor.

Vyčerpání prostředků

Vyčerpání prostředků může nastat, když klient komunikuje se serverem a způsobí, že server spotřebuje nadměrné prostředky. Nadměrná spotřeba prostředků má vliv především na:

• CPU
• Paměť
• Klientská připojení

Útoky DoS (Denial of Service) se obvykle snaží vyčerpat prostředky aplikace nebo serveru. Vyčerpání prostředků ale nemusí nutně být výsledkem útoku na systém. Například konečné prostředky je možné vyčerpat z důvodu vysoké poptávky uživatelů. DoS je podrobněji popsáno v části DoS.

U prostředků mimo architekturu Blazor , jako jsou databáze a popisovače souborů (používané ke čtení a zápisu souborů), mohou také docházet k vyčerpání prostředků. Další informace najdete v tématu Nejlepší postupy pro ASP.NET Core.

Procesor

K vyčerpání procesoru může dojít, když jeden nebo více klientů vynutí, aby server prováděl náročné úlohy procesoru.

Představte si například aplikaci, která vypočítá fibonnacciho číslo. Fibonnacciho číslo se vytváří z fibonnacciho sekvence, kde každé číslo v sekvenci je součet dvou předchozích čísel. Množství práce potřebné k dosažení odpovědi závisí na délce sekvence a velikosti počáteční hodnoty. Pokud aplikace neumisťuje omezení na požadavek klienta, můžou výpočty náročné na procesor dominovat času procesoru a snížit výkon jiných úloh. Nadměrná spotřeba prostředků je problém se zabezpečením, který má vliv na dostupnost.

Vyčerpání procesoru je pro všechny veřejné aplikace důležité. V běžných webových aplikacích vyprší časový limit požadavků a připojení jako bezpečnostní opatření, ale Blazor aplikace neposkytují stejná ochranná opatření. Blazor aplikace musí obsahovat odpovídající kontroly a limity, než budou provádět potenciálně náročné práce na procesoru.

Memory (Paměť)

K vyčerpání paměti může dojít, když jeden nebo více klientů přinutí server, aby spotřeboval velké množství paměti.

Představte si například aplikaci s komponentou, která přijímá a zobrazuje seznam položek. Blazor Pokud aplikace neumisťuje omezení počtu povolených položek nebo počtu položek vykreslovaných zpět klientovi, může zpracování a vykreslování náročné na paměť dominovat paměti serveru v bodě, kdy dochází k omezení výkonu serveru. Server se může zhroutit nebo zpomalit natolik, že se zdá, jako by se zhroutil.

Při údržbě a zobrazení seznamu položek, které se týkají potenciálního scénáře vyčerpání paměti na serveru, zvažte následující scénář:

• Položky ve List<T> vlastnosti nebo poli používají paměť serveru. Pokud aplikace umožňuje, aby seznam položek zvětšoval nevázaný, hrozí, že na serveru dochází nedostatek paměti. Nedostatek paměti způsobí ukončení aktuální relace (chybové ukončení) a všechny souběžné relace v této instanci serveru obdrží výjimku z nedostatku paměti. Aby k tomuto scénáři nedocházelo, musí aplikace používat datovou strukturu, která omezuje počet položek pro souběžné uživatele.
• Pokud se pro vykreslování nepoužívá schéma stránkování, server použije další paměť pro objekty, které nejsou viditelné v uživatelském rozhraní. Bez omezení počtu položek můžou požadavky na paměť vyčerpat dostupnou paměť serveru. Pokud chcete tomuto scénáři zabránit, použijte jeden z následujících přístupů:
  • Při vykreslování používejte stránkované seznamy.
  • Zobrazí pouze prvních 100 až 1 000 položek a vyžaduje, aby uživatel zadal kritéria hledání, aby vyhledal položky mimo zobrazené položky.
  • V případě pokročilejšího scénáře vykreslování implementujte seznamy nebo mřížky, které podporují virtualizaci. Pomocí virtualizace vykreslí seznamy jenom podmnožinu položek, které jsou aktuálně viditelné pro uživatele. Když uživatel pracuje s posuvníkem v uživatelském rozhraní, komponenta vykreslí pouze ty položky potřebné k zobrazení. Položky, které nejsou aktuálně potřeba pro zobrazení, se dají uchovávat v sekundárním úložišti, což je ideální přístup. Nezobrazené položky lze také uchovávat v paměti, což není ideální.

Poznámka:

Blazor má integrovanou podporu virtualizace. Další informace najdete v tématu virtualizace komponent ASP.NET CoreRazor.

Blazoraplikace nabízejí podobný programovací model jiným architekturám uživatelského rozhraní pro stavové aplikace, jako je WPF, model Windows Forms nebo Blazor WebAssembly. Hlavní rozdíl spočívá v tom, že v několika architekturách uživatelského rozhraní paměť spotřebovaná aplikací patří klientovi a ovlivňuje pouze jednotlivého klienta. Například Blazor WebAssembly aplikace běží zcela na klientovi a používá pouze prostředky paměti klienta. V případě aplikace na straně Blazor serveru paměť spotřebovaná aplikací patří k serveru a sdílí se mezi klienty v instanci serveru.

Požadavky na paměť na straně serveru jsou důležité pro všechny aplikace na straně Blazor serveru. Většina webových aplikací je ale bezstavová a paměť používaná při zpracování požadavku se uvolní při vrácení odpovědi. Obecně doporučujeme neumožnit klientům přidělovat neomezenou velikost paměti, stejně jako v jakékoli jiné aplikaci na straně serveru, která udržuje klientská připojení. Paměť spotřebovaná aplikací na straně Blazor serveru trvá delší dobu než jeden požadavek.

Poznámka:

Během vývoje lze použít profilovací nástroj nebo zachytit trasování k posouzení požadavků klientů na paměť. Profiler nebo trasování nezachytí paměť přidělenou konkrétnímu klientovi. Pokud chcete zachytit využití paměti konkrétního klienta během vývoje, zachyťte výpis paměti a prozkoumejte požadavky na paměť všech objektů kořenových v okruhu uživatele.

Připojení klientů

K vyčerpání připojení může dojít, když jeden nebo více klientů otevře příliš mnoho souběžných připojení k serveru, což ostatním klientům brání v navazování nových připojení.

Blazor klienti navazují jedno připojení pro každou relaci a připojení zůstává aktivní, dokud je prohlížeč otevřený. Vzhledem k trvalé povaze připojení a stavové povaze aplikací na straně Blazor serveru představuje vyčerpání připojení větší riziko pro dostupnost aplikace.

Počet připojení pro uživatele aplikace není nijak omezený. Pokud aplikace vyžaduje limit připojení, použijte jeden nebo několik následujících přístupů:

• Vyžadovat ověřování, které přirozeně omezuje schopnost neautorizovaných uživatelů připojit se k aplikaci. Aby byl tento scénář efektivní, musí být uživatelům znemožněno zřizovat nové uživatele na vyžádání.
• Omezte počet připojení na uživatele. Omezení připojení je možné provést pomocí následujících přístupů. Dbejte na to, abyste legitimním uživatelům umožnili přístup k aplikaci (například když je navázán limit připojení na základě IP adresy klienta).
  • Úroveň aplikace
    • Rozšiřitelnost směrování koncových bodů
    • Vyžadujte ověření pro připojení k aplikaci a sledujte aktivní relace na uživatele.
    • Odmítněte nové relace při dosažení limitu.
    • Proxy připojení WebSocket k aplikaci prostřednictvím využití proxy serveru, jako je služba Azure, který multiplexuje připojení z klientů k aplikaci. To poskytuje aplikaci větší kapacitu připojení, než může navázat jeden klient, a brání klientovi, aby nevyčerpal připojení k serveru.
  • Úroveň serveru: Před aplikací použijte proxy server nebo bránu.
    • azure Application Gateway je nástroj pro vyrovnávání zatížení webového provozu (OSI vrstvy 7), který umožňuje spravovat provoz do webových aplikací. Další informace najdete v tématu Přehled podpory protokolu WebSocket ve službě Application Gateway.
    • azure Front Door je služba vyrovnávání zatížení pro distribuci úloh napříč několika výpočetními prostředky.

Útoky na dostupnost služby (DoS)

Denial-of-Service (DoS) útoky zahrnují, že klientský software způsobuje vyčerpání jednoho nebo více prostředků serveru, čímž se aplikace stává nedostupnou. Blazor aplikace zahrnují výchozí limity a spoléhají na další limity ASP.NET Core a SignalR, které jsou nastavené CircuitOptions pro ochranu před útoky DoS:

• CircuitOptions.DisconnectedCircuitMaxRetained
• CircuitOptions.DisconnectedCircuitRetentionPeriod
• CircuitOptions.JSInteropDefaultCallTimeout
• CircuitOptions.MaxBufferedUnacknowledgedRenderBatches
• HubConnectionContextOptions.MaximumReceiveMessageSize

Další informace a příklady kódování konfigurace najdete v následujících článcích:

• Pokyny pro ASP.NET Core BlazorSignalR
• Konfigurace SignalR pro ASP.NET Core

Interakce s prohlížečem (klientem)

Klient komunikuje se serverem prostřednictvím JS odesílání událostí zprostředkovatele a dokončování vykreslování. JS komunikace mezi JavaScriptem a .NET probíhá oběma způsoby:

• Události prohlížeče se odesílají z klienta na server asynchronním způsobem.
• Server podle potřeby asynchronně rerenderuje uživatelské rozhraní.

Funkce JavaScriptu vyvolané z .NET

Volání z metod .NET do JavaScriptu:

• Všechny vyvolání mají konfigurovatelný časový limit, po jehož překročení selžou a vrátí volajícímu OperationCanceledException.
  • Existuje výchozí časový limit pro volání (CircuitOptions.JSInteropDefaultCallTimeout) ve výši jedné minuty. Pokud chcete tento limit nakonfigurovat, přečtěte si téma Volání javascriptových funkcí z metod .NET v ASP.NET Core Blazor.
  • Token pro zrušení může být poskytnut pro řízení zrušení u každého jednotlivého volání. Kde je to možné, spoléhejte na výchozí časový limit volání a pokud je k dispozici token pro zrušení, časově omezte jakékoliv volání na klienta.
• Výsledek volání JavaScriptu nemůže být důvěryhodný. Klient Blazor aplikace spuštěný v prohlížeči vyhledá funkci JavaScriptu, která se má vyvolat. Funkce se vyvolá a výsledek nebo chyba se vytvoří. Škodlivý klient se může pokusit:
  • Problém v aplikaci můžete způsobit vrácením chyby z funkce JavaScriptu.
  • Vyvolání neúmyslného chování na serveru vrácením neočekávaného výsledku z funkce JavaScriptu.

Pokud chcete chránit před předchozími scénáři, proveďte následující opatření:

• Zabalte JS mezioperační volání do příkazů try-catch, aby se zohlednily chyby, ke kterým může dojít během vyvolání. Další informace naleznete v Řešení chyb v aplikacích Blazor ASP.NET Core.
• Před provedením jakékoli akce ověřte data vrácená z JS vyvolání zprostředkovatele komunikace, včetně chybových zpráv.

Metody .NET vyvolané z prohlížeče

Nedůvěřujte voláním z JavaScriptu do metod .NET. Pokud je metoda .NET vystavená JavaScriptu, zvažte způsob vyvolání metody .NET:

• Zacházejte s libovolnou metodou .NET vystavenou JavaScriptu stejně jako s veřejným koncovým bodem aplikace.
  • Ověřte vstup.
    • Ujistěte se, že hodnoty jsou v očekávaných rozmezích.
    • Ujistěte se, že má uživatel oprávnění k provedení požadované akce.
  • Nevyčleňujte nadměrné množství prostředků při vyvolání metody .NET. Můžete například provádět kontroly a umisťovat omezení využití procesoru a paměti.
  • Vezměte v úvahu, že statické metody a metody instancí mohou být zpřístupněny klientům JavaScriptu. Vyhněte se sdílení stavu napříč relacemi, pokud návrh nevyžaduje sdílení stavu s odpovídajícími omezeními.
    • Například metody vystavené prostřednictvím DotNetObjectReference objektů, které byly původně vytvořeny prostřednictvím injektáže závislostí (DI), by měly být objekty registrovány jako objekty s vymezeným oborem. To platí pro jakoukoli službu DI, kterou aplikace používá.
    • U statických metod se vyhněte vytváření stavu, který nelze omezit pouze na klienta, pokud aplikace podle návrhu sdílí stav mezi všemi uživateli v instanci serveru.
  • Vyhněte se předávání dat zadaných uživatelem do parametrů volání JavaScriptu. Pokud je předání dat v parametrech naprosto povinné, ujistěte se, že kód JavaScriptu zpracovává předávání dat bez zavedení chyb zabezpečení skriptování mezi weby (XSS ). Například nezapisujte uživatelem zadaná data do DOM nastavením innerHTML vlastnosti elementu. Zvažte použití zásad zabezpečení obsahu (CSP) k zakázání eval a dalším nebezpečným primitivám JavaScriptu. Další informace najdete v tématu Vynucení zásad zabezpečení obsahu pro ASP.NET Core Blazor a pokyny k referenci CSP na MDN.
• Vyhněte se implementaci vlastního odesílání volání rozhraní .NET nad implementací odesílání frameworku. Zveřejnění metod .NET v prohlížeči je pokročilý scénář, který se nedoporučuje pro obecný Blazor vývoj.

Události

Události poskytují vstupní bod pro aplikaci. Stejná pravidla pro ochranu koncových bodů ve webových aplikacích platí pro zpracování událostí v Blazor aplikacích. Škodlivý klient může odeslat jakákoli data, která chce odeslat jako datovou část události.

Příklad:

• Událost změny pro <select> by mohla odeslat hodnotu, která není mezi možnostmi poskytovanými aplikací klientovi.
• Jakýkoli <input> může odeslat data na server, čímž obejde ověření na straně klienta.

Aplikace musí ověřit data pro libovolnou událost, kterou aplikace zpracovává. Komponenty Blazor formulářů architektury provádějí základní ověření. Pokud aplikace používá vlastní komponenty formulářů, musí se vlastní kód zapsat, aby se ověřila data událostí podle potřeby.

Události jsou asynchronní, takže více událostí je možné odeslat na server předtím, než aplikace bude mít čas reagovat vytvořením nového vykreslení. To má určité bezpečnostní důsledky, které je potřeba vzít v úvahu. Omezení klientských akcí v aplikaci musí být provedeno uvnitř obslužných rutin událostí a nezávisí na aktuálním stavu vykresleného zobrazení.

Zvažte komponentu čítače, která by uživateli měla umožnit zvýšit čítač maximálně třikrát. Tlačítko pro zvýšení čítače závisí na hodnotě count:

<p>Count: @count</p>

@if (count < 3)
{
    <button @onclick="IncrementCount" value="Increment count" />
}

@code 
{
    private int count = 0;

    private void IncrementCount()
    {
        count++;
    }
}

Klient může odeslat jednu nebo více událostí přírůstku předtím, než architektura vytvoří nové vykreslení této komponenty. Výsledkem je, že count lze uživatelem zvýšit více než třikrát, protože tlačítko není uživatelským rozhraním odstraněno dostatečně rychle. Správný způsob, jak dosáhnout limitu tří count přírůstků, je znázorněn v následujícím příkladu:

<p>Count: @count</p>

@if (count < 3)
{
    <button @onclick="IncrementCount" value="Increment count" />
}

@code 
{
    private int count = 0;

    private void IncrementCount()
    {
        if (count < 3)
        {
            count++;
        }
    }
}

if (count < 3) { ... } Přidáním kontroly uvnitř obslužné rutiny se rozhodnutí o přírůstku count zakládá na aktuálním stavu aplikace. Rozhodnutí není založené na stavu uživatelského rozhraní, jako tomu bylo v předchozím příkladu, což může být dočasně zastaralé.

Ochrana proti více voláním

Pokud zpětné volání události vyvolá dlouhotrvající operaci asynchronně, například načtení dat z externí služby nebo databáze, zvažte použití ochrany. Ochrana může zabránit uživateli v zařazení více operací do fronty během probíhající operace, při které je poskytována vizuální zpětná vazba. Následující kód komponenty nastaví isLoading na true, zatímco DataService.GetDataAsync získává data ze serveru. I když isLoading je true, tlačítko je v uživatelském rozhraní deaktivované:

<button disabled="@isLoading" @onclick="UpdateData">Update</button>

@code {
    private bool isLoading;
    private Data[] data = Array.Empty<Data>();

    private async Task UpdateData()
    {
        if (!isLoading)
        {
            isLoading = true;
            data = await DataService.GetDataAsync(DateTime.Now);
            isLoading = false;
        }
    }
}

Patrón ochrany předvedený v předchozím příkladu funguje, pokud je operace na pozadí prováděna asynchronně se vzorem async-await.

Zrušte předčasné zrušení a vyhněte se použití po vyřazení.

Kromě použití ochranného opatření, jak je popsáno v části Ochrana proti více dispečerům , zvažte možnost CancellationToken zrušení dlouhotrvajících operací při vyřazení komponenty. Tento přístup má přidanou výhodu, že se vyhne použití po vyřazení u komponent:

@implements IDisposable

...

@code {
    private readonly CancellationTokenSource TokenSource = 
        new CancellationTokenSource();

    private async Task UpdateData()
    {
        ...

        data = await DataService.GetDataAsync(DateTime.Now, TokenSource.Token);

        if (TokenSource.Token.IsCancellationRequested)
        {
           return;
        }

        ...
    }

    public void Dispose()
    {
        TokenSource.Cancel();
    }
}

Vyhněte se událostem, které vytvářejí velké objemy dat

Některé události DOM, například oninput nebo onscroll, mohou produkovat velké množství dat. Nepoužívejte tyto události na serveru na straně Blazor serveru.

Další pokyny k zabezpečení

Pokyny pro zabezpečení aplikací ASP.NET Core platí pro aplikace na straně Blazor serveru a jsou popsané v následujících částech tohoto článku:

• Protokolování a citlivá data
• Ochrana přenášených informací pomocí PROTOKOLU HTTPS
• Skriptování mezi weby (XSS)
• Ochrana před cross-origin útoky
• Clickjacking
• Otevřené přesměrování

Protokolování a citlivá data

JS Interakce mezi klientem a serverem se zaznamenávají v protokolech serveru s instancemi ILogger . Blazor zabraňuje protokolování citlivých informací, jako jsou skutečné události nebo JS vstupy vzájemné spolupráce a výstupy.

Pokud na serveru dojde k chybě, architektura upozorní klienta a ukonče relaci. Klient obdrží obecnou chybovou zprávu, kterou lze zobrazit v vývojářských nástrojích prohlížeče.

Chyba na straně klienta neobsahuje zásobník volání a neposkytuje podrobnosti o příčině chyby, ale protokoly serveru tyto informace obsahují. Pro účely vývoje lze citlivé informace o chybách zpřístupnit klientovi povolením podrobných chyb.

Varování

Zveřejnění informací o chybách klientům na internetu je bezpečnostní riziko, kterému byste se měli vždy vyhnout.

Ochrana přenášených informací pomocí PROTOKOLU HTTPS

Blazor používá SignalR ke komunikaci mezi klientem a serverem. Blazor obvykle používá přenos, který SignalR vyjedná, což je obvykle WebSockets.

Blazor nezajistí integritu a důvěrnost dat odesílaných mezi serverem a klientem. Vždy používejte PROTOKOL HTTPS.

Skriptování mezi weby (XSS)

Skriptování mezi weby (XSS) umožňuje neoprávněné straně spouštět libovolnou logiku v kontextu prohlížeče. Ohrožená aplikace může v klientovi potenciálně spustit libovolný kód. Toto ohrožení zabezpečení by mohlo být použito k provedení řady škodlivých akcí na serveru:

• Odeslat falešné nebo neplatné události na server.
• Selhání odeslání/neplatné dokončení vykreslení.
• Vyhněte se odesílání dokončení vykreslování.
• Odesílání interop volání z JavaScriptu do .NET.
• Upravte odpověď interoperabilních volání z .NET do JavaScriptu.
• Vyhněte se předávání výsledků .NET interoperace do JS.

Architektura Blazor provádí kroky k ochraně před některými z předchozích hrozeb:

• Pokud klient nepotvrzuje dávky vykreslování, přestane vytvářet nové aktualizace uživatelského rozhraní. Nakonfigurováno pomocí CircuitOptions.MaxBufferedUnacknowledgedRenderBatches.
• Nastaví časový limit pro volání z .NET do JavaScriptu na jednu minutu při neobdržení odpovědi od klienta. Nakonfigurováno pomocí CircuitOptions.JSInteropDefaultCallTimeout.
• Provede základní ověření všech vstupů přicházejících z prohlížeče během JS interoperability.
  • Odkazy na .NET jsou platné a jsou typu očekávaného metodou .NET.
  • Data nejsou poškozená.
  • Správný počet argumentů pro metodu jsou přítomné v datové části.
  • Argumenty nebo výsledek lze před vyvoláním metody deserializovat správně.
• Provede základní ověření ve všech vstupech přicházejících z prohlížeče z odeslaných událostí:
  • Událost má platný typ.
  • Data události mohou být deserializována.
  • K události je přidružená obslužná rutina události.

Kromě ochranných opatření, která architektura implementuje, musí být aplikace kódována vývojářem, aby se chránila před hrozbami a prováděla příslušné akce:

• Při zpracování událostí vždy ověřte data.
• Při přijímání neplatných dat proveďte odpovídající akci:
  • Ignorujte data a vraťte se. To aplikaci umožní pokračovat ve zpracování požadavků.
  • Pokud aplikace zjistí, že vstup je nelegitimní a nelze ho vytvořit legitimním klientem, vyvolá se výjimka. Vyvolání výjimky přeruší okruh a ukončí relaci.
• Nedůvěřujte chybové zprávě poskytované dokončeními dávky vykreslování, které jsou zahrnuty v protokolech. Chyba je poskytována klientem a nemůže být obecně důvěryhodná, protože klient může být ohrožen.
• Nedůvěřujte vstupu pro JS interoperabilní volání mezi metodami JavaScriptu a .NET v obou směrech.
• Aplikace zodpovídá za ověření, že obsah argumentů a výsledků je platný, i když jsou argumenty nebo výsledky správně deserializovány.

Aby zranitelnost XSS existovala, musí aplikace začlenit uživatelský vstup do vykreslené stránky. Blazor spustí krok kompilace, ve kterém se kód v .razor souboru transformuje na procedurální logiku jazyka C#. Logika jazyka C# za běhu vytvoří vykreslovací strom popisující prvky, text a podřízené komponenty. To se použije na DOM prohlížeče prostřednictvím posloupnosti javascriptových instrukcí (nebo se serializuje do HTML v případě předrenderingu):

• Uživatelský vstup vykreslený prostřednictvím normální Razor syntaxe (například @someStringValue) nezpřístupňuje ohrožení zabezpečení XSS, protože Razor syntaxe se přidá do DOM prostřednictvím příkazů, které můžou psát jenom text. I když hodnota obsahuje kód HTML, zobrazí se tato hodnota jako statický text. Při předkreslování je výstup kódovaný ve formátu HTML, který také zobrazuje obsah jako statický text.
• Autoři komponent mohou vytvářet komponenty v jazyce C# bez použití Razor. Autor komponenty zodpovídá za použití správných rozhraní API při generování výstupu. Například použijte builder.AddContent(0, someUserSuppliedString) a nebuilder.AddMarkupContent(0, someUserSuppliedString), protože druhý by mohl vytvořit ohrožení zabezpečení XSS.

Zvažte další zmírnění ohrožení zabezpečení XSS. Například implementujte omezující zásady zabezpečení obsahu (CSP). Další informace najdete v tématu Vynucení zásad zabezpečení obsahu pro ASP.NET Core Blazor a pokyny k referencím CSP podle MDN.

Další informace najdete v tématu Zabránění skriptování mezi weby (XSS) v ASP.NET Core.

Ochrana mezi zdroji

Útoky mezi zdroji zahrnují klienta z jiného původu, který provádí akci se serverem. Škodlivá akce je obvykle požadavek GET nebo formulář POST (cross-site Request Forgery, CSRF), ale otevření škodlivého webSocketu je také možné. Blazor aplikace poskytují stejné záruky jako každá jiná SignalR aplikace používající protokol hubu:

• K aplikacím lze přistupovat napříč původy, pokud nejsou přijata další opatření k tomu, aby se v tom zabránilo. Pokud chcete zakázat přístup mezi doménami, deaktivujte CORS v koncovém bodu přidáním middleware CORS do kanálu a přidáním DisableCorsAttribute do Blazor metadat koncového bodu nebo omezte sadu povolených původů konfigurací SignalR pro sdílení prostředků mezi doménami. Pokyny k omezením původu protokolu WebSocket najdete v tématu Podpora protokolu WebSocket v ASP.NET Core.
• Pokud je CORS povolená, může být potřeba provést další kroky k ochraně aplikace v závislosti na konfiguraci CORS. Pokud je CORS globálně povolená, můžete CORS pro BlazorSignalR centrum zakázat přidáním DisableCorsAttribute metadat do metadat koncového bodu po volání MapBlazorHub do tvůrce tras koncových bodů.

Další informace najdete v tématu Prevence útoků založených na padělání žádosti posílané mezi weby (XSRF/CSRF) v ASP.NET Core.

Klikni a zvednutí

Přesměrování kliknutí zahrnuje zobrazení stránky jako <iframe> na stránce z jiného zdroje, aby oklamalo uživatele k provedení akcí na cílové stránce útoku.

K ochraně aplikace před vykreslováním uvnitř objektu <iframe>použijte zásady zabezpečení obsahu (CSP) a hlavičku X-Frame-Options . Informace o syntaxi CSP najdete referenční pokyny k CSP MDN.

Další informace naleznete v následujících zdrojích:

• Vynucení zásad zabezpečení obsahu pro ASP.NET Core Blazor
• Webová dokumentace MDN: X-Frame-Options

Otevřené přesměrování

Když se spustí relace aplikace, server provede základní ověření adres URL odeslaných v rámci spuštění relace. Architektura zkontroluje, že základní adresa URL je nadřazenou aktuální adresou URL před vytvořením okruhu. Rámec neprovádí žádné další kontroly.

Když uživatel vybere odkaz na klientovi, odešle se na server adresa URL odkazu, která určuje, jaká akce se má provést. Aplikace může například provést navigaci na straně klienta nebo označit prohlížeči, aby přešla do nového umístění.

Komponenty mohou také prostřednictvím kódu programu aktivovat žádosti o navigaci prostřednictvím nástroje NavigationManager. V takových scénářích může aplikace provést navigaci na straně klienta nebo indikovat prohlížeči, aby přešla do nového umístění.

Součásti musí:

• Nepoužívejte uživatelský vstup jako součást argumentů volání navigace.
• Ověřte argumenty a ujistěte se, že je cíl povolený aplikací.

Jinak může uživatel se zlými úmysly vynutit, aby prohlížeč přešel na web řízený kybernetickým útokem. V tomto scénáři kyberútočník ošálí aplikaci, aby v rámci vyvolání metody NavigationManager.NavigateTo používala nějaký uživatelský vstup.

Toto doporučení platí také při vykreslování odkazů v rámci aplikace:

• Pokud je to možné, použijte relativní odkazy.
• Před zahrnutím na stránku ověřte, že jsou absolutní odkazy platné.

Další informace najdete v tématu Prevence útoků s otevřeným přesměrováním v ASP.NET Core.

Kontrolní seznam zabezpečení

Následující seznam aspektů zabezpečení není vyčerpávající:

• Ověřte argumenty z událostí.
• Ověřte vstupy a výsledky z JS volání interop.
• Vyhněte se použití (nebo ověření předem) uživatelského vstupu pro .NET pro JS volání zprostředkovatele komunikace.
• Zabrání klientovi v přidělování nevázaného množství paměti.
  • Data uvnitř komponenty.
  • DotNetObjectReference objekty vrácené klientovi.
• Chraňte před více dispečery.
• Zrušte dlouhotrvající operace, když je komponenta odstraněna.
• Vyhněte se událostem, které vytvářejí velké objemy dat.
• Nepoužívejte uživatelský vstup jako součást volání NavigationManager.NavigateTo a ověřte vstup uživatele pro adresy URL proti sadě povolených původů, pokud je to nevyhnutelné.
• Nevytvávejte rozhodnutí o autorizaci na základě stavu uživatelského rozhraní, ale jenom ze stavu komponent.
• Zvažte použití zásad zabezpečení obsahu (CSP) k ochraně před útoky XSS. Pro více informací se podívejte na Vynutit zásady zabezpečení obsahu pro ASP.NET Core Blazor a na referenční pokyny k CSP na MDN.
• Zvažte použití CSP a X-Frame-Options k ochraně před kliknutím na podvodné prvky.
• Ujistěte se, že je nastavení CORS vhodné při povolování CORS, nebo explicitně zakažte CORS pro Blazor aplikace.
• Otestujte, abyste zajistili, že limity na straně serveru pro Blazor aplikaci poskytují přijatelné uživatelské prostředí bez nepřijatelné úrovně rizika.