Pokyny pro zmírnění hrozeb pro ASP.NET Core Blazor Server

  • Článek
  • 29 min ke čtení

Blazor Server aplikace přijímají stavový model zpracování dat, kde server a klient udržuje dlouhotrvající relaci. Trvalý stav je udržován okruhem, který může zahrnovat připojení, která jsou také potenciálně dlouhodobá.

Když uživatel navštíví Blazor Server web, Server vytvoří okruh v paměti serveru. Okruh indikuje prohlížeči, který obsah se má vykreslit a reagovat na události, například když uživatel vybere tlačítko v uživatelském rozhraní. Chcete-li provést tyto akce, okruh vyvolá funkce JavaScriptu v prohlížeči uživatele a metodách .NET na serveru. Tato obousměrná interakce založená na jazyce JavaScript je označována jako zprostředkovatel komunikace JavaScript (zprostředkovatel komunikace js).

Vzhledem k tomu, že interoperabilita JS probíhá přes Internet a klient používá vzdálený prohlížeč, Blazor Server aplikace sdílejí většinu otázek zabezpečení webových aplikací. Toto téma popisuje běžné hrozby pro Blazor Server aplikace a poskytuje pokyny pro zmírnění hrozeb zaměřené na internetové aplikace.

V omezených prostředích, jako jsou v podnikových sítích nebo intranetech, se jedná o některé pokyny k omezení rizik:

  • Neplatí v omezeném prostředí.
  • Nestojí za implementaci, protože bezpečnostní riziko je nízké v omezeném prostředí.

Blazor a sdílený stav

Blazor serverové aplikace živě v paměti serveru. To znamená, že v rámci stejného procesu je hostovaných více aplikací. Pro každou relaci aplikace spustí Blazor okruh s vlastním oborem kontejneru DI. To znamená, že vymezené služby jsou pro každou relaci Blazor jedinečné.

Upozornění

Aplikace ve stejném stavu sdílené složky serveru nedoporučujeme používat s využitím jednosměnné služby, pokud není přijata extrémní péče, protože to může představovat ohrožení zabezpečení, jako je například únik stavu uživatele napříč okruhy.

V aplikacích můžete používat stavové jednosměnné Blazor služby, pokud jsou pro něj speciálně navržené. Mezipaměť paměti můžete použít například jako jednu položku, protože vyžaduje klíč pro přístup k dané položce za předpokladu, že uživatelé nemají kontrolu nad tím, jaké klíče mezipaměti se používají.

Z bezpečnostních důvodů se navíc nesmí používat IHttpContextAccessor v Blazor aplikacích. Blazoraplikace běží mimo kontext kanálu ASP.NET Core. Není zaručeno, že bude k dispozici v rámci , ani není zaručeno, že bude uchovat kontext, HttpContext IHttpContextAccessor který aplikaci Blazor zahájil.

Doporučený způsob, jak předat stav požadavku do aplikace, je prostřednictvím parametrů kořenové komponentě při Blazor počátečním vykreslování aplikace:

  • Definujte třídu se všemi daty, která chcete do Blazor aplikace předat.
  • Naplňte tato data ze Razor stránky pomocí možnosti dostupné v tomto HttpContext okamžiku.
  • Předejte data do Blazor aplikace jako parametr do kořenové komponenty (aplikace).
  • V kořenové komponentě definujte parametr, který bude obsahovat data předaná do aplikace.
  • Použití dat specifických pro uživatele v rámci aplikace Nebo můžete tato data zkopírovat do vymezené služby v rámci , aby je bylo možné OnInitializedAsync používat v celé aplikaci.

Další informace a příklad kódu najdete v tématu Blazor ServerASP.NET Core další scénáře zabezpečení .

Vyčerpání prostředků

K vyčerpání prostředků může dojít, když klient komunikuje se serverem a způsobí, že Server spotřebovává nadměrné prostředky. Nadměrné využití prostředků primárně ovlivňuje:

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

Prostředky, které jsou externí pro Blazor rámec, jako jsou databáze a obslužné rutiny souborů (slouží ke čtení a zápisu souborů), můžou taky vyčerpat prostředky. Další informace naleznete v tématu ASP.NET Core Osvědčené postupy z oblasti výkonu.

Procesor

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

Představte si třeba Blazor Server aplikaci, která vypočítá Fibonnacci číslo. Fibonnacci číslo je vytvořeno z Fibonnacci sekvence, kde každé číslo v sekvenci je součet dvou předcházejících čísel. Množství práce potřebné k dosažení odpovědi závisí na délce sekvence a na velikosti počáteční hodnoty. Pokud aplikace neumístí omezení na požadavky klienta, mohou výpočty náročné na procesor poznamenat čas procesoru a snížit výkon dalších úloh. Nadměrné využití prostředků je zabezpečení, které má vliv na dostupnost.

Vyčerpání výkonu procesoru je obavou pro všechny veřejné aplikace. V běžných webových aplikacích jsou požadavky a připojení vyprší jako ochrana, ale Blazor Server aplikace neposkytují stejné záruky. Blazor Server aplikace musí před provedením práce náročné na procesor zahrnovat vhodné kontroly a omezení.

Memory (Paměť)

K vyčerpání paměti může dojít v případě, že jeden nebo více klientů vynutí Server, aby využíval velké množství paměti.

Představte si třeba Blazor aplikaci na straně serveru s komponentou, která přijímá a zobrazuje seznam položek. Pokud Blazor aplikace neumístí omezení na povolený počet položek nebo počet položek, které se vrátí klientovi, může zpracování a vykreslování náročné na paměť podznamenat paměť serveru do bodu, ve kterém výkon serveru utrpí. Server může způsobit selhání nebo zpomalit bod, na kterém se zdá, že došlo k chybě.

Při údržbě a zobrazování seznamu položek, které se vztahují k potenciálnímu scénáři vyčerpání paměti na serveru, vezměte v úvahu následující scénář:

  • Položky ve List<MyItem> vlastnosti nebo poli používají paměť serveru. Pokud aplikace umožňuje dosáhnout neohraničeného seznamu položek, dojde k riziku serveru, který nemá dostatek paměti. Nedostatek paměti způsobí, že aktuální relace skončí (zhroucení) a všechny souběžné relace v této instanci serveru obdrží výjimku z důvodu nedostatku paměti. Aby nedocházelo k tomuto scénáři, musí aplikace používat datovou strukturu, která ukládá omezení počtu položek na souběžných uživatelích.
  • Pokud se schéma stránkování nepoužívá pro vykreslování, server používá další paměť pro objekty, které nejsou viditelné v uživatelském rozhraní. Bez omezení počtu položek mohou nároky na paměť vyčerpat dostupnou paměť serveru. Chcete-li zabránit tomuto scénáři, použijte jeden z následujících přístupů:
    • Při vykreslování použít stránkované seznamy.
    • Zobrazí se pouze prvních 100 až 1 000 položek a vyžaduje, aby uživatel zadal kritéria hledání, aby vyhledal položky nad zobrazenými položkami.
    • Pro pokročilejší scénář vykreslování implementujte seznamy nebo mřížky podporující virtualizaci. Pomocí virtualizace vykreslí pouze podmnožinu položek, které jsou aktuálně viditelné uživateli. Když uživatel pracuje s posuvníkem v uživatelském rozhraní, komponenta vykreslí pouze ty položky, které jsou nutné k zobrazení. Položky, které nejsou aktuálně požadovány k zobrazení, lze uchovávat v sekundárním úložišti, což je ideální přístup. Nezobrazené položky je také možné uchovávat v paměti, což je méně ideální.

Blazor Serveraplikace nabízejí podobný programovací model pro jiné architektury uživatelského rozhraní pro stavové aplikace, jako je WPF, model Windows Forms nebo Blazor WebAssembly . Hlavním rozdílem je to, že v několika rozhraních uživatelského rozhraní paměť spotřebovaná aplikací patří klientovi a ovlivňuje pouze jednotlivé klienty. Například Blazor WebAssembly aplikace běží úplně na klientovi a používá jenom prostředky paměti klienta. V Blazor Server případě, že paměť spotřebovaná aplikací patří do serveru a je sdílená mezi klienty v instanci serveru.

Požadavky na paměť na straně serveru jsou zvážené pro všechny Blazor Server aplikace. Většina webových aplikací je ale Bezstavová a při vrácení odpovědi se uvolní paměť, která se používá při zpracování žádosti. Obecně doporučujeme, abyste klientům nepovolili přidělit nevázanou velikost paměti jako v jakékoli jiné aplikaci na straně serveru, která se zachovává připojení klientů. Paměť využitá Blazor Server aplikací trvá déle než jedna žádost.

Poznámka

Během vývoje lze použít Profiler nebo zaznamenané trasování pro vyhodnocení požadavků na paměť klientů. Profiler nebo trasování nezachycuje 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 prověřte požadavky na paměť všech objektů, které jsou v okruhu uživatele rootem.

Připojení klientů

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

Blazor klienti navážou jedno připojení na jednu relaci a udržují připojení otevřené po celou dobu, než se otevře okno prohlížeče. Požadavky na server správy všech připojení nejsou specifické pro Blazor aplikace. Vzhledem k trvalé povaze připojení a stavové povaze Blazor Server aplikací je vyčerpání spojení větším rizikem pro dostupnost aplikace.

Ve výchozím nastavení se počet připojení na uživatele pro aplikaci nijak neomezuje Blazor Server . Pokud aplikace vyžaduje limit připojení, proveďte jednu nebo více následujících přístupů:

  • Vyžaduje ověření, které přirozeně omezuje možnosti neautorizovaných uživatelů připojit se k aplikaci. Aby byl tento scénář účinný, je nutné uživatelům zabránit v zřizování nových uživatelů.
  • Omezte počet připojení na uživatele. Omezení připojení je možné dosáhnout pomocí následujících přístupů. Dbejte na to, abyste uživatelům povolili přístup k aplikaci (například když je na základě IP adresy klienta vytvořen limit připojení).

    • Na úrovni aplikace:

      • Rozšiřitelnost směrování koncových bodů.
      • Vyžadovat ověřování pro připojení k aplikaci a sledování aktivních relací na uživatele.
      • Po dosažení limitu zamítnout nové relace.
      • Proxy připojení WebSocket k aplikaci prostřednictvím proxy serveru, jako je například SignalR Služba Azure , která multiplexuje připojení z klientů do aplikace. Tato funkce poskytuje aplikaci s větší kapacitou připojení, než může jeden klient navázat a zabránit klientovi v vyčerpání připojení k serveru.

    • Na úrovni serveru: před aplikací použijte proxy server nebo bránu. Například přední dveře Azure umožňují definovat, spravovat a monitorovat globální směrování webového provozu do aplikace a funguje, když Blazor Server jsou aplikace nakonfigurované na používání dlouhého cyklického dotazování.

      Poznámka

      I když pro aplikace je podporované dlouhé cyklické dotazování Blazor Server , je protokol WebSocket doporučený transportní protokol. Přední dveře Azure v tuto chvíli nepodporují WebSockets, ale v budoucí verzi služby se vyplatí podpora pro objekty WebSockets.

Útoky DoS (Denial of Service)

Útoky DoS (Denial of Service) zahrnují klienta, který způsobuje, že server vyčerpá jeden nebo víc svých prostředků, takže aplikace nebude k dispozici. Blazor Serveraplikace zahrnují výchozí limity a spoléhají na jiné ASP.NET Core a SignalR omezení ochrany proti útokům DoS nastaveným na CircuitOptions :

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

Interakce s prohlížečem (klient)

Klient komunikuje s odesláním a dokončením vykreslování událostí serveru prostřednictvím aplikace JS. Komunikace interoperability JS přechází mezi oběma způsoby mezi jazykem JavaScript a .NET:

  • Události prohlížeče jsou odesílány z klienta na server asynchronním způsobem.
  • Server odpoví asynchronním vykreslením uživatelského rozhraní podle potřeby.

Funkce JavaScriptu vyvolané z .NET

Pro volání z metod .NET do JavaScriptu:

  • Všechna volání mají konfigurovatelný časový limit, po kterém selžou a vrátí OperationCanceledException volajícímu .
  • 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 je vyvolána a je vytvořen výsledek nebo chyba. Klient se zlými úmysly se může pokusit:
    • Vrácením chyby z funkce JavaScriptu způsobíte problém v aplikaci.
    • Indukuje nezamýšlené chování na serveru vrácením neočekávaného výsledku z funkce JavaScriptu.

Před předchozími scénáři se vezměte vhod následující opatření:

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

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

Nevěřte volání metodám .NET z JavaScriptu. Když je metoda .NET zpřístupněna v JavaScriptu, zvažte, jak se vyvolá metoda .NET:

  • Zacházet s jakoukoli metodou .NET vystavenou JavaScriptu jako s veřejným koncovým bodem aplikace.
    • Ověřte vstup.
      • Ujistěte se, že hodnoty jsou v očekávaném rozsahu.
      • Ujistěte se, že má uživatel oprávnění k provedení požadované akce.
    • Při vyvolání metody .NET přidělujte nadměrné množství prostředků. Například proveďte kontroly a umiste omezení využití procesoru a paměti.
    • Vezměte v úvahu, že statické a instance metod mohou být vystaveny klientům JavaScriptu. Vyhněte se sdílení stavu mezi relacemi, pokud návrh nevyvolá stav sdílení s příslušnými omezeními.
      • Například metody vystavené prostřednictvím objektů, které byly původně vytvořeny prostřednictvím injektáže závislostí (DI), by objekty měly být DotNetReference registrovány jako objekty s vymezeným oborem. To platí pro všechny služby diod, Blazor Server které aplikace používá.
      • U statických metod se vyhněte vytvoření stavu, který nelze vymezit na klienta, pokud aplikace explicitně neschová stav mezi všemi uživateli v instanci serveru.
    • Vyhněte se předávání uživatelem zadaných dat v parametrech voláním JavaScriptu. Pokud je předávání dat v parametrech naprosto nezbytné, zajistěte, aby kód JavaScriptu zpracuje předávání dat bez zavedení ohrožení zabezpečení skriptování mezi weby (XSS). Například nezapisování uživatelem zadaných dat do objektu model DOM (Document Object Model) (DOM) nastavením innerHTML vlastnosti elementu. Zvažte použití zásad zabezpečení obsahu (CSP) k zakázání a dalších nebezpečných primitiv eval JavaScriptu.
  • Vyhněte se implementaci vlastního odesílání volání .NET nad implementaci rozhraní pro odesílání. Vystavení metod .NET prohlížeči je pokročilý scénář, který se nedoporučuje pro obecný Blazor vývoj.

Události

Události poskytují vstupní bod do Blazor Server aplikace. Stejná pravidla pro ochranu koncových bodů ve webových aplikacích platí pro zpracování událostí v Blazor Server aplikacích. Klient se zlými úmysly může odeslat jakákoli data, která chce odeslat jako datovou část události.

Příklad:

  • Událost změny pro může odeslat hodnotu, která není v rámci možností, <select> které aplikace prezentoval klientovi.
  • Objekt <input> může na server odeslat libovolná textová data a obejít tak ověřování na straně klienta.

Aplikace musí ověřit data pro všechny události, které aplikace zpracovává. Komponenty Blazor formulářů architektury provádějí základní ověření. Pokud aplikace používá vlastní komponenty formulářů, musí být vlastní kód zapsán, aby se data události ověřila podle potřeby.

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

Představte si komponentu čítače, která by měla uživateli umožnit zvýšit čítač maximálně třikrát. Tlačítko pro zvýšení čítače je podmíněně založené 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ž rozhraní vytvoří nové vykreslení této komponenty. Výsledkem je, že uživatel může zvýšit hodnotu na více než třikrát, protože uživatelské rozhraní tlačítko není odebráno dostatečně count 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++;
        }
    }
}

Přidáním kontroly do obslužné rutiny je rozhodnutí o zvýšení založeno na if (count < 3) { ... } count 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 před více odesláními

Pokud zpětné volání události vyvolá dlouhotrací operaci asynchronně, například načítání dat z externí služby nebo databáze, zvažte použití ochrany. Ochrana může zabránit uživateli v zařadit více operací do fronty, zatímco operace probíhá pomocí vizuální zpětné vazby. Následující kód komponenty nastaví isLoading na , zatímco získá data ze true GetForecastAsync serveru. Zatímco isLoading je , je tlačítko v true uživatelském rozhraní zakázané:

@page "/fetchdata"
@using BlazorServerSample.Data
@inject WeatherForecastService ForecastService

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

@code {
    private bool isLoading;
    private WeatherForecast[] forecasts;

    private async Task UpdateForecasts()
    {
        if (!isLoading)
        {
            isLoading = true;
            forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
            isLoading = false;
        }
    }
}

Vzor guard předvedený v předchozím příkladu funguje, pokud se operace na pozadí provádí asynchronně se async - await vzorem.

Zrušení v rané fázi a zabránění použití po uvolnění

Kromě použití guard, jak je popsáno v části Ochrana proti více voláním, zvažte použití ke zrušení dlouhotrvatých operací, CancellationToken když je komponenta odstraněna. Tento přístup má přidanou výhodu v tom, že se v komponentách vyhnete použití po uvolnění:

@implements IDisposable

...

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

    private async Task UpdateForecasts()
    {
        ...

        forecasts = await ForecastService.GetForecastAsync(DateTime.Now, 
            TokenSource.Token);

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

        ...
    }

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

Vyhněte se událostem, které produkují velké objemy dat

Některé události modelu DOM, například oninput onscroll nebo , mohou produkci velkého množství dat. Vyhněte se používání těchto událostí v Blazor serverových aplikacích.

Další pokyny k zabezpečení

Pokyny k zabezpečení aplikací ASP.NET Core platí pro aplikace a Blazor Server jsou uvedená v následujících částech:

Protokolování a citlivá data

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

Pokud na serveru dojde k chybě, rozhraní upozorní klienta a relaci zkrátí. Ve výchozím nastavení klient obdrží obecnou chybovou zprávu, která se zobrazí ve 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 takové informace obsahují. Pro účely vývoje mohou být citlivé informace o chybách klientovi dostupné povolením podrobných chyb.

Upozornění

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

Ochrana informací během přenosu pomocí protokolu HTTPS

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

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

Skriptování mezi weby (XSS)

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

  • Odešlete na server falešné nebo neplatné události.
  • Odeslání se nepovede nebo se nedokončování vykreslování zruší.
  • Vyhněte se odesílání dokončování vykreslování.
  • Volání zprostředkovatele komunikace z JavaScriptu do .NET
  • Upravte odpověď volání zprostředkovatele komunikace z .NET do JavaScriptu.
  • Vyhněte se odesílání výsledků zprostředkovatele komunikace .NET do JS.

Toto Blazor Server rozhraní podniká kroky k ochraně před některými z předchozích hrozeb:

  • Zastaví vytváření nových aktualizací uživatelského rozhraní, pokud klient nepotvrzuje dávky vykreslování. Nakonfigurováno s CircuitOptions.MaxBufferedUnacknowledgedRenderBatches .
  • Časové razítko jakéhokoli volání .NET do JavaScriptu po jedné minutě bez přijetí odpovědi od klienta. Nakonfigurováno s CircuitOptions.JSInteropDefaultCallTimeout .
  • Provádí základní ověření všech vstupů přicházejících z prohlížeče během zprostředkovatele komunikace JS:
    • Odkazy na .NET jsou platné a typu očekávaného metodou .NET.
    • Data nejsou poškozená.
    • V datové části je přítomný správný počet argumentů pro metodu .
    • Argumenty nebo výsledek lze správně deserializovat před vyvoláním metody.
  • Provádí 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 lze deserializovat.
    • K události je přidružená obslužná rutina události.

Kromě ochranných opatření implementovaných architekturou musí být aplikace kódována vývojářem, aby byla chráněna před hrozbami a příslušná opatření:

  • Při zpracování událostí vždy ověřovat data.
  • Po přijetí neplatných dat udělejte příslušnou akci:
    • Ignorujte data a vraťte se. To aplikaci umožňuje pokračovat ve zpracování požadavků.
    • Pokud aplikace zjistí, že je vstup neschůdný a nemůže být vytvořen legitimním klientem, vyvolá výjimku. Vyvoláním výjimky se okruh ukončí a relace se ukončí.
  • Důvěřování chybové zprávě poskytované při dávkovém dokončování vykreslování zahrnutých v protokolech Tuto chybu poskytuje klient a obecně není důvěryhodná, protože klient může být ohrožen.
  • Nevěřte vstupu u volání zprostředkovatele komunikace JS v obou směrech mezi metodami JavaScriptu a .NET.
  • 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 existovalo ohrožení zabezpečení XSS, musí aplikace na vykreslené stránce začlenit uživatelský vstup. Blazor Server Komponenty provedou krok v době kompilace, kdy se kód v souboru .razor transformuje na procedurální logiku jazyka C#. Za běhu vytvoří logika jazyka C# strom vykreslování popisující elementy, text a podřízené komponenty. To se aplikuje na dom prohlížeče prostřednictvím sekvence javascriptových instrukcí (nebo se v případě prerenderingu serializuje do HTML):

  • Uživatelský vstup vykreslený pomocí normální syntaxe (například ) nezpřístupňuje ohrožení zabezpečení Razor XSS, protože syntaxe se do modelu DOM přidává prostřednictvím příkazů, které píšou jenom @someStringValue Razor text. I když hodnota obsahuje kód HTML, hodnota se zobrazí jako statický text. Při předběžném vykreslení je výstup kódovaný html, který také zobrazuje obsah jako statický text.
  • Značky skriptů nejsou povolené a neměly by být zahrnuty do stromu vykreslování komponent aplikace. Pokud je značka skriptu součástí značek komponenty, vygeneruje se chyba při kompilaci.
  • Autoři komponent mohou vytvářet komponenty v jazyce C# bez použití Razor . Autor komponenty zodpovídá za používání správných rozhraní API při vysílání výstupu. Použijte například a ne , protože druhá možnost by builder.AddContent(0, someUserSuppliedString) mohla vytvořit ohrožení zabezpečení builder.AddMarkupContent(0, someUserSuppliedString) XSS.

V rámci ochrany před útoky XSS zvažte implementaci omezení rizik XSS, jako jsou zásady zabezpečení obsahu (CSP).

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

Ochrana mezi zdroji

Mezi útoky mezi zdroji patří klient z jiného původu, který provádí akci se serverem. Škodlivou akcí je obvykle požadavek GET nebo formulář POST (CsRF) napříč weby, ale je také možné otevřít škodlivý WebSocket. Blazor ServerAplikace nabízejí stejné záruky jako všechny ostatní aplikace SignalR používající protokol centra:

  • Blazor Server Aplikace jsou přístupné mezi zdroji, pokud nejsou přijata další opatření, která jim brání. Pokud chcete zakázat přístup mezi zdroji, zakažte CORS v koncovém bodě přidáním middlewaru CORS do kanálu a přidáním do metadat koncového bodu, nebo omezte sadu povolených zdrojů tím, že nakonfigurujete sdílení prostředků mezi DisableCorsAttribute Blazor zdroji. SignalR
  • 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ý, je možné CORS pro centrum zakázat přidáním metadat do metadat koncového bodu po volání ve tvůrci Blazor Server DisableCorsAttribute tras MapBlazorHub koncového bodu.

Další informace naleznete v tématu Prevence útoků XSRF/CSRF (Cross-Site Request Forgery) v ASP.NET Core.

Klikání

Při klikání se web vykresluje jako web z jiného původu, aby se uživatel mohl obelstít k provádění akcí na webu, na který <iframe> útok napadá.

Pokud chcete chránit aplikaci před vykreslováním uvnitř , použijte zásady zabezpečení obsahu <iframe> (CSP) a X-Frame-Options hlavičku . Další informace najdete v tématu Webové dokumenty MDN: X-Frame-Options.

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

Při spuštění relace aplikace provede server základní ověření adres URL odeslaných v Blazor Server rámci spuštění relace. Rozhraní před vytvořením okruhu zkontroluje, že základní adresa URL je nadřazená aktuální adrese URL. Žádná další kontrola není prováděna architekturou.

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

Komponenty mohou také aktivovat žádosti o navigaci programově prostřednictvím NavigationManager . V takových scénářích může aplikace provést navigaci na straně klienta nebo v prohlížeči označit, že má přejít do nového umístění.

Součásti musí:

  • Nepoužívejte vstup uživatele jako součást argumentů volání navigace.
  • Ověřte argumenty, abyste zajistili, že aplikace bude mít povolený cíl.

Jinak může uživatel se zlými úmysly přinutit prohlížeč přejít na web řízený útočníkem. V tomto scénáři útočník zmátá aplikaci, aby v rámci vyvolání metody mohl použít nějaký uživatelský NavigationManager.NavigateTo 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 platnost absolutních cílů odkazu.

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

Kontrolní seznam zabezpečení

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

  • Ověřte argumenty z událostí.
  • Ověření vstupů a výsledků z volání vzájemné spolupráce JS
  • Vyhněte se použití (nebo ověření předem) uživatelského vstupu pro volání zprostředkovatele komunikace .NET do JS.
  • Zabrání klientovi přidělit nevázané množství paměti.
    • Data v rámci komponenty.
    • DotNetObject odkazy vrácené klientovi.
  • Ochrana před více odesláními.
  • Zrušení dlouhotrvatých operací, když je komponenta odstraněna.
  • Vyhněte se událostem, které produkují velké objemy dat.
  • Nepoužívejte uživatelský vstup jako součást volání a ověřte vstup uživatele pro adresy URL pro sadu povolených původů, pokud NavigationManager.NavigateTo je to nevyhnutelné.
  • Neděláte rozhodnutí o autorizaci na základě stavu uživatelského rozhraní, ale pouze ze stavu komponenty.
  • Zvažte použití zásad zabezpečení obsahu (CSP) k ochraně před útoky XSS.
  • Zvažte použití CSP a X-Frame-Options k ochraně před zakňožením klikání.
  • 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 omezení na straně serveru pro aplikaci poskytují přijatelné uživatelské prostředí bez Blazor nepřijatelných úrovní rizika.

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

Když uživatel navštíví Blazor Server lokalitu, server vytvoří v paměti serveru okruh. Okruh prohlížeči indikuje, jaký obsah se má vykreslit, a reaguje 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 metody .NET na serveru. Tato dvousměnná interakce založená na JavaScriptu se označuje jako interoperabilita JavaScriptu (interoperabilita JS).

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

V prostředích s omezenými omezeními, například v podnikových sítích nebo intranetech, jsou některé z těchto pokynů k omezení rizik:

  • Neplatí pro omezené prostředí.
  • Není vhodné implementovat náklady, protože bezpečnostní riziko je v omezeném prostředí nízké.

Blazor a sdílený stav

Blazor serverové aplikace živě v paměti serveru. To znamená, že v rámci stejného procesu je hostovaných více aplikací. Pro každou relaci aplikace spustí Blazor okruh s vlastním oborem kontejneru DI. To znamená, že vymezené služby jsou pro každou relaci Blazor jedinečné.

Upozornění

Aplikace ve stejném stavu sdílené složky serveru nedoporučujeme používat s využitím jednosměnné služby, pokud není přijata extrémní péče, protože to může představovat ohrožení zabezpečení, jako je například únik stavu uživatele napříč okruhy.

V aplikacích můžete používat stavové jednosměnné Blazor služby, pokud jsou pro něj speciálně navržené. Mezipaměť paměti můžete použít například jako jednu položku, protože vyžaduje klíč pro přístup k dané položce za předpokladu, že uživatelé nemají kontrolu nad tím, jaké klíče mezipaměti se používají.

Z bezpečnostních důvodů se navíc nesmí používat IHttpContextAccessor v Blazor aplikacích. Blazoraplikace běží mimo kontext kanálu ASP.NET Core. Není zaručeno, že bude k dispozici v rámci , ani není zaručeno, že bude uchovat kontext, HttpContext IHttpContextAccessor který aplikaci Blazor zahájil.

Doporučený způsob, jak předat stav požadavku do aplikace, je prostřednictvím parametrů kořenové komponentě při Blazor počátečním vykreslování aplikace:

  • Definujte třídu se všemi daty, která chcete do Blazor aplikace předat.
  • Naplňte tato data ze Razor stránky pomocí možnosti dostupné v tomto HttpContext okamžiku.
  • Předejte data do Blazor aplikace jako parametr do kořenové komponenty (aplikace).
  • V kořenové komponentě definujte parametr, který bude obsahovat data předaná do aplikace.
  • Použití dat specifických pro uživatele v rámci aplikace Nebo můžete tato data zkopírovat do vymezené služby v rámci , aby je bylo možné OnInitializedAsync používat v celé aplikaci.

Další informace a příklad kódu najdete v tématu Blazor ServerASP.NET Core další scénáře zabezpečení .

Vyčerpání prostředků

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

Útoky DoS (Denial of Service) se obvykle snaží vyčerpaly prostředky aplikace nebo serveru. Vyčerpání prostředků ale nemusí nutně být výsledkem útoku na systém. Například omezené prostředky je možné vyčerpaně kvůli vysoké poptávce uživatelů. DoS je dále popsán v části Útoky na odepření služeb (DoS).

U prostředků externích pro rozhraní, jako jsou databáze a popisovače souborů (používané ke čtení a zápisu souborů), může dojít také k Blazor vyčerpání prostředků. Další informace naleznete v tématu ASP.NET Core Osvědčené postupy z oblasti výkonu.

Procesor

K vyčerpání procesoru může dojít v případě, že jeden nebo více klientů vynutí, aby server intenzivně pracoval na procesoru.

Představte si například Blazor Server aplikaci, která vypočítá Fibonnacciho číslo. Fibonnacciho číslo se produkuje z Fibonnacciho posloupnosti, 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 nenamizí omezení požadavků klienta, výpočty náročné na procesor mohou dominovat času procesoru a snížit výkon jiných úloh. Nadměrná spotřeba prostředků je bezpečnostním problémem, který ovlivňuje dostupnost.

Vyčerpání procesoru je pro všechny veřejně přístupné aplikace důležité. V běžných webových aplikacích časový limit požadavků a připojení zamešla jako ochrana, ale aplikace neposkytují Blazor Server stejná bezpečnostní opatření. Blazor Server Aplikace musí před provedením potenciálně náročné práce na procesoru zahrnovat odpovídající kontroly a omezení.

Memory (Paměť)

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

Představte si například Blazor aplikaci na straně serveru s komponentou, která přijímá a zobrazuje seznam položek. Pokud aplikace neumisťuje omezení počtu povolených položek nebo počtu položek vykreslených zpět klientovi, zpracování a vykreslování náročné na paměť může dominovat paměti serveru až do bodu, kdy dochází ke snížení výkonu Blazor serveru. Server může selha nebo pomalu do bodu, kdy se zdá, že havaroval.

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

  • Položky ve List<MyItem> vlastnosti nebo poli používají paměť serveru. Pokud aplikace povolí, aby se seznam položek rozrůstal bez vázaného stavu, existuje riziko, že serveru došla paměť. Při vyšetřené paměti se ukončí aktuální relace (chyba) a u všech souběžných relací v této instanci serveru dojde k výjimce typu "mimo paměť". Aby k tomuto scénáři nedosálo, musí aplikace používat datovou strukturu, která pro souběžné uživatele omezuje položky.
  • Pokud se schéma stránkování pro vykreslování používá, server používá další paměť pro objekty, které nejsou viditelné v uživatelském rozhraní. Bez omezení počtu položek může nároky na paměť vyčerpanou 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í se jenom prvních 100 až 1 000 položek a uživatel musí zadat kritéria vyhledávání, aby našel položky nad rámec zobrazených položek.
    • V případě pokročilejšího scénáře vykreslování implementujte seznamy nebo mřížky, které podporují virtualizaci. Pomocí virtualizace vykreslí seznamy pouze 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í jenom položky potřebné k zobrazení. Položky, které aktuálně nejsou potřeba k zobrazení, se mohou nachovat v sekundárním úložišti, což je ideální přístup. Nezobrazované položky lze také uchovat v paměti, což je méně ideální.

Blazor ServerAplikace nabízejí podobný programovací model jako jiné architektury uživatelského rozhraní pro stavové aplikace, jako je WPF, 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 tohoto jednotlivého klienta. Například aplikace běží zcela na klientovi a Blazor WebAssembly používá pouze prostředky paměti klienta. V tomto scénáři paměť spotřebovaná aplikací patří serveru a sdílí se mezi klienty Blazor Server v instanci serveru.

Požadavky na paměť na straně serveru jsou důležité pro všechny Blazor Server aplikace. Většina webových aplikací je ale bez stavu a při vrácení odpovědi se uvolní paměť použitá při zpracování požadavku. Obecně neumožňovat klientům přidělit nevázané množství paměti jako v jakékoli jiné aplikaci na straně serveru, která uchová klientská připojení. Paměť spotřebovaná aplikací trvá déle než Blazor Server jeden požadavek.

Poznámka

Během vývoje je možné použít profiler nebo zachytit trasování k vyhodnocení požadavků klientů na paměť. Profiler nebo trasování nezachytí paměť přidělenou konkrétnímu klientovi. Pokud chcete zaznamenat využití paměti konkrétního klienta během vývoje, zachyťte výpis paměti a prozkoumejte poptávku po paměti všech objektů rootovaných v okruhu uživatele.

Připojení klientů

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

Blazor klienti vytvoří jedno připojení pro každou relaci a připojení nechte otevřené po dobu, po které je otevřené okno prohlížeče. Požadavky na server údržby všech připojení nejsou specifické pro Blazor aplikace. Vzhledem k trvalé povaze připojení a stavové povaze aplikací je vyčerpání připojení pro dostupnost Blazor Server aplikace větší riziko.

Ve výchozím nastavení neexistuje žádné omezení počtu připojení na uživatele pro Blazor Server aplikaci. Pokud aplikace vyžaduje limit připojení, využijte jeden nebo několik následujících přístupů:

  • Vyžadovat ověřování, které přirozeně omezuje možnost neautorizovaných uživatelů připojit se k aplikaci. Aby byl tento scénář efektivní, je nutné uživatelům zabránit ve zřizování nových uživatelů podle chví.
  • Omezte počet připojení na uživatele. K omezení připojení můžete použít následující přístupy. Procvičte si přístup k aplikaci oprávněným uživatelům (například při nastavení limitu připojení na základě IP adresy klienta).

    • Na úrovni aplikace:

      • Rozšiřitelnost směrování koncových bodů.
      • Vyžadovat ověření pro připojení k aplikaci a sledování aktivních relací na uživatele.
      • Odmítnout nové relace při dosažení limitu.
      • Proxy připojení WebSocket k aplikaci prostřednictvím proxy serveru, jako je služba Azure, SignalR která multiplexuje připojení z klientů do aplikace. To poskytuje aplikaci větší kapacitu připojení, než může vytvořit jeden klient, což klientovi brání v vyčerpání připojení k serveru.

    • Na úrovni serveru: Před aplikací použijte proxy server nebo bránu.

      Poznámka

      Přestože aplikace podporují dlouhé dotazování, doporučuje se Blazor Server přenosový protokol WebSocket.

Útoky DoS (Denial of Service)

K útokům DoS (Denial of Service) patří klient, který způsobuje, že server vyčerpá jeden nebo více prostředků, takže aplikace není dostupná. Blazor Serveraplikace zahrnují výchozí limity a spoléhají na jiné ASP.NET Core a omezení pro ochranu před útoky SignalR DoS nastavenými na CircuitOptions :

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

Interakce s prohlížečem (klient)

Klient komunikuje se serverem prostřednictvím dispečinku událostí zprostředkovatele komunikace JS a dokončení vykreslování. Komunikace zprostředkovatele komunikace JS mezi JavaScriptem a .NET prochází oběma způsoby:

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

Funkce Jazyka JavaScript vyvolané z .NET

Pro volání z metod .NET do JavaScriptu:

  • Všechna volání mají konfigurovatelný časový limit, po kterém selžou a vrátí OperationCanceledException volajícímu .
  • 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 je vyvolána a je vytvořen výsledek nebo chyba. Klient se zlými úmysly se může pokusit:
    • Vrácením chyby z funkce JavaScriptu způsobíte problém v aplikaci.
    • Indukuje nezamýšlené chování na serveru vrácením neočekávaného výsledku z funkce JavaScriptu.

Před předchozími scénáři se vezměte vhod následující opatření:

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

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

Nevěřte volání metodám .NET z JavaScriptu. Když je metoda .NET zpřístupněna v JavaScriptu, zvažte, jak je vyvolána metoda .NET:

  • Zacházet s jakoukoli metodou .NET vystavenou JavaScriptu jako s veřejným koncovým bodem aplikace.
    • Ověřte vstup.
      • Ujistěte se, že hodnoty jsou v rámci očekávaných rozsahů.
      • Zajistěte, aby měl uživatel oprávnění k provedení požadované akce.
    • Nepřiřazujte nadměrné množství prostředků jako součást volání metod .NET. Například proveďte kontrolu a umístěte omezení využití procesoru a paměti.
    • Vezměte v úvahu, že statické a instanční metody můžou být vystavené klientům JavaScriptu. Vyhněte se sdílení stavu napříč relacemi, pokud se návrh nevolá pro stav sdílení s příslušnými omezeními.
      • Pro metody DotNetReference , které jsou vystaveny prostřednictvím objektů, které byly vytvořeny prostřednictvím injektáže Dependency vstřik (di), by měly být objekty registrovány jako objekty s oborem. To platí pro všechny služby DI, které Blazor Server aplikace používá.
      • U statických metod Vyhněte se vytváření stavu, který nelze nastavit na klienta, pokud aplikace explicitně nesdílí stav pro všechny uživatele v instanci serveru.
    • Vyhněte se předávání dat poskytovaných uživatelem v parametrech volání JavaScript. Pokud je předávání dat v parametrech naprosto povinné, ujistěte se, že kód jazyka JavaScript zpracovává předávání dat bez nutnosti chyby zabezpečení SKRIPTOVÁNÍ XSS (více lokalit) . Nepište například data dodaná uživatelem do model DOM (Document Object Model) (DOM) nastavením innerHTML vlastnosti prvku. Zvažte použití zásad zabezpečení obsahu (CSP) k zakázání eval a dalším nebezpečným primitivním primitivům jazyka JavaScript.
  • Neimplementujte implementaci vlastního odesílání volání .NET nad rámec implementace odesílajícího rozhraní. Vystavení 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 Blazor Server aplikaci. Stejná pravidla pro ochranu koncových bodů ve webových aplikacích se vztahují na zpracování událostí v Blazor Server aplikacích. Škodlivý klient může odesílat všechna data, která chce odeslat jako datovou část pro událost.

Příklad:

  • Událost změny pro <select> by mohla odeslat hodnotu, která není v rámci možností, které aplikace prezentuje klientovi.
  • <input>Může odeslat veškerá textová data na server a obejít ověřování na straně klienta.

Aplikace musí ověřit data pro všechny události, které aplikace zpracovává. Blazor Komponenty formulářů rozhraní provádějí základní ověření. Pokud aplikace používá vlastní součásti formulářů, je nutné napsat vlastní kód pro ověření dat události podle potřeby.

Blazor Server události jsou asynchronní, takže je možné odeslat do serveru více událostí, než aplikace začne reagovat tím, že vygeneruje nové vykreslování. To má vliv na některé zabezpečení, které je potřeba vzít v úvahu. Omezení akcí klienta v aplikaci musí být provedeno uvnitř obslužných rutin událostí a nemusí být závislé na aktuálním stavu zobrazení.

Vezměte v úvahu komponentu čítače, která by uživateli umožnila zvýšit hodnotu čítače maximálně třikrát. Tlačítko pro zvýšení čítače je podmíněně na základě hodnoty 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é vykreslování této součásti. Výsledkem je, že count uživatel může tento krok zvýšit za třikrát , protože toto tlačítko není v uživatelském rozhraní k dispozici 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++;
        }
    }
}

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

Ochrana proti více odesláním

Pokud zpětné volání události vyvolá asynchronně běžící operaci, jako je například načítání dat z externí služby nebo databáze, zvažte použití ochrany. Ochrana může uživatelům zabránit ve zařazení více operací do fronty, zatímco operace probíhá pomocí vizuální zpětné vazby. Následující kód komponenty nastaví isLoading na, true Když GetForecastAsync získá data ze serveru. isLoadingV nástroji je true tlačítko neaktivní v uživatelském rozhraní:

@page "/fetchdata"
@using BlazorServerSample.Data
@inject WeatherForecastService ForecastService

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

@code {
    private bool isLoading;
    private WeatherForecast[] forecasts;

    private async Task UpdateForecasts()
    {
        if (!isLoading)
        {
            isLoading = true;
            forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
            isLoading = false;
        }
    }
}

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

Zrušit počáteční a vyhnout se použití po vyřazení

Kromě používání ochrany, jak je popsáno v části Guard proti více odesláních , zvažte použití nástroje CancellationToken ke zrušení dlouhotrvajících operací při likvidaci komponenty. Tento přístup má výhodu při zamezení používání funkcí po Dispose v součástech:

@implements IDisposable

...

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

    private async Task UpdateForecasts()
    {
        ...

        forecasts = await ForecastService.GetForecastAsync(DateTime.Now, 
            TokenSource.Token);

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

        ...
    }

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

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

Některé události modelu DOM, například oninput nebo onscroll , mohou vytvořit velké množství dat. Nepoužívejte tyto události v Blazor serverových aplikacích.

Další pokyny k zabezpečení

doprovodné materiály k zabezpečení aplikací ASP.NET Core platí pro Blazor Server aplikace a jsou uvedené v následujících oddílech:

Protokolování a citlivá data

Interakce interoperability v JS mezi klientem a serverem se zaznamenávají v protokolech serveru s ILogger instancemi. Blazor Nepoužívejte protokolování citlivých informací, jako jsou například skutečné události nebo vstupy a výstupy interoperability JS.

Když na serveru dojde k chybě, rozhraní upozorní klienta a rozhlasí relaci. Ve výchozím nastavení klient obdrží obecnou chybovou zprávu, která se může 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 obsahují takové informace. Pro účely vývoje lze klientovi zpřístupnit citlivé informace o chybách tím, že povolíte podrobné chyby.

Upozornění

Odhalení informací o chybách klientům na internetu je bezpečnostní riziko, které by se mělo vždy vyhnout.

Ochrana informací při přenosu pomocí protokolu HTTPS

Blazor Server používá se SignalR pro komunikaci mezi klientem a serverem. Blazor Server běžně používá přenos, který SignalR vyjednává, což jsou typicky objekty WebSockets.

Blazor Server nezajišťuje integritu a důvěrnost dat odesílaných mezi serverem a klientem. Vždy používat protokol HTTPS.

Skriptování mezi weby (XSS)

Skriptování mezi weby (XSS) umožňuje neoprávněné straně spustit libovolnou logiku v kontextu prohlížeče. Ohrožená aplikace by mohla spustit libovolný kód v klientovi. Chybu zabezpečení lze použít k potenciálnímu provedení určitého množství škodlivých akcí proti serveru:

  • Odeslání falešných/neplatných událostí na server.
  • Odeslání neúspěšných nebo neplatných dokončení vykreslování.
  • Vyhněte se odesílání doplňování vykreslování.
  • Odešlete volání Interop z JavaScriptu do .NET.
  • Upravte odpověď volání Interop z rozhraní .NET na JavaScript.
  • Vyhněte se odesílání výsledků interoperability .NET to JS.

Blazor ServerRozhraní používá kroky k ochraně před některými předchozími hrozbami:

  • Ukončí vytváření nových aktualizací uživatelského rozhraní, pokud klient nepotvrzující dávky vykreslování. Nakonfigurováno pomocí CircuitOptions.MaxBufferedUnacknowledgedRenderBatches .
  • Vyprší časový limit volání rozhraní .NET do JavaScriptu po jedné minutě, aniž by byla obdržena odpověď od klienta. Nakonfigurováno pomocí CircuitOptions.JSInteropDefaultCallTimeout .
  • Provede základní ověření na všech vstupech přicházejících z prohlížeče během interoperability JS:
    • Odkazy .NET jsou platné a typ očekávaný metodou .NET.
    • Data nejsou poškozena.
    • V datové části je uveden správný počet argumentů pro metodu.
    • Argumenty nebo výsledky 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 pro událost lze deserializovat.
    • K události je přidružená obslužná rutina události.

Kromě ochrany, kterou implementuje rozhraní, musí být aplikace kódována vývojářem k ochraně před hrozbami a provádět příslušné akce:

  • Při zpracování událostí vždy ověřovat data.
  • Po přijetí neplatných dat proveďte příslušnou akci:
    • Ignorujte data a vraťte se. Tím umožníte, aby aplikace pokračovala v zpracování požadavků.
    • Pokud aplikace zjistí, že vstup je illegitimate a nemohl být vytvořen legitimním klientem, vyvolejte výjimku. Došlo k výjimce při odtrhlině okruhu a ukončení relace.
  • Nedůvěra na chybovou zprávu poskytovanou dokončováním dávek vykreslování zahrnutými v protokolech. Klient poskytuje chybu a nemůže být obecně důvěryhodný, protože může dojít k ohrožení zabezpečení klienta.
  • Nedůvěřovat vstupu volání interoperability JS v obou směrech mezi metodami jazyka JavaScript a .NET.
  • 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 mohla existovat ohrožení zabezpečení XSS, musí aplikace na vykreslené stránce zahrnovat vstup uživatele. Blazor Server komponenty spustí krok v čase kompilace, kde je kód v .razor souboru transformován do logiky jazyka C#. V době běhu vytvoří logika jazyka C# strom vykreslování , který popisuje prvky, text a podřízené komponenty. To se aplikuje na DOM v prohlížeči pomocí sekvence instrukcí JavaScriptu (nebo je v případě předvykreslování serializovaná na HTML):

  • Uživatelský vstup vykreslený pomocí normální Razor syntaxe (například @someStringValue ) nevystavuje zranitelnost XSS, protože Razor syntaxe je přidána do modelu DOM prostřednictvím příkazů, které mohou zapisovat pouze text. I v případě, že hodnota obsahuje kód HTML, hodnota se zobrazí jako statický text. Při předběžné vykreslování je výstupem kódovaný HTML, který také zobrazuje obsah jako statický text.
  • Značky skriptu nejsou povoleny a neměly by být zahrnuty do stromu vykreslování součásti aplikace. Je-li značka skriptu obsažena v kódu komponenty, je vygenerována chyba při kompilaci.
  • 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. Můžete například použít builder.AddContent(0, someUserSuppliedString) a nikoli builder.AddMarkupContent(0, someUserSuppliedString) , protože by to mohlo vytvořit chybu zabezpečení XSS.

Jako součást ochrany proti útokům XSS zvažte implementaci zmírnění XSS, jako je například zásada zabezpečení obsahu (CSP).

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

Ochrana mezi zdroji

Útoky mezi zdroji zahrnují klienta z jiného zdroje, který provádí akci na serveru. Škodlivá akce je obvykle požadavek GET nebo POST formuláře (pro padělání žádostí mezi weby, CSRF), ale otevírání škodlivého WebSocket je také možné. Blazor Server aplikace nabízí stejné záruky jako všechny ostatní SignalR aplikace používající protokol rozbočovače:

  • Blazor Server k aplikacím se dá přihlédnout z více zdrojů, pokud se nepřijmou další opatření, která jim zabrání. Pokud chcete zakázat přístup pro více zdrojů, buď zakažte CORS v koncovém bodu přidáním middlewaru CORS do kanálu a přidáním DisableCorsAttribute do Blazor metadat koncového bodu, nebo omezte sadu povolených SignalR zdrojů konfigurací pro sdílení prostředků mezi zdroji.
  • Pokud je CORS povolená, můžou se při ochraně aplikace v závislosti na konfiguraci CORS vyžadovat další kroky. Pokud je CORS povolena globálně, může být CORS pro centrum zakázaná Blazor Server přidáním DisableCorsAttribute metadat do metadat koncového bodu po volání do MapBlazorHub Tvůrce tras koncových bodů.

Další informace naleznete v tématu Prevence útoků XSRF/CSRF (Cross-Site Request Forgery) v ASP.NET Core.

Kliknutí – zdířka

Kliknutí na zásuvky zahrnuje vykreslování lokality jako <iframe> v rámci lokality z jiného zdroje, aby uživatel mohl v rámci útoku přimět uživatele k provádění akcí na webu.

K ochraně aplikace před vykreslováním v nástroji <iframe> použijte zásady zabezpečení obsahu (CSP) a X-Frame-Options hlavičku. Další informace najdete v tématu MDN web Docs: X-frame-Options.

Otevřít přesměrování

Při Blazor Server spuštění relace aplikace provede Server základní ověření adres URL odesílaných v rámci zahájení relace. Architektura kontroluje, zda je základní adresa URL nadřazena aktuální adrese URL před vytvořením okruhu. Rozhraní neprovádí žádné další kontroly.

Když uživatel vybere odkaz na klientovi, adresa URL odkazu se pošle na server, který určuje, jakou akci chcete provést. Aplikace může například provádět navigaci na straně klienta nebo naznačit prohlížeči, aby přešel do nového umístění.

Komponenty mohou také aktivovat požadavky na navigaci programově prostřednictvím použití NavigationManager . V takových scénářích může aplikace provést navigaci na straně klienta nebo v prohlížeči označit, že se má přejít na nové umístění.

Komponenty musí:

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

V opačném případě může uživatel se zlými úmysly vynutit, aby prohlížeč přešel k webu kontrolovanému útočníkem. V tomto scénáři útočník získá aplikaci do použití určitého vstupu uživatele jako součást volání NavigationManager.NavigateTo metody.

Tato doporučení platí i při vykreslování odkazů jako součást aplikace:

  • Pokud je to možné, používejte relativní odkazy.
  • Ověřte, zda jsou cíle absolutních odkazů platné, než je zařadíte do stránky.

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

Kontrolní seznam zabezpečení

Následující seznam bezpečnostních otázek není vyčerpávající:

  • Ověřte argumenty z událostí.
  • Ověřte vstupy a výsledky volání interoperability JS.
  • Nepoužívejte (nebo ověřte předem) uživatelský vstup pro volání interoperability .NET to JS.
  • Zabrání klientovi v přidělování nevázané velikosti paměti.
    • Data v rámci součásti.
    • DotNetObject odkazy vracené klientovi.
  • Ochrana proti více odesláním.
  • Zrušit dlouhotrvající operace, když je komponenta vyřazena.
  • Vyhněte se událostem, které vytváří velké objemy dat.
  • Vyhněte se použití vstupu uživatele jako součásti volání NavigationManager.NavigateTo a ověření vstupu uživatele pro adresy URL proti sadě povolených původních míst, pokud je to nenevyhnutelné.
  • Neprovádějte rozhodnutí o autorizaci na základě stavu uživatelského rozhraní, ale jenom ze stavu součásti.
  • Zvažte použití zásad zabezpečení obsahu (CSP) k ochraně před útoky XSS.
  • Zvažte použití CSP a možností X-frame – k ochraně před kliknutím na konektory.
  • Zajistěte, aby nastavení CORS byla vhodná při povolování CORS nebo explicitně zakázala CORS pro Blazor aplikace.
  • Otestujte, abyste zajistili, že omezení na straně serveru pro Blazor aplikaci poskytují přijatelné uživatelské prostředí bez nepřijatelných úrovní rizika.

Blazor Server aplikace přijímají stavový model zpracování dat, kde server a klient udržuje dlouhotrvající relaci. Trvalý stav je udržován okruhem, který může zahrnovat připojení, která jsou také potenciálně dlouhodobá.

Když uživatel navštíví Blazor Server web, Server vytvoří okruh v paměti serveru. Okruh indikuje prohlížeči, který obsah se má vykreslit a reagovat na události, například když uživatel vybere tlačítko v uživatelském rozhraní. Chcete-li provést tyto akce, okruh vyvolá funkce JavaScriptu v prohlížeči uživatele a metodách .NET na serveru. Tato obousměrná interakce založená na jazyce JavaScript je označována jako zprostředkovatel komunikace JavaScript (zprostředkovatel komunikace js).

Vzhledem k tomu, že interoperabilita JS probíhá přes Internet a klient používá vzdálený prohlížeč, Blazor Server aplikace sdílejí většinu otázek zabezpečení webových aplikací. Toto téma popisuje běžné hrozby pro Blazor Server aplikace a poskytuje pokyny pro zmírnění hrozeb zaměřené na internetové aplikace.

V omezených prostředích, jako jsou v podnikových sítích nebo intranetech, se jedná o některé pokyny k omezení rizik:

  • Neplatí v omezeném prostředí.
  • Nestojí za implementaci, protože bezpečnostní riziko je nízké v omezeném prostředí.

Blazor a sdílený stav

Blazor serverové aplikace živě v paměti serveru. To znamená, že v rámci stejného procesu je hostovaných více aplikací. Pro každou relaci aplikace spustí Blazor okruh s vlastním oborem kontejneru DI. To znamená, že vymezené služby jsou pro každou relaci Blazor jedinečné.

Upozornění

Aplikace ve stejném stavu sdílené složky serveru nedoporučujeme používat s využitím jednosměnné služby, pokud není přijata extrémní péče, protože to může představovat ohrožení zabezpečení, jako je například únik stavu uživatele napříč okruhy.

V aplikacích můžete používat stavové jednosměnné Blazor služby, pokud jsou pro něj speciálně navržené. Mezipaměť paměti můžete použít například jako jednu položku, protože vyžaduje klíč pro přístup k dané položce za předpokladu, že uživatelé nemají kontrolu nad tím, jaké klíče mezipaměti se používají.

Z bezpečnostních důvodů se navíc nesmí používat IHttpContextAccessor v Blazor aplikacích. Blazoraplikace běží mimo kontext kanálu ASP.NET Core. Není zaručeno, že bude k dispozici v rámci , ani není zaručeno, že bude uchovat kontext, HttpContext IHttpContextAccessor který aplikaci Blazor zahájil.

Doporučený způsob, jak předat stav požadavku do aplikace, je prostřednictvím parametrů kořenové komponentě při Blazor počátečním vykreslování aplikace:

  • Definujte třídu se všemi daty, která chcete do Blazor aplikace předat.
  • Naplňte tato data ze Razor stránky pomocí možnosti dostupné v tomto HttpContext okamžiku.
  • Předejte data do Blazor aplikace jako parametr do kořenové komponenty (aplikace).
  • V kořenové komponentě definujte parametr, který bude obsahovat data předaná do aplikace.
  • Použití dat specifických pro uživatele v rámci aplikace Nebo můžete tato data zkopírovat do vymezené služby v rámci , aby je bylo možné OnInitializedAsync používat v celé aplikaci.

Další informace a příklad kódu najdete v tématu Blazor ServerASP.NET Core další scénáře zabezpečení .

Vyčerpání prostředků

K vyčerpání prostředků může dojít, když klient komunikuje se serverem a způsobí, že Server spotřebovává nadměrné prostředky. Nadměrné využití prostředků primárně ovlivňuje:

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

Prostředky, které jsou externí pro Blazor rámec, jako jsou databáze a obslužné rutiny souborů (slouží ke čtení a zápisu souborů), můžou taky vyčerpat prostředky. Další informace naleznete v tématu ASP.NET Core Osvědčené postupy z oblasti výkonu.

Procesor

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

Představte si třeba Blazor Server aplikaci, která vypočítá Fibonnacci číslo. Fibonnacci číslo je vytvořeno z Fibonnacci sekvence, kde každé číslo v sekvenci je součet dvou předcházejících čísel. Množství práce potřebné k dosažení odpovědi závisí na délce sekvence a na velikosti počáteční hodnoty. Pokud aplikace neumístí omezení na požadavky klienta, mohou výpočty náročné na procesor poznamenat čas procesoru a snížit výkon dalších úloh. Nadměrné využití prostředků je zabezpečení, které má vliv na dostupnost.

Vyčerpání výkonu procesoru je obavou pro všechny veřejné aplikace. V běžných webových aplikacích jsou požadavky a připojení vyprší jako ochrana, ale Blazor Server aplikace neposkytují stejné záruky. Blazor Server aplikace musí před provedením práce náročné na procesor zahrnovat vhodné kontroly a omezení.

Memory (Paměť)

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

Představte si například Blazor aplikaci na straně serveru s komponentou, která přijímá a zobrazuje seznam položek. Pokud aplikace neumisťuje omezení počtu povolených položek nebo počtu položek vykreslených zpět klientovi, zpracování a vykreslování náročné na paměť může dominovat paměti serveru až do bodu, kdy dojde ke snížení výkonu Blazor serveru. Server může selha nebo pomalu do bodu, kdy se zdá, že havaroval.

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

  • Položky ve List<MyItem> vlastnosti nebo poli používají paměť serveru. Pokud aplikace povolí, aby se seznam položek rozrůstal bez vázaného stavu, existuje riziko, že serveru došla paměť. Při vyšetřené paměti se ukončí aktuální relace (chyba) a u všech souběžných relací v této instanci serveru dojde k výjimce typu "mimo paměť". Aby k tomuto scénáři nedocházet, musí aplikace používat datovou strukturu, která pro souběžné uživatele omezuje položky.
  • Pokud se schéma stránkování pro vykreslování používá, server používá další paměť pro objekty, které nejsou viditelné v uživatelském rozhraní. Bez omezení počtu položek může nároky na paměť vyčerpanou 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í se jenom prvních 100 až 1 000 položek a uživatel musí zadat kritéria vyhledávání, aby našel položky nad rámec zobrazených položek.
    • V případě pokročilejšího scénáře vykreslování implementujte seznamy nebo mřížky, které podporují virtualizaci. Pomocí virtualizace vykreslí seznamy pouze 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í jenom položky potřebné k zobrazení. Položky, které aktuálně nejsou potřeba k zobrazení, se mohou nachovat v sekundárním úložišti, což je ideální přístup. Nezobrazované položky lze také uchovat v paměti, což je méně ideální.

Blazor ServerAplikace nabízejí podobný programovací model jako jiné architektury uživatelského rozhraní pro stavové aplikace, jako je WPF, 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 tohoto jednotlivého klienta. Například aplikace běží zcela na klientovi a Blazor WebAssembly používá pouze prostředky paměti klienta. V tomto scénáři paměť spotřebovaná aplikací patří serveru a sdílí se mezi klienty Blazor Server v instanci serveru.

Požadavky na paměť na straně serveru jsou důležité pro všechny Blazor Server aplikace. Většina webových aplikací je ale bez stavu a při vrácení odpovědi se uvolní paměť použitá při zpracování požadavku. Obecně neumožňovat klientům přidělit nevázané množství paměti jako v jakékoli jiné serverové aplikaci, která uchová klientská připojení. Paměť spotřebovaná aplikací trvá déle než Blazor Server jeden požadavek.

Poznámka

Během vývoje je možné použít profiler nebo zachytit trasování k vyhodnocení požadavků klientů na paměť. Profiler nebo trasování nezachytí paměť přidělenou konkrétnímu klientovi. Pokud chcete zaznamenat využití paměti konkrétního klienta během vývoje, zachyťte výpis paměti a prozkoumejte poptávku po paměti všech objektů rootovaných v okruhu uživatele.

Připojení klientů

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

Blazor klienti vytvoří jedno připojení pro každou relaci a připojení nechte otevřené po dobu, po které je otevřené okno prohlížeče. Požadavky na server údržby všech připojení nejsou specifické pro Blazor aplikace. Vzhledem k trvalé povaze připojení a stavové povaze aplikací je vyčerpání připojení pro dostupnost Blazor Server aplikace větší riziko.

Ve výchozím nastavení neexistuje žádné omezení počtu připojení na uživatele pro Blazor Server aplikaci. Pokud aplikace vyžaduje limit připojení, využijte jeden nebo několik následujících přístupů:

  • Vyžadovat ověřování, které přirozeně omezuje možnost neautorizovaných uživatelů připojit se k aplikaci. Aby byl tento scénář efektivní, je nutné uživatelům zabránit ve zřizování nových uživatelů podle chví.
  • Omezte počet připojení na uživatele. K omezení připojení můžete použít následující přístupy. Procvičte si přístup k aplikaci oprávněným uživatelům (například při nastavení limitu připojení na základě IP adresy klienta).

    • Na úrovni aplikace:

      • Rozšiřitelnost směrování koncových bodů.
      • Vyžadovat ověření pro připojení k aplikaci a sledování aktivních relací na uživatele.
      • Odmítnout nové relace při dosažení limitu.
      • Proxy připojení WebSocket k aplikaci prostřednictvím proxy serveru, jako je služba Azure, SignalR která multiplexuje připojení z klientů do aplikace. To poskytuje aplikaci větší kapacitu připojení, než může vytvořit jeden klient, což klientovi brání v vyčerpání připojení k serveru.

    • Na úrovni serveru: Před aplikací použijte proxy server nebo bránu.

      Poznámka

      Přestože aplikace podporují dlouhé dotazování, doporučuje se Blazor Server přenosový protokol WebSocket.

Útoky DoS (Denial of Service)

K útokům DoS (Denial of Service) patří klient, který způsobuje, že server vyčerpá jeden nebo více prostředků, takže aplikace není dostupná. Blazor Serveraplikace zahrnují výchozí limity a spoléhají na jiné ASP.NET Core a omezení pro ochranu před útoky SignalR DoS nastavenými na CircuitOptions :

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

Interakce s prohlížečem (klient)

Klient komunikuje se serverem prostřednictvím dispečinku událostí zprostředkovatele komunikace JS a dokončení vykreslování. Komunikace zprostředkovatele komunikace JS mezi JavaScriptem a .NET prochází oběma způsoby:

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

Funkce Jazyka JavaScript vyvolané z .NET

Pro volání z metod .NET do JavaScriptu:

  • Všechna volání mají konfigurovatelný časový limit, po kterém selžou a vrátí OperationCanceledException volajícímu .
  • 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 je vyvolána a je vytvořen výsledek nebo chyba. Klient se zlými úmysly se může pokusit:
    • Vrácením chyby z funkce JavaScriptu způsobíte problém v aplikaci.
    • Indukuje nezamýšlené chování na serveru vrácením neočekávaného výsledku z funkce JavaScriptu.

Před předchozími scénáři se vezměte vhod následující opatření:

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

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

Nevěřte volání metodám .NET z JavaScriptu. Když je metoda .NET zpřístupněna v JavaScriptu, zvažte, jak je vyvolána metoda .NET:

  • Zacházet s jakoukoli metodou .NET vystavenou JavaScriptu jako s veřejným koncovým bodem aplikace.
    • Ověřte vstup.
      • Ujistěte se, že hodnoty jsou v očekávaném rozsahu.
      • Ujistěte se, že má uživatel oprávnění k provedení požadované akce.
    • Při vyvolání metody .NET přidělujte nadměrné množství prostředků. Například proveďte kontroly a umiste omezení využití procesoru a paměti.
    • Vezměte v úvahu, že statické a instance metod mohou být vystaveny klientům JavaScriptu. Vyhněte se sdílení stavu mezi relacemi, pokud návrh nevyvolá stav sdílení s příslušnými omezeními.
      • Například metody vystavené prostřednictvím objektů, které byly původně vytvořeny prostřednictvím injektáže závislostí (DI), by objekty měly být DotNetReference registrovány jako objekty s vymezeným oborem. To platí pro všechny služby diod, Blazor Server které aplikace používá.
      • U statických metod se vyhněte vytvoření stavu, který nelze vymezit na klienta, pokud aplikace explicitně neschová stav mezi všemi uživateli v instanci serveru.
    • Vyhněte se předávání uživatelem zadaných dat v parametrech voláním JavaScriptu. Pokud je předávání dat v parametrech naprosto nezbytné, zajistěte, aby kód JavaScriptu zpracuje předávání dat bez zavedení ohrožení zabezpečení skriptování mezi weby (XSS). Například nezapisování uživatelem zadaných dat do objektu model DOM (Document Object Model) (DOM) nastavením innerHTML vlastnosti elementu. Zvažte použití zásad zabezpečení obsahu (CSP) k zakázání a dalších nebezpečných primitiv eval JavaScriptu.
  • Vyhněte se implementaci vlastního volání rozhraní .NET nad implementaci odesílání rozhraní. Vystavení metod .NET prohlížeči je pokročilý scénář, který se nedoporučuje pro obecný Blazor vývoj.

Události

Události poskytují vstupní bod do Blazor Server aplikace. Stejná pravidla pro ochranu koncových bodů ve webových aplikacích platí pro zpracování událostí v Blazor Server aplikacích. Klient se zlými úmysly 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í v rámci možností, které aplikace prezentuje klientovi.
  • <input>Může odeslat veškerá textová data na server a obejít ověřování na straně klienta.

Aplikace musí ověřit data pro všechny události, které aplikace zpracovává. Blazor Komponenty formulářů rozhraní provádějí základní ověření. Pokud aplikace používá vlastní součásti formulářů, je nutné napsat vlastní kód pro ověření dat události podle potřeby.

Blazor Server události jsou asynchronní, takže je možné odeslat do serveru více událostí, než aplikace začne reagovat tím, že vygeneruje nové vykreslování. To má vliv na některé zabezpečení, které je potřeba vzít v úvahu. Omezení akcí klienta v aplikaci musí být provedeno uvnitř obslužných rutin událostí a nemusí být závislé na aktuálním stavu zobrazení.

Vezměte v úvahu komponentu čítače, která by uživateli umožnila zvýšit hodnotu čítače maximálně třikrát. Tlačítko pro zvýšení čítače je podmíněně na základě hodnoty 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é vykreslování této součásti. Výsledkem je, že count uživatel může tento krok zvýšit za třikrát , protože toto tlačítko není v uživatelském rozhraní k dispozici 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++;
        }
    }
}

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

Ochrana proti více odesláním

Pokud zpětné volání události vyvolá asynchronně běžící operaci, jako je například načítání dat z externí služby nebo databáze, zvažte použití ochrany. Ochrana může uživatelům zabránit ve zařazení více operací do fronty, zatímco operace probíhá pomocí vizuální zpětné vazby. Následující kód komponenty nastaví isLoading na, true Když GetForecastAsync získá data ze serveru. isLoadingV nástroji je true tlačítko neaktivní v uživatelském rozhraní:

@page "/fetchdata"
@using BlazorServerSample.Data
@inject WeatherForecastService ForecastService

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

@code {
    private bool isLoading;
    private WeatherForecast[] forecasts;

    private async Task UpdateForecasts()
    {
        if (!isLoading)
        {
            isLoading = true;
            forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
            isLoading = false;
        }
    }
}

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

Zrušit počáteční a vyhnout se použití po vyřazení

Kromě používání ochrany, jak je popsáno v části Guard proti více odesláních , zvažte použití nástroje CancellationToken ke zrušení dlouhotrvajících operací při likvidaci komponenty. Tento přístup má výhodu při zamezení používání funkcí po Dispose v součástech:

@implements IDisposable

...

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

    private async Task UpdateForecasts()
    {
        ...

        forecasts = await ForecastService.GetForecastAsync(DateTime.Now, 
            TokenSource.Token);

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

        ...
    }

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

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

Některé události modelu DOM, například oninput nebo onscroll , mohou vytvořit velké množství dat. Nepoužívejte tyto události v Blazor serverových aplikacích.

Další pokyny k zabezpečení

doprovodné materiály k zabezpečení aplikací ASP.NET Core platí pro Blazor Server aplikace a jsou uvedené v následujících oddílech:

Protokolování a citlivá data

Interakce interoperability v JS mezi klientem a serverem se zaznamenávají v protokolech serveru s ILogger instancemi. Blazor Nepoužívejte protokolování citlivých informací, jako jsou například skutečné události nebo vstupy a výstupy interoperability JS.

Když na serveru dojde k chybě, rozhraní upozorní klienta a rozhlasí relaci. Ve výchozím nastavení klient obdrží obecnou chybovou zprávu, která se může 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 obsahují takové informace. Pro účely vývoje lze klientovi zpřístupnit citlivé informace o chybách tím, že povolíte podrobné chyby.

Upozornění

Odhalení informací o chybách klientům na internetu je bezpečnostní riziko, které by se mělo vždy vyhnout.

Ochrana informací při přenosu pomocí protokolu HTTPS

Blazor Server používá se SignalR pro komunikaci mezi klientem a serverem. Blazor Server běžně používá přenos, který SignalR vyjednává, což jsou typicky objekty WebSockets.

Blazor Server nezajišťuje integritu a důvěrnost dat odesílaných mezi serverem a klientem. Vždy používat protokol HTTPS.

Skriptování mezi weby (XSS)

Skriptování mezi weby (XSS) umožňuje neoprávněné straně spustit libovolnou logiku v kontextu prohlížeče. Ohrožená aplikace by mohla spustit libovolný kód v klientovi. Chybu zabezpečení lze použít k potenciálnímu provedení určitého množství škodlivých akcí proti serveru:

  • Odeslání falešných/neplatných událostí na server.
  • Odeslání neúspěšných nebo neplatných dokončení vykreslování.
  • Vyhněte se odesílání doplňování vykreslování.
  • Odešlete volání Interop z JavaScriptu do .NET.
  • Upravte odpověď volání Interop z rozhraní .NET na JavaScript.
  • Vyhněte se odesílání výsledků interoperability .NET to JS.

Blazor ServerRozhraní používá kroky k ochraně před některými předchozími hrozbami:

  • Ukončí vytváření nových aktualizací uživatelského rozhraní, pokud klient nepotvrzující dávky vykreslování. Nakonfigurováno pomocí CircuitOptions.MaxBufferedUnacknowledgedRenderBatches .
  • Vyprší časový limit volání rozhraní .NET do JavaScriptu po jedné minutě, aniž by byla obdržena odpověď od klienta. Nakonfigurováno pomocí CircuitOptions.JSInteropDefaultCallTimeout .
  • Provede základní ověření na všech vstupech přicházejících z prohlížeče během interoperability JS:
    • Odkazy .NET jsou platné a typ očekávaný metodou .NET.
    • Data nejsou poškozena.
    • V datové části je uveden správný počet argumentů pro metodu.
    • Argumenty nebo výsledky 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 pro událost lze deserializovat.
    • K události je přidružená obslužná rutina události.

Kromě ochrany, kterou implementuje rozhraní, musí být aplikace kódována vývojářem k ochraně před hrozbami a provádět příslušné akce:

  • Při zpracování událostí vždy ověřovat data.
  • Po přijetí neplatných dat proveďte příslušnou akci:
    • Ignorujte data a vraťte se. Tím umožníte, aby aplikace pokračovala v zpracování požadavků.
    • Pokud aplikace zjistí, že vstup je illegitimate a nemohl být vytvořen legitimním klientem, vyvolejte výjimku. Došlo k výjimce při odtrhlině okruhu a ukončení relace.
  • Nedůvěra na chybovou zprávu poskytovanou dokončováním dávek vykreslování zahrnutými v protokolech. Klient poskytuje chybu a nemůže být obecně důvěryhodný, protože může dojít k ohrožení zabezpečení klienta.
  • Nedůvěřovat vstupu volání interoperability JS v obou směrech mezi metodami jazyka JavaScript a .NET.
  • 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 mohla existovat ohrožení zabezpečení XSS, musí aplikace na vykreslené stránce zahrnovat vstup uživatele. Blazor Server komponenty spustí krok v čase kompilace, kde je kód v .razor souboru transformován do logiky jazyka C#. V době běhu vytvoří logika jazyka C# strom vykreslování , který popisuje prvky, text a podřízené komponenty. To se aplikuje na DOM v prohlížeči pomocí sekvence instrukcí JavaScriptu (nebo je v případě předvykreslování serializovaná na HTML):

  • Uživatelský vstup vykreslený pomocí normální Razor syntaxe (například @someStringValue ) nevystavuje zranitelnost XSS, protože Razor syntaxe je přidána do modelu DOM prostřednictvím příkazů, které mohou zapisovat pouze text. I v případě, že hodnota obsahuje kód HTML, hodnota se zobrazí jako statický text. Při předběžné vykreslování je výstupem kódovaný HTML, který také zobrazuje obsah jako statický text.
  • Značky skriptu nejsou povoleny a neměly by být zahrnuty do stromu vykreslování součásti aplikace. Je-li značka skriptu obsažena v kódu komponenty, je vygenerována chyba při kompilaci.
  • 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. Můžete například použít builder.AddContent(0, someUserSuppliedString) a nikoli builder.AddMarkupContent(0, someUserSuppliedString) , protože by to mohlo vytvořit chybu zabezpečení XSS.

Jako součást ochrany proti útokům XSS zvažte implementaci zmírnění XSS, jako je například zásada zabezpečení obsahu (CSP).

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

Ochrana mezi zdroji

Útoky mezi zdroji zahrnují klienta z jiného zdroje, který provádí akci na serveru. Škodlivá akce je obvykle požadavek GET nebo POST formuláře (pro padělání žádostí mezi weby, CSRF), ale otevírání škodlivého WebSocket je také možné. Blazor Server aplikace nabízí stejné záruky jako všechny ostatní SignalR aplikace používající protokol rozbočovače:

  • Blazor Server k aplikacím se dá přihlédnout z více zdrojů, pokud se nepřijmou další opatření, která jim zabrání. Pokud chcete zakázat přístup pro více zdrojů, buď zakažte CORS v koncovém bodu přidáním middlewaru CORS do kanálu a přidáním DisableCorsAttribute do Blazor metadat koncového bodu, nebo omezte sadu povolených SignalR zdrojů konfigurací pro sdílení prostředků mezi zdroji.
  • Pokud je CORS povolená, můžou se při ochraně aplikace v závislosti na konfiguraci CORS vyžadovat další kroky. Pokud je CORS povolena globálně, může být CORS pro centrum zakázaná Blazor Server přidáním DisableCorsAttribute metadat do metadat koncového bodu po volání do MapBlazorHub Tvůrce tras koncových bodů.

Další informace naleznete v tématu Prevence útoků XSRF/CSRF (Cross-Site Request Forgery) v ASP.NET Core.

Kliknutí – zdířka

Kliknutí na zásuvky zahrnuje vykreslování lokality jako <iframe> v rámci lokality z jiného zdroje, aby uživatel mohl v rámci útoku přimět uživatele k provádění akcí na webu.

K ochraně aplikace před vykreslováním v nástroji <iframe> použijte zásady zabezpečení obsahu (CSP) a X-Frame-Options hlavičku. Další informace najdete v tématu MDN web Docs: X-frame-Options.

Otevřít přesměrování

Při Blazor Server spuštění relace aplikace provede Server základní ověření adres URL odesílaných v rámci zahájení relace. Architektura kontroluje, zda je základní adresa URL nadřazena aktuální adrese URL před vytvořením okruhu. Rozhraní neprovádí žádné další kontroly.

Když uživatel vybere odkaz na klientovi, adresa URL odkazu se pošle na server, který určuje, jakou akci chcete provést. Aplikace může například provádět navigaci na straně klienta nebo naznačit prohlížeči, aby přešel do nového umístění.

Komponenty mohou také aktivovat požadavky na navigaci programově prostřednictvím použití NavigationManager . V takových scénářích může aplikace provést navigaci na straně klienta nebo v prohlížeči označit, že se má přejít na nové umístění.

Komponenty musí:

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

V opačném případě může uživatel se zlými úmysly vynutit, aby prohlížeč přešel k webu kontrolovanému útočníkem. V tomto scénáři útočník získá aplikaci do použití určitého vstupu uživatele jako součást volání NavigationManager.NavigateTo metody.

Tato doporučení platí i při vykreslování odkazů jako součást aplikace:

  • Pokud je to možné, používejte relativní odkazy.
  • Ověřte, zda jsou cíle absolutních odkazů platné, než je zařadíte do stránky.

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

Kontrolní seznam zabezpečení

Následující seznam bezpečnostních otázek není vyčerpávající:

  • Ověřte argumenty z událostí.
  • Ověřte vstupy a výsledky volání interoperability JS.
  • Nepoužívejte (nebo ověřte předem) uživatelský vstup pro volání interoperability .NET to JS.
  • Zabrání klientovi v přidělování nevázané velikosti paměti.
    • Data v rámci součásti.
    • DotNetObject odkazy vracené klientovi.
  • Ochrana proti více odesláním.
  • Zrušit dlouhotrvající operace, když je komponenta vyřazena.
  • Vyhněte se událostem, které vytváří velké objemy dat.
  • Vyhněte se použití vstupu uživatele jako součásti volání NavigationManager.NavigateTo a ověření vstupu uživatele pro adresy URL proti sadě povolených původních míst, pokud je to nenevyhnutelné.
  • Neprovádějte rozhodnutí o autorizaci na základě stavu uživatelského rozhraní, ale jenom ze stavu součásti.
  • Zvažte použití zásad zabezpečení obsahu (CSP) k ochraně před útoky XSS.
  • Zvažte použití CSP a možností X-frame – k ochraně před kliknutím na konektory.
  • Zajistěte, aby nastavení CORS byla vhodná při povolování CORS nebo explicitně zakázala CORS pro Blazor aplikace.
  • Otestujte, abyste zajistili, že omezení na straně serveru pro Blazor aplikaci poskytují přijatelné uživatelské prostředí bez nepřijatelných úrovní rizika.