Fenyegetéscsökkentési útmutató ASP.NET Core Blazor interaktív kiszolgálóoldali rendereléshez

Ez a cikk azt ismerteti, hogyan háríthatja el a biztonsági fenyegetéseket az interaktív kiszolgálóoldali Blazor.

Az alkalmazások állapotalapú adatfeldolgozási modellt vezetnek be, amelyben a kiszolgáló és az ügyfél hosszú életű kapcsolatot tart fenn. Az állandó állapotot egy kapcsolatcsoport tartja karban, amely kiterjedhet a potenciálisan hosszú élettartamú kapcsolatokra is.

Amikor egy felhasználó meglátogat egy webhelyet, a kiszolgáló létrehoz egy körfolyamatot a memóriájában. A kapcsolatcsoport jelzi a böngészőnek, hogy milyen tartalmat jelenítsen meg, és reagáljon az eseményekre, például amikor a felhasználó kiválaszt egy gombot a felhasználói felületen. Ezeknek a műveleteknek a végrehajtásához egy kapcsolatcsoport JavaScript-függvényeket hív meg a felhasználó böngészőjében és .NET-metódusokat a kiszolgálón. Ezt a kétirányú JavaScript-alapú interakciót JavaScript interop (JS interop)nevezik.

Mivel JS interop az interneten keresztül történik, és az ügyfél távoli böngészőt használ, az alkalmazások a legtöbb webalkalmazással kapcsolatos biztonsági problémát megosztják. Ez a témakör a kiszolgálóoldali Blazor-alkalmazások gyakori fenyegetéseit ismerteti, és az internetes alkalmazásokra összpontosító fenyegetéscsökkentési útmutatást nyújt.

Korlátozott környezetekben, például vállalati hálózatokon vagy intraneteken belül, a kockázatcsökkentési útmutatók némelyike a következők:

• A korlátozott környezetben nem alkalmazható.
• Nem éri meg a megvalósítás költségeit, mert a biztonsági kockázat alacsony korlátozott környezetben.

Interaktív kiszolgálóösszetevők, amelyeken engedélyezve van a WebSocket tömörítése

A tömörítés kiszolgáltatottá teheti az alkalmazást a kapcsolat TLS-titkosítása elleni oldalcsatornás támadásokkal szemben, mint például a CRIME és a BREACH támadások. Az ilyen típusú támadások megkövetelik, hogy a kibertámadás:

• Kényszerítse a böngészőt arra, hogy egy hasznos adattal kapcsolatos kéréseket küldjön a cyberattacker-vezérlőknek egy sebezhető helyre a helyek közötti űrlapok közzétételével vagy a webhely beágyazásával egy másik webhely iframe-jeibe.
• Figyelje meg a hálózaton keresztüli tömörített és titkosított válasz hosszát.

Ahhoz, hogy az alkalmazás sebezhető legyen, a válasznak tükröznie kell a kibertámadó által küldött kódot, például az elérési út vagy a lekérdezési karakterlánc beleírásával a válaszba. A válasz hosszát használva a kiberbűnöző bármilyen információt "találgathat" a válaszról, megkerülve a kapcsolat titkosítását.

Általánosságban elmondható, hogy Blazor alkalmazások a megfelelő biztonsági intézkedésekkel engedélyezhetik a WebSocket-kapcsolaton keresztüli tömörítést:

• Az alkalmazás sebezhető lehet, ha a kérésből származó tartalmat (például az elérési utat vagy a lekérdezési sztringet) egy kibertámadás befolyásolhatja, és reprodukálja az oldal HTML-fájljába, vagy más módon a válasz részét képezi.

• Blazor automatikusan alkalmazza a következő biztonsági intézkedéseket:

  • Ha a tömörítés konfigurálva van, Blazor automatikusan letiltja az alkalmazás iframe-be való beágyazását, ami megakadályozza a kiszolgáló kezdeti (tömörítetlen) válaszának renderelését, és megakadályozza, hogy a WebSocket-kapcsolat soha ne induljon el.

  • Az alkalmazás iframe-be való beágyazására vonatkozó korlátozás enyhíthető. A korlátozás enyhítése azonban támadásnak teszi ki az alkalmazást, ha a beágyazási dokumentum egy helyek közötti szkriptelési biztonsági résen keresztül sérül meg, mivel így a kiberbűnöző végrehajthatja a támadást.

• Általában az ilyen típusú támadáshoz az alkalmazásnak ismételten reprodukálnia kell a válaszokat, hogy a kibertámadás kitalálhassa a választ. Tekintettel arra, hogy Blazor hogyan jelenik meg (egyszer rendereli, majd csak a módosított elemekhez állítja elő a tartalom diffs-eit), ezt a kibertámadásnak nehéz elérnie. A kiberbűnözők számára azonban nem lehetetlen, ezért ügyelni kell arra, hogy a kibertámadás által manipulálható külső információk mellett ne lehessen bizalmas információkat megjeleníteni. Néhány példa erre:

  • A személyazonosításra alkalmas adatok (PII) megjelenítése a lapon egy másik felhasználó által hozzáadott adatbázisadatok renderelésével egyidejűleg.

  • Személyes azonosításra alkalmas információk megjelenítése a lapon, ugyanabban az időben, amikor egy másik felhasználótól érkező adatok érkeznek a JS interop vagy egy helyi egyszeri szolgáltatáson keresztül a szerveren.

Általában azt javasoljuk, hogy kerülje az olyan összetevők renderelését, amelyek bizalmas információkat tartalmaznak olyan összetevők mellett, amelyek ugyanazon renderelési köteg részeként nem megbízható forrásokból származó adatokat képesek renderelni. A nem megbízható források közé tartoznak az útvonalparaméterek, a lekérdezési sztringek, az JS interopból származó adatok, valamint a külső felhasználók által szabályozható egyéb adatforrások (adatbázisok, külső szolgáltatások).

Megosztott állapot

A kiszolgálóoldali Blazor alkalmazások a kiszolgáló memóriájában élnek, és több alkalmazás-munkamenet is ugyanazon a folyamaton belül fut. Az egyes alkalmazás-munkamenetek esetében Blazor saját függőség befecskendezési tároló hatókörével körfolyamatot indít, így a hatókörön belüli szolgáltatások Blazor munkamenetenként egyediek.

Figyelmeztetés

Nem javasoljuk, hogy az azonos kiszolgálói megosztási állapotban lévő alkalmazások egyszeri szolgáltatásokat használjanak, kivéve, ha különös figyelmet igényelnek, mivel ez biztonsági réseket okozhat, például kiszivárogtathatja a felhasználói állapotot a kapcsolatcsoportok között.

Állapotalapú szingelton szolgáltatásokat használhat a Blazor alkalmazásokban, ha kifejezetten erre tervezték őket. Az egytonos memóriagyorsítótár használata például elfogadható, mert a memória-gyorsítótárnak kulcsra van szüksége egy adott bejegyzés eléréséhez. Feltéve, hogy a felhasználók nem irányítják a gyorsítótárban használt gyorsítótárkulcsokat, a gyorsítótárban tárolt állapot nem szivárog ki a kapcsolatcsoportok között.

Az állapotkezeléssel kapcsolatos általános útmutatásért lásd az ASP.NET Alapszintű Blazor állapotkezelés áttekintését.

IHttpContextAccessor/HttpContext

További információkért lásd: IHttpContextAccessor/HttpContext az ASP.NET Core Blazor alkalmazásokban.

Erőforrás-kimerültség

Az erőforrás-kimerülés akkor fordulhat elő, ha egy ügyfél kommunikál a kiszolgálóval, és a kiszolgáló túlzott erőforrásokat használ fel. A túlzott erőforrás-felhasználás elsősorban a következőket érinti:

• CPU
• memória
• ügyfélkapcsolatok

A szolgáltatásmegtagadási (DoS-) támadások általában egy alkalmazás vagy kiszolgáló erőforrásainak kimerítésére irányulnak. Az erőforrás-kimerültség azonban nem feltétlenül a rendszer elleni támadás eredménye. A véges erőforrások például a magas felhasználói igény miatt kimerülhetnek. A DoS részletesebben tárgyalva van a DoS szakasz-ben.

A Blazor keretrendszeren kívüli erőforrások, például adatbázisok és fájlleírók (fájlok olvasására és írására) szintén erőforrás-kimerültséget tapasztalhatnak. További információ: ASP.NET alapvető ajánlott eljárások.

CPU

A processzor kimerülése akkor fordulhat elő, ha egy vagy több ügyfél intenzív processzormunkára kényszeríti a kiszolgálót.

Vegyük például azt az alkalmazást, amely egy Fibonnacci-számot számít ki. A Fibonnacci-szám egy Fibonnacci-sorozatból jön létre, ahol a sorozat minden egyes száma az előző két szám összege. A válasz eléréséhez szükséges munka mennyisége a sorozat hosszától és a kezdeti érték méretétől függ. Ha az alkalmazás nem korlátozza az ügyfél kérését, a processzorigényes számítások uralhatják a processzoridőt, és csökkenthetik a többi feladat teljesítményét. A túlzott erőforrás-felhasználás a rendelkezésre állásra gyakorolt biztonsági probléma.

A cpu-kimerültség az összes nyilvánosan elérhető alkalmazás számára problémát jelent. A normál webalkalmazásokban a kérések és kapcsolatok esetében időtúllépést alkalmaznak biztonsági intézkedésként, de a Blazor alkalmazásoknál ezeket a biztonsági intézkedéseket nem biztosítják. Blazor alkalmazásoknak megfelelő ellenőrzéseket és korlátozásokat kell tartalmazniuk, mielőtt processzorigényes munkát végeznek.

Emlékezet

A memória kimerülése akkor fordulhat elő, ha egy vagy több ügyfél nagy mennyiségű memória felhasználására kényszeríti a kiszolgálót.

Vegyük például egy olyan alkalmazást, amely egy olyan összetevővel rendelkezik, amely elfogadja és megjeleníti az elemek listáját. Ha az Blazor alkalmazás nem korlátozza az engedélyezett elemek számát vagy az ügyfélnek visszaadott elemek számát, a memóriaigényes feldolgozás és a renderelés a kiszolgáló memóriáját olyan mértékben uralhatja, ahol a kiszolgáló teljesítménye szenved. Előfordulhat, hogy a kiszolgáló összeomlik, vagy annyira lelassul, hogy úgy tűnik, mintha összeomlott volna.

Fontolja meg a következő forgatókönyvet a kiszolgáló lehetséges memóriakimerülési forgatókönyvéhez kapcsolódó elemek listájának karbantartásához és megjelenítéséhez:

• A List<T> tulajdonság vagy mező elemei a kiszolgáló memóriáját használják. Ha az alkalmazás lehetővé teszi, hogy az elemek listája korlátlanul növekedjen, fennáll annak a kockázata, hogy a kiszolgáló elfogy a memóriája. A memóriakihasználtság miatt az aktuális munkamenet véget ér (összeomlik), és az adott kiszolgálópéldány összes egyidejű munkamenete memóriakivételt kap. Ennek a forgatókönyvnek a megakadályozása érdekében az alkalmazásnak olyan adatstruktúrát kell használnia, amely egy elemkorlátot ír elő az egyidejű felhasználók számára.
• Ha nem használ lapozási sémát a rendereléshez, a kiszolgáló további memóriát használ a felhasználói felületen nem látható objektumokhoz. Az elemek számának korlátozása nélkül a memóriaigények kimeríthetik a rendelkezésre álló kiszolgálói memóriát. A forgatókönyv megelőzéséhez használja az alábbi módszerek egyikét:
  • Többoldalas listák használata rendereléskor.
  • Csak az első 100–1000 elemet jeleníti meg, és a felhasználónak meg kell adnia a keresési feltételeket a megjelenített elemeken túli elemek kereséséhez.
  • Haladóbb renderelési forgatókönyvben implementálhat olyan listákat vagy rácsokat, amelyek támogatják a virtualizálást. A virtualizálással a listák csak a felhasználó számára jelenleg látható elemek egy részét jelenítik meg. Amikor a felhasználó a felhasználói felületen használja a görgetősávot, az összetevő csak a megjelenítéshez szükséges elemeket jeleníti meg. A megjelenítéshez jelenleg nem szükséges elemek másodlagos tárolóban tárolhatók, ami az ideális módszer. A nem lejátszott elemek a memóriában is tárolhatók, ami kevésbé ideális.

Jegyzet

Blazor beépített támogatást nyújt a virtualizáláshoz. További információért lásd: ASP.NET Core Razor összetevő-virtualizálás.

Blazor alkalmazások hasonló programozási modellt kínálnak más felhasználói felületi keretrendszerekhez állapotfüggő alkalmazások számára, mint például a WPF, a Windows Forms-hoz vagy a Blazor WebAssembly. A fő különbség az, hogy számos felhasználói felületi keretrendszerben az alkalmazás által felhasznált memória az ügyfélhez tartozik, és csak az adott ügyfelet érinti. Egy Blazor WebAssembly-alkalmazás például teljes egészében az ügyfélen fut, és csak az ügyfél memória-erőforrásait használja. Kiszolgálóoldali Blazor-alkalmazások esetében az alkalmazás által felhasznált memória a kiszolgálóhoz tartozik, és meg van osztva a kiszolgálópéldány ügyfelei között.

A kiszolgálóoldali memóriaigényt minden Blazor alkalmazás esetében figyelembe kell venni. A legtöbb webalkalmazás azonban állapot nélküli, és a kérés feldolgozása során használt memória a válasz visszaadásakor felszabadul. Általános javaslatként ne engedélyezze az ügyfelek számára, hogy kötetlen mennyiségű memóriát foglaljanak le, mint bármely más kiszolgálóoldali alkalmazásban, amely megőrzi az ügyfélkapcsolatokat. A kiszolgálóoldali Blazor alkalmazás által felhasznált memória hosszabb ideig marad fenn, mint egyetlen kérelem.

Jegyzet

A fejlesztés során profilkészítőt vagy nyomkövetést használhat az ügyfelek memóriaigényének felméréséhez. A profilkészítő vagy nyomkövetés nem rögzíti az adott ügyfél számára lefoglalt memóriát. Ha egy adott ügyfél memóriahasználatát szeretné rögzíteni a fejlesztés során, rögzítsen egy memóriaképet, és vizsgálja meg a felhasználói kapcsolatcsoportban gyökerező összes objektum memóriaigényét.

Ügyfélkapcsolatok

A kapcsolat kimerülése akkor fordulhat elő, ha egy vagy több ügyfél túl sok egyidejű kapcsolatot nyit meg a kiszolgálóval, ami megakadályozza, hogy más ügyfelek új kapcsolatokat hozzanak létre.

Blazor ügyfelek munkamenetenként egyetlen kapcsolatot létesítenek, és mindaddig nyitva tartják a kapcsolatot, amíg a böngészőablak meg van nyitva. Tekintettel a kapcsolatok állandó jellegére és a kiszolgálóoldali Blazor alkalmazások állapotalapú jellegére, a kapcsolatok kimerülése nagyobb kockázatot jelent az alkalmazás rendelkezésre állására.

Az alkalmazáshoz felhasználónkénti kapcsolatok száma nincs korlátozva. Ha az alkalmazáshoz kapcsolati korlát szükséges, kövesse az alábbi módszerek valamelyikét:

• Hitelesítés megkövetelése, amely természetesen korlátozza a jogosulatlan felhasználók csatlakozását az alkalmazáshoz. Ahhoz, hogy ez a forgatókönyv hatékony legyen, a felhasználókat meg kell akadályozni abban, hogy igény szerint új felhasználókat építhessenek ki.
• Felhasználónkénti kapcsolatok számának korlátozása. A kapcsolatok korlátozása az alábbi módszerekkel valósítható meg. Ügyeljen arra, hogy a jogos felhasználók hozzáférhessenek az alkalmazáshoz (például amikor az ügyfél IP-címe alapján létesítenek kapcsolati korlátot).
  • Alkalmazásszint
    • Végpont-útválasztás bővíthetősége.
    • Hitelesítés megkövetelése az alkalmazáshoz való csatlakozáshoz és az aktív munkamenetek felhasználónkénti nyomon követéséhez.
    • Új munkamenetek elutasítása a korlát elérésekor.
    • WebSocket-kapcsolatok egy alkalmazáshoz proxy használatával érhetők el, például az Azure SignalR Service révén, amely multiplexeli a kliensek és az alkalmazás közötti kapcsolatokat. Ez nagyobb kapcsolati kapacitást biztosít egy alkalmazás számára, mint amennyit egyetlen ügyfél képes létrehozni, megakadályozva, hogy az ügyfél kimerítse a kiszolgálóhoz való kapcsolatokat.
  • Kiszolgálószint: Használjon proxyt/átjárót az alkalmazás előtt.
    • Azure Application Gateway egy webes forgalom (OSI 7. réteg) terheléselosztó, amely lehetővé teszi a webalkalmazások felé irányuló forgalom kezelését. További információ: WebSocket-támogatás áttekintése az Application Gateway.
    • Azure Front Door egy terheléselosztási szolgáltatás, amely a számítási feladatokat több számítási erőforrás között osztja el.

Szolgáltatásmegtagadási (DoS-) támadások

Szolgáltatásmegtagadási (DoS-) támadások olyan ügyfelet érintenek, amely miatt a kiszolgáló kimerít egy vagy több erőforrást, így az alkalmazás elérhetetlenné válik. Blazor alkalmazások alapértelmezett korlátokat tartalmaznak, és más ASP.NET Core- és SignalR-korlátokra támaszkodnak, amelyek a DoS-támadások elleni védelem érdekében CircuitOptions vannak beállítva:

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

További információkért és konfigurációkódolási példákért tekintse meg az alábbi cikkeket:

• ASP.NET Core BlazorSignalR útmutató
• ASP.NET Core SignalR konfiguráció

Interakciók a böngészővel (ügyféllel)

Az ügyfél a JS interop eseményküldés és renderelés befejezése révén kommunikál a kiszolgálóval. JS Az interop kommunikáció kétirányú a JavaScript és a .NET között.

• A böngészőeseményeket a rendszer aszinkron módon küldi el az ügyféltől a kiszolgálóra.
• A kiszolgáló szükség szerint aszinkron módon válaszol a felhasználói felület újrarendezésére.

A .NET-ből meghívott JavaScript-függvények

.NET-metódusokból JavaScriptre irányuló hívások esetén:

• Minden hívás konfigurálható időtúllépéssel rendelkezik, amely lejárta után sikertelenek, és a rendszer egy OperationCanceledException értéket ad vissza a hívónak.
  • Az alapértelmezett időkorlát a hívásoknál (CircuitOptions.JSInteropDefaultCallTimeout) egy perc. A korlát konfigurálásához lásd: JavaScript-függvények meghívása a .NET-metódusokból ASP.NET Core Blazor.
  • Megszakítási token biztosítható a hívások megszakításának ellenőrzésére hívásonként. Ha lehetséges, támaszkodjon az alapértelmezett hívásidőkorlátra, és ha rendelkezik lemondási jogkivonattal, akkor az ügyfélhez irányuló hívásokat időkorláttal kell ellátni.
• Egy JavaScript-hívás eredménye nem megbízható. A böngészőben futó Blazor alkalmazásügyfél megkeresi a meghívandó JavaScript-függvényt. A függvényt meghívják, és vagy az eredmény, vagy egy hiba keletkezik. A rosszindulatú ügyfél megkísérelheti a következőt:
  • Hibát okozhat az alkalmazásban, ha hibát ad vissza a JavaScript függvényből.
  • Nem szándékos viselkedést válthat ki a kiszolgálón, ha váratlan eredményt ad vissza a JavaScript-függvényből.

A fenti forgatókönyvek elleni védelem érdekében tegye a következő óvintézkedéseket:

• A JS interop-hívásokat helyezze el a try-catch utasításokban, hogy figyelembe vegyék a meghívások során előforduló hibákat. További információ: ASP.NET Core Blazor-alkalmazások hibáinak kezelése.
• A művelet végrehajtása előtt ellenőrizze JS interop-hívásból visszaadott adatokat, beleértve a hibaüzeneteket is.

A böngészőből meghívott .NET-metódusok

Ne bízzon a JavaScriptből a .NET metódusokra történő hívásokban. Ha egy .NET-metódust a JavaScript elérhetővé teszi, fontolja meg a .NET metódus meghívását:

• Kezelje a JavaScript által közzétett .NET-metódusokat úgy, mint az alkalmazás nyilvános végpontját.
  • Bemenet ellenőrzése.
    • Győződjön meg arról, hogy az értékek a várt tartományokon belül vannak.
    • Győződjön meg arról, hogy a felhasználó rendelkezik engedéllyel a kért művelet végrehajtásához.
  • A .NET metódushívás részeként ne foglalj le túlzott mennyiségű erőforrást. Például végezzen ellenőrzéseket, és korlátozza a processzor- és memóriahasználatot.
  • Vegye figyelembe, hogy a statikus és a példány metódusai a JavaScript-ügyfelek számára is elérhetők. Kerülje a munkamenetek közötti megosztást, kivéve, ha a kialakítás megfelelő korlátozásokkal kéri a megosztási állapotot.
    • Például az eredetileg függőséginjektálással (DI) létrehozott DotNetObjectReference objektumokon keresztül közzétett metódusokat hatókörrel rendelkező objektumként kell regisztrálni. Ez minden olyan DI-szolgáltatásra vonatkozik, amelyet az alkalmazás használ.
    • Statikus módszerek esetén ne hozzon létre olyan állapotot, amely csak akkor alkalmazható az ügyfélre, ha az alkalmazás kifejezetten megosztja az állapotot a kiszolgálópéldány összes felhasználója között.
  • Ne adjon át felhasználó által megadott adatokat a paraméterekben JavaScript-hívásoknak. Ha az adatok paraméterekben való átadására feltétlenül szükség van, győződjön meg arról, hogy a JavaScript-kód kezeli az adatok továbbítását anélkül, hogy helyek közötti szkriptelést (XSS) biztonsági réseket vezet be. Például ne írjon felhasználó által megadott adatokat a DOM-ba egy elem innerHTML tulajdonságának beállításával. Fontolja meg Tartalombiztonsági szabályzat (CSP) használatát eval és egyéb nem biztonságos JavaScript-primitívek letiltásához. További információ: Tartalombiztonsági szabályzat kényszerítése a ASP.NET Core Blazor és az MDN CSP-útmutatójában.
• Kerülje a .NET-meghívások egyéni kézbesítésének implementálását a keretrendszer kézbesítési implementációján felül. A .NET-metódusok böngészőben való felfedése egy speciális forgatókönyv, amely nem ajánlott általános Blazor fejlesztéshez.

Események

Az események belépési pontot biztosítanak egy alkalmazáshoz. A webalkalmazásokban a végpontok védelmére vonatkozó szabályok az Blazor-alkalmazások eseménykezelésére vonatkoznak. A rosszindulatú ügyfél bármilyen adatot küldhet egy esemény hasznos adataként.

Például:

• Egy <select> változáseseménye olyan értéket küldhet, amely nem szerepel az alkalmazás által az ügyfélnek bemutatott beállítások között.
• Egy <input> bármilyen szöveges adatot küldhet a kiszolgálónak, elkerülve az ügyféloldali érvényesítést.

Az alkalmazásnak ellenőriznie kell az adatokat minden olyan esemény esetében, amelyet az alkalmazás kezel. A Blazor keretrendszer űrlapösszetevők alapszintű érvényesítéseket hajtanak végre. Ha az alkalmazás egyéni űrlapösszetevőket használ, egyéni kódot kell írni az eseményadatok megfelelő ellenőrzéséhez.

Az események aszinkronok, így több esemény is elküldhető a kiszolgálóra, mielőtt az alkalmazásnak ideje lenne reagálni egy új rendereléssel. Ennek biztonsági következményei vannak. Az alkalmazás ügyfélműveleteinek korlátozását eseménykezelőkben kell végrehajtani, és nem függhet az aktuális renderelt nézet állapotától.

Vegyünk egy számlálóösszetevőt, amely lehetővé teszi, hogy a felhasználó legfeljebb háromszor növelje a számlálót. A számláló növelő gomb feltételesen a countértékétől függ.

<p>Count: @count</p>

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

@code 
{
    private int count = 0;

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

Az ügyfél elküldhet egy vagy több növekményes eseményt, mielőtt a keretrendszer létrehozná az összetevő új renderelését. Ennek az az eredménye, hogy a count a felhasználó által több mint háromszor lehet növelni, mert a felhasználói felület nem távolítja el elég gyorsan a gombot. A három count növekmény korlátjának elérésének helyes módja az alábbi példában látható:

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

A kezelőn belüli if (count < 3) { ... }-ellenőrzés hozzáadásával a count növelésének döntése az aktuális alkalmazásállapoton alapul. A döntés nem a felhasználói felület állapotán alapul, mint az előző példában, ami átmenetileg elavult lehet.

Védelem több kézbesítés ellen

Ha egy eseményvisszahívás egy hosszú ideig futó műveletet aszinkron módon hív meg, például adatokat kér le egy külső szolgáltatásból vagy adatbázisból, fontolja meg a védelem használatát. A védelem megakadályozhatja, hogy a felhasználó több műveletet hajt végre, miközben a művelet vizuális visszajelzéssel van folyamatban. Az alábbi összetevőkód beállítja isLoading-t true-re, miközben DataService.GetDataAsync adatokat kér le a kiszolgálóról. Amíg isLoadingtrueértékkel bír, a gomb inaktív a felhasználói felületen.

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

Az előző példában bemutatott védelmi minta akkor működik, ha a háttérműveletet aszinkron módon hajtja végre a async-await mintával.

Lemondás korán és a kidobás utáni használat elkerülése

A Több kézbesítés elleni védelem szakaszban leírt védelem használata mellett érdemes megfontolni egy CancellationToken alkalmazását a hosszú ideig futó műveletek megszakítására az összetevő eltávolításakor. Ez a megközelítés további előnyt jelent, mivel elkerüli a használat utáni-t a komponensekben.

@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();
    }
}

Kerülje a nagy mennyiségű adatot termelő eseményeket

Egyes DOM-események, például oninput vagy onscroll, nagy mennyiségű adatot hozhatnak létre. Ne használja ezeket az eseményeket a kiszolgálóoldalon.

További biztonsági útmutató

Az ASP.NET Core-alkalmazások védelmének útmutatója a kiszolgálóoldali Blazor-alkalmazásokra vonatkozik, és a cikk következő szakaszaiban találhatók:

• naplózási és bizalmas adatok
• Az átvitel közben lévő információk védelme HTTPS-sel
• Cross-site scripting (helyek közötti szkriptelés, XSS)
• Kereszt-eredet védelem
• Kattintás-eltérítés
• Nyitott átirányítások

Naplózás és bizalmas adatok

JS az ügyfél és a kiszolgáló közötti interoperábilis interakciók a kiszolgáló naplóiban ILogger példányokkal vannak rögzítve. Blazor elkerüli a bizalmas adatok, például a tényleges események vagy JS interop bemenetek és kimenetek naplózását.

Ha hiba történik a kiszolgálón, a keretrendszer értesíti az ügyfelet, és leállítja a munkamenetet. Az ügyfél általános hibaüzenetet kap, amely a böngésző fejlesztői eszközeiben látható.

Az ügyféloldali hiba nem tartalmazza a hívásvermet, és nem ad részletes információt a hiba okáról, de a kiszolgálónaplók tartalmaznak ilyen információkat. Fejlesztési célokra az ügyfél számára elérhetővé tehetők a bizalmas hibainformációk a részletes hibákengedélyezésével.

Figyelmeztetés

Az ügyfelek internetes hibainformációinak felfedése biztonsági kockázatot jelent, amelyet mindig el kell kerülni.

Az átvitel alatt lévő információk védelme HTTPS használatával

Az ügyfél és a kiszolgáló közötti kommunikációhoz a Blazor a SignalR-et használja. Blazor általában a SignalR egyeztetett átvitelt használja, amely általában WebSockets.

Blazor nem biztosítja a kiszolgáló és az ügyfél között küldött adatok integritását és titkosságát. Mindig HTTPS-t használjon.

Helyek közötti szkriptelés (XSS)

A helyek közötti szkriptelés (XSS) lehetővé teszi, hogy egy jogosulatlan fél tetszőleges logikát hajtson végre a böngésző kontextusában. Egy feltört alkalmazás tetszőleges kódot futtathat az ügyfélen. A biztonsági rés használatával számos kártékony műveletet hajthat végre a kiszolgálón:

• Hamis/érvénytelen események küldése a kiszolgálóra.
• Sikertelen/érvénytelen renderelési befejezések küldése.
• Kerülje a renderelési folyamatok befejezéseinek elküldését.
• Interop-hívások küldése JavaScriptből a .NET-be.
• Módosítsa a .NET-ről JavaScriptre irányuló interop-hívások válaszát.
• Kerülje a .NET továbbítását JS interop eredményekhez.

A Blazor keretrendszer lépéseket tesz az előző fenyegetések elleni védelemre:

• Leállítja az új felhasználói felületi frissítések előállítását, ha az ügyfél nem ismeri el a renderelési kötegeket. Már konfigurálva CircuitOptions.MaxBufferedUnacknowledgedRenderBatches-ként.
• A .NET és JavaScript közötti hívások egy perc után lejárnak, ha nem érkezik válasz a klienstől. Már konfigurálva CircuitOptions.JSInteropDefaultCallTimeout-ként.
• Alapszintű ellenőrzést végez a böngészőből érkező összes bemeneten a JS interop során:
  • A .NET-hivatkozások érvényesek, és a .NET metódus által várt típusúak.
  • Az adatok nincsenek rosszul formázva.
  • A metódus argumentumainak helyes száma szerepel a terhelésben.
  • Az argumentumok vagy eredmények helyesen deszerializálhatók a metódus meghívása előtt.
• Alapszintű ellenőrzést végez a böngészőből érkező összes bemeneten a küldött eseményekből:
  • Az esemény érvényes típussal rendelkezik.
  • Az esemény adatai deszerializálhatók.
  • Egy eseménykezelő van társítva az eseményhez.

A keretrendszer által implementált védelem mellett az alkalmazást a fejlesztőnek kell kódálnia a fenyegetések elleni védelemhez és a megfelelő műveletek végrehajtásához:

• Események kezelésekor mindig ellenőrizze az adatokat.
• Az érvénytelen adatok fogadásakor megfelelő lépéseket kell tenni:
  • Hagyja figyelmen kívül az adatokat, és térjen vissza. Ez lehetővé teszi, hogy az alkalmazás folytassa a kérelmek feldolgozását.
  • Ha az alkalmazás megállapítja, hogy a bemeneti adatok illegitimek, és nem állíthatók elő jogszerű ügyfél által, kivételt kell tenni. A kivétel eldobása megszakítja az áramkört, és véget vet a munkamenetnek.
• Ne bízzon a naplókban szereplő renderelési kötegek befejezése által nyújtott hibaüzenetben. A hiba az ügyfél által, és általában nem lehet megbízni benne, mivel az ügyfél kompromittálódhat.
• Ne bízzon a JS interop-hívások bemenetében a JavaScript és a .NET metódusok közötti bármelyik irányban.
• Az alkalmazás felelős annak ellenőrzéséért, hogy az argumentumok és eredmények tartalma érvényes-e, még akkor is, ha az argumentumok vagy eredmények megfelelően deszerializálva vannak.

Az XSS biztonsági résének meglétéhez az alkalmazásnak tartalmaznia kell a felhasználói bemenetet a renderelt oldalon. Blazor végrehajt egy fordítási idejű lépést, amelyben a .razor fájlban lévő jelölés eljárási C#-logikává alakul. Futásidőben a C#-logika létrehoz egy renderfát, amely leírja az elemeket, a szöveget és a gyermekösszetevőket. Ez a böngésző DOM-jára javaScript-utasítások sorozatán keresztül kerül alkalmazásra (vagy előrerendezés esetén HTML-ben szerializálva):

• A normál Razor szintaxissal (például @someStringValue) renderelt felhasználói bemenet nem tesz közzé XSS-biztonsági rést, mert a Razor szintaxis csak szöveget írni képes parancsokkal lesz hozzáadva a DOM-hoz. Az érték akkor is statikus szövegként kerül megjelenítésre, ha az érték HTML jelölőt tartalmaz. Az előrendeléskor a kimenet HTML-kódolású, amely statikus szövegként is megjeleníti a tartalmat.
• Az összetevő-szerzők Razorhasználata nélkül is létrehozhatnak összetevőket c# nyelven. A kimenet kibocsátásakor az összetevő szerzője felelős a megfelelő API-k használatáért. Használjon például builder.AddContent(0, someUserSuppliedString), és nebuilder.AddMarkupContent(0, someUserSuppliedString), mert ez utóbbi XSS-biztonsági rést hozhat létre.

Fontolja meg az XSS biztonsági réseinek további mérséklését. Implementáljon például egy korlátozó tartalombiztonsági szabályzatot (CSP). További információ: Tartalombiztonsági szabályzat kényszerítése a ASP.NET Core Blazor és az MDN CSP-útmutatójában.

További információért lásd: Helyek közötti szkriptelés (XSS) megakadályozása az ASP.NET Core-ben.

Kereszt-eredetű védelem

A forrásközi támadások során egy másik forrásból származó ügyfél műveletet hajt végre a kiszolgáló ellen. A rosszindulatú művelet általában egy GET kérés vagy egy űrlap POST (helyek közötti kérelemhamisítás, CSRF), de egy rosszindulatú WebSocket megnyitása is lehetséges. Blazor alkalmazások ugyanazokat a garanciákat biztosítják, mint bármely más SignalR, a központi protokollt használó alkalmazás:

• Az alkalmazások forrásközi hozzáféréssel érhetők el, kivéve, ha további intézkedéseket hoznak annak megakadályozására. A kereszt-eredet hozzáférés letiltásához tiltsa le a CORS-t a végpontban a CORS Middleware hozzáadásával a folyamathoz, és adja hozzá a DisableCorsAttribute a Blazor végpont metaadataihoz, vagy korlátozza az engedélyezett eredetek halmazát a SignalR konfigurálásával a Kereszt-Eredet Erőforrás Megosztás számára. A WebSocket-forrás korlátozásaira vonatkozó útmutatáshoz tekintse meg a WebSockets támogatás az ASP.NET Corecímű részt.
• Ha a CORS engedélyezve van, további lépésekre lehet szükség az alkalmazás védelméhez a CORS-konfigurációtól függően. Ha a CORS globálisan engedélyezve van, a CORS letiltható a BlazorSignalR hub számára, ha hozzáadja a DisableCorsAttribute metaadatokat a végpont metaadataihoz, miután lefuttatta a MapBlazorHub-at a végpontútvonal-szerkesztőn.

További információért lásd: helyek közötti kérelemhamisítás (XSRF/CSRF) támadások megakadályozása az ASP.NET Core-ban.

Klikkeltérítés

A click-jacking abból áll, hogy egy webhelyet más forrásból származó oldalon jelenítenek meg technikai módszerekkel (például <iframe> keret használatával), hogy a felhasználót becsapják, és így akaratlanul cselekvésre bírják a támadott weboldalon.

Egy alkalmazás <iframe>belüli megjelenésének megakadályozásához használja a Tartalombiztonsági Szabályzatot (CSP) és a X-Frame-Options fejléceket. A CSP szintaxisát az MDN CSP-útmutatójában találja.

További információ:

• Tartalombiztonsági szabályzat kényszerítése ASP.NET Core Blazor
• MDN webes dokumentumai: X-Frame-Options

Átirányítások megnyitása

Amikor egy alkalmazás-munkamenet elindul, a kiszolgáló elvégzi a munkamenet indítása során küldött URL-címek alapvető ellenőrzését. A keretrendszer a kapcsolatcsoport létrehozása előtt ellenőrzi, hogy az alap URL-cím az aktuális URL-cím szülője-e. A keretrendszer nem végez további ellenőrzéseket.

Amikor egy felhasználó kiválaszt egy hivatkozást az ügyfélen, a rendszer elküldi a hivatkozás URL-címét a kiszolgálónak, amely meghatározza, hogy milyen műveletet kell elvégeznie. Az alkalmazás például ügyféloldali navigációt hajthat végre, vagy jelezheti a böngészőnek, hogy az új helyre lépjen.

Az összetevők programozott módon is elindíthatják a navigációs kéréseket a NavigationManagerhasználatával. Ilyen esetekben az alkalmazás ügyféloldali navigációt hajthat végre, vagy jelezheti a böngészőnek, hogy az új helyre lépjen.

Az összetevőknek kell:

• Kerülje a felhasználói bevitel használatát a navigációs hívás argumentumai részeként.
• Ellenőrizze az argumentumokat annak biztosítására, hogy a célt engedélyezze az alkalmazás.

Ellenkező esetben a rosszindulatú felhasználók kényszeríthetik a böngészőt, hogy egy kibertámadás által vezérelt webhelyre lépjenek. Ebben a forgatókönyvben a kibertámadó ráveszi az alkalmazást, hogy felhasználói bemenetet használjon fel a NavigationManager.NavigateTo metódus meghívásának részeként.

Ez a tanács akkor is érvényes, ha hivatkozásokat jelenít meg az alkalmazás részeként:

• Ha lehetséges, használjon relatív hivatkozásokat.
• Ellenőrizze, hogy az abszolút hivatkozási célhelyek érvényesek-e, mielőtt belevennénk őket egy oldalra.

További információ: Nyílt átirányítási támadások megakadályozása ASP.NET Core.

Biztonsági ellenőrzőlista

A biztonsági szempontok alábbi listája nem átfogó:

• Argumentumok ellenőrzése eseményekből.
• Ellenőrizze JS interop-hívások bemeneteit és eredményeit.
• Kerülje a felhasználói bemenet .NET interop hívásokkal való használatát, vagy előzetesen ellenőrizze azt JS.
• Ne engedje az ügyfélnek, hogy korlátlan mennyiségű memóriát foglaljon le.
  • Az összetevőn belüli adatok.
  • DotNetObjectReference az ügyfélnek visszaadott objektumok.
• Védelem a többes kiküldés ellen.
• A hosszú ideig futó műveletek megszakítása az összetevő törlésekor.
• Kerülje a nagy mennyiségű adatot termelő eseményeket.
• Kerülje el felhasználói bemenet használatát a NavigationManager.NavigateTo hívások részeként, és ha elkerülhetetlen, először ellenőrizze a felhasználói URL-bemenetet egy meghatározott engedélyezett forráskészlethez képest.
• Ne hozzon engedélyezési döntéseket a felhasználói felület állapota alapján, csak az összetevő állapota alapján.
• Fontolja meg tartalombiztonsági szabályzat (CSP) használatát az XSS-támadások elleni védelemhez. További információ: Tartalombiztonsági szabályzat kényszerítése a ASP.NET Core Blazor és az MDN CSP-útmutatójában.
• Fontolja meg a CSP és X-Frame-Options használatát a clickjacking elleni védelemhez.
• Győződjön meg arról, hogy a CORS-beállítások megfelelőek, amikor engedélyezi a CORS-t, vagy kifejezetten letiltja a CORS-t Blazor alkalmazásokhoz.
• Ellenőrizze, hogy a Blazor alkalmazás kiszolgálóoldali korlátai elfogadható felhasználói élményt biztosítanak-e elfogadhatatlan kockázati szintek nélkül.