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, například v podnikových sítích nebo intranetech, některé pokyny pro zmírnění rizik:

• Nevztahuje se v omezeném prostředí.
• Náklady na implementaci stojí za to, protože riziko zabezpečení je nízké v omezeném prostředí.

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

Komprese může aplikaci vystavit útokům na straně kanálu proti šifrování protokolu TLS připojení, jako CRIME jsou útoky a BREACH útoky. Tyto typy útoků vyžadují, aby cyberattacker:

• Vynutit, aby prohlížeč vydá žádosti s datovou částí, která řídí cyberattacker na ohrožený web prostřednictvím publikování formuláře mezi weby nebo vložením 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 odrážet datovou část z cyberattackeru, například napsáním cesty nebo řetězce dotazu do odpovědi. Pomocí délky odpovědi může cyberattacker "hádat" jakékoli informace o odpovědi a obejít š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 konfiguraci Blazor komprese automaticky zablokuje vložení aplikace do prvku iframe, který blokuje počáteční (nekomprimovanou) odpověď ze serveru z vykreslení a zabraňuje tomu, aby se připojení WebSocket vůbec zahájilo.

  • 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 obtížné dosáhnout cyberattackeru. Není však nemožné pro cyberattacker, takže je třeba se vyhnout vykreslování citlivých informací spolu s externími informacemi, které může kyberattacker 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

Aplikace na straně Blazor serveru jsou živé v paměti serveru a několik relací aplikací se hostuje ve stejném procesu. Pro každou relaci Blazor aplikace spustí okruh s vlastním oborem kontejneru injektáže závislostí, takže služby s vymezeným oborem jsou jedinečné pro každou Blazor relaci.

Upozorňující

Nedoporučujeme aplikace ve stejném stavu sdílení serveru, které používají singletonové služby, pokud se o to nezajímá extrémní péče, protože to může představovat ohrožení zabezpečení, jako je únik stavu uživatele napříč okruhy.

Stavové jednoúčelové služby můžete v Blazor aplikacích používat, pokud jsou speciálně navržené. 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 v Razor součástech

IHttpContextAccessor musí se vyhnout interaktivnímu vykreslování, protože není k dispozici platný HttpContext .

IHttpContextAccessor lze použít pro součásti, které jsou staticky vykresleny na serveru. Pokud je to ale možné, doporučujeme ho vyhnout.

HttpContext lze použít jako kaskádový parametr pouze v staticky vykreslovaných kořenových komponentách pro obecné úlohy, jako je kontrola a úprava hlaviček nebo jiných vlastností v komponentě App (Components/App.razor). Hodnota je vždy null určená pro interaktivní vykreslování.

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

Pro scénáře, ve HttpContext kterých se vyžaduje v interaktivních komponentách, doporučujeme tok dat přes trvalý stav komponenty ze serveru. Další informace najdete v tématu ASP.NET základní serverové a Blazor Web App další scénáře zabezpečení.

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:

• PROCESOR
• 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 ASP.NET Základních osvědčených postupů.

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é záruky. 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ů vynutí, aby server spotřebovávalo 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 může dojít k chybovému ukončení nebo zpomalení v bodě, kdy se zdá, že došlo k chybě.

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. Nezohraněné položky lze také uchovávat v paměti, což je méně ideální.

Poznámka:

Blazor má integrovanou podporu virtualizace. Další informace najdete v tématu Razor komponent Core.

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 klientům přidělit nevázanou velikost paměti jako v jakékoli jiné aplikaci na straně serveru, která zachovává připojení klientů. Paměť spotřebovaná aplikací na straně Blazor serveru trvá delší dobu než jeden požadavek.

Poznámka:

Během vývoje lze profiler použít 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 navazuje jedno připojení na relaci a připojení zůstane otevřené, dokud je otevřené okno prohlížeče. 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žadovat ověření pro připojení k aplikaci a sledování aktivních relací na uživatele.
    • Odmítněte nové relace při dosažení limitu.
    • Proxy připojení WebSocket k aplikaci prostřednictvím použití proxy serveru, jako SignalR Azure, která multiplexuje připojení z klientů k aplikaci. To poskytuje aplikaci s větší kapacitou připojení než jeden klient může navázat, což klientovi brání v vyčerpání připojení k serveru.
  • Úroveň serveru
    • Před aplikací použijte proxy server nebo bránu. Například Aplikace Azure lication Gateway je nástroj pro vyrovnávání zatížení webového provozu (vrstva OSI 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.
    • I když se pro aplikace podporuje Blazor dlouhé dotazování, které by umožnilo přijetí služby Azure Front Door, webSockets je doporučený přenosový protokol. Od září 2024 služba Azure Front Door nepodporuje webSockety, ale podporuje webSockety. Další informace najdete v tématu Podpora připojení WebSocket ve službě Azure Front Door.

Útoky na dostupnost služby (DoS)

Útoky DoS (Denial of Service) zahrnují klienta, který způsobuje vyčerpání jednoho nebo více prostředků, aby aplikace byla nedostupná. Blazor aplikace zahrnují výchozí limity a spoléhají na další ASP.NET Core a SignalR limity nastavené CircuitOptions na 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í metod .NET do JavaScriptu:

• Všechny vyvolání mají konfigurovatelný časový limit, po kterém selžou OperationCanceledException a vrátí volajícímu.
  • Pro volání (CircuitOptions.JSInteropDefaultCallTimeout) 1 minutu existuje výchozí časový limit. 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 zrušení lze poskytnout k řízení zrušení na základě volání. Pokud je k dispozici token zrušení, závisí na výchozím časovém limitu volání, pokud je k dispozici časový limit volání 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 volání zprostředkovatele komunikace v příkazech try-catch , aby se zohlednily chyby, ke kterým může dojít při vyvolání. Další informace najdete v tématu 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 rozsazích.
    • Ujistěte se, že má uživatel oprávnění k provedení požadované akce.
  • Nevydělujte nadměrné množství prostředků jako součást 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 nevyvolá stav sdílení s příslušný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 navazování stavu, který nelze nastavit na klienta, pokud aplikace explicitně nesdílí stav podle návrhu napříč 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 naleznete v tématu Vynucení zásad zabezpečení obsahu pro ASP.NET Core Blazor.
• 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 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 klienta <select> by mohla odeslat hodnotu, která není v možnostech, které aplikace zobrazila klientovi.
• Textová <input> data by mohla odeslat na server a obejít 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 je podmíněně založeno 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 uživatel může zvýšit třikrát, protože tlačítko není odebráno uživatelským rozhraním 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 před více dispečery

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, zatímco operace probíhá s vizuální zpětnou vazbou. Následující kód komponenty se nastaví isLoading na dobutrue, kdy DataService.GetDataAsync získá data ze serveru. I když isLoading ano true, tlačítko je v uživatelském rozhraní zakázané:

<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;
        }
    }
}

Vzor ochrany předvázaný v předchozím příkladu funguje, pokud se operace na pozadí provádí 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, jak se vyhnout použití po vyřazení součástí:

@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 mezi zdroji
• Klikni a zvednutí
• 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.

Upozorňující

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:

• Odešle falešné nebo neplatné události na server.
• Odeslání selže nebo neplatné dokončení vykreslení.
• Vyhněte se odesílání dokončení vykreslování.
• Odesílání volání z JavaScriptu do .NET
• Upravte odpověď volání z .NET na JavaScript.
• Vyhněte se odesílání .NET do JS výsledků spolupráce.

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.
• Vyprší časový limit volání .NET do JavaScriptu po jedné minutě bez přijetí 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 zprostředkovatele komunikace:
  • Odkazy na .NET jsou platné a typ očekávaný 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é vykreslením dávkových dokončování zahrnutých 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 volání zprostředkovatele komunikace 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 ohrožení zabezpečení XSS existovalo, musí aplikace na vykreslené stránce začlenit uživatelský vstup. 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) nezpřístupňuje ohrožení zabezpečení XSS, @someStringValueprotož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 naleznete v tématu Vynucení zásad zabezpečení obsahu pro ASP.NET Core Blazor.

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 nabízejí stejné záruky, že každá jiná SignalR aplikace využívající nabídku protokolu centra:

• K aplikacím je možné přistupovat mezi zdroji, pokud nejsou přijata další opatření, aby se zabránilo jejich vzniku. Pokud chcete zakázat přístup mezi zdroji, zakažte CORS v koncovém bodu přidáním middlewaru CORS do kanálu a přidáním DisableCorsAttribute metadat Blazor koncového bodu nebo omezením sady povolených zdrojů konfigurací SignalR pro sdílení prostředků mezi zdroji. 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í

Klikni a zvednutí zahrnuje vykreslení webu jako <iframe> uvnitř webu z jiného původu, aby mohl uživatele oklamat, aby provedl akce na webu, který je napadený.

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 .

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. Rozhraní 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 kyberattacker chytá aplikaci tak, aby v rámci vyvolání NavigationManager.NavigateTo metody používala určitý 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 cílů na stránku ověřte, že jsou absolutní cíle odkazů 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í zprostředkovatele komunikace.
• 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 v rámci komponenty.
  • DotNetObjectReference objekty vrácené klientovi.
• Chraňte před více dispečery.
• Zrušte dlouhotrvající operace, když je komponenta uvolně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 s sadou povolených původů, pokud je to neuskutečnitelné.
• 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. Další informace naleznete v tématu Vynucení zásad zabezpečení obsahu pro ASP.NET Core Blazor.
• Zvažte použití CSP a možností X-Frame-Options k ochraně před klikni a konektorem.
• Při povolování CORS nebo explicitně zakažte CORS pro Blazor aplikace, ujistěte se, že je nastavení CORS vhodné.
• Otestujte, abyste zajistili, že limity na straně serveru pro Blazor aplikaci poskytují přijatelné uživatelské prostředí bez nepřijatelné úrovně rizika.