Prevence útoků XSRF/CSRF (Cross-Site Request Forgery) v ASP.NET Core

Autoři: Fiyaz Hasan a Rick Anderson

Zranitelnost zvaná cross-site request forgery (CSRF) je útok na webové aplikace, kdy škodlivá webová aplikace může ovlivnit interakci mezi klientským prohlížečem a webovou aplikací, která důvěřuje tomuto prohlížeči. Tyto útoky jsou možné, protože webové prohlížeče automaticky odesílají některé typy ověřovacích tokenů s každou žádostí na web. Tato forma zneužití se také označuje jako jednoklikový útok nebo únos relace, protože útok využívá dříve ověřenou relaci uživatele. Padělání požadavků mezi weby se také označuje jako XSRF nebo CSRF.

Příklad útoku CSRF:

1. Uživatel se přihlásí k www.good-banking-site.example.com pomocí ověření formulářem. Server ověřuje uživatele a vydává odpověď, která zahrnuje ověřování cookie. Web je zranitelný vůči útoku, protože důvěřuje všem požadavkem, který obdrží s platným ověřováním cookie.

2. Uživatel navštíví škodlivý web. www.bad-crook-site.example.com

   Škodlivý web obsahuje www.bad-crook-site.example.comformulář HTML podobný následujícímu příkladu:

   <h1>Congratulations! You're a Winner!</h1>
   <form action="https://www.good-banking-site.example.com/api/account" method="post">
       <input type="hidden" name="Transaction" value="withdraw" />
       <input type="hidden" name="Amount" value="1000000" />
       <input type="submit" value="Click to collect your prize!" />
   </form>
   

   Všimněte si, že formulář action odesílá na ohrožený web, nikoli na škodlivý web. Toto je "cross-site" část CSRF.

3. Uživatel vybere tlačítko Odeslat. Prohlížeč vytvoří požadavek a automaticky zahrne ověřování cookie pro požadovanou doménu. www.good-banking-site.example.com

4. Požadavek se spustí na www.good-banking-site.example.com serveru s kontextem ověřování uživatele a může provést jakoukoli akci, kterou může ověřený uživatel provést.

Kromě scénáře, ve kterém uživatel vybere tlačítko pro odeslání formuláře, může škodlivý web:

• Spusťte skript, který automaticky odešle formulář.
• Odešlete formulář jako požadavek AJAX.
• Skryjte formulář pomocí šablon stylů CSS.

Tyto alternativní scénáře nevyžadují žádnou akci ani vstup od jiného uživatele, než je počáteční návštěva škodlivého webu.

Použití PROTOKOLU HTTPS nezabrání útoku CSRF. Škodlivý web může odeslat https://www.good-banking-site.example.com/ požadavek stejně snadno, jako by mohl odeslat nezabezpečený požadavek.

Některé útoky cílí na koncové body, které reagují na požadavky GET, v takovém případě lze použít značku image k provedení akce. Tato forma útoku je běžná na webech fóra, které umožňují obrázky, ale blokují JavaScript. Aplikace, které mění stav požadavků GET, kde se mění proměnné nebo prostředky, jsou zranitelné vůči škodlivým útokům. Požadavky GET, které změní stav, jsou nezabezpečené. Osvědčeným postupem je nikdy změnit stav požadavku GET.

Útoky CSRF jsou možné vůči webovým aplikacím, které k ověřování používají soubory cookie, protože:

• Prohlížeče ukládají soubory cookie vydané webovou aplikací.
• Uložené soubory cookie obsahují soubory cookie relace pro ověřené uživatele.
• Prohlížeče odesílají všechny soubory cookie přidružené k doméně do webové aplikace bez ohledu na to, jak se požadavek na aplikaci vygeneroval v prohlížeči.

Útoky CSRF ale nejsou omezené na zneužití souborů cookie. Například základní ověřování a ověřování pomocí digest je také ohroženo. Jakmile se uživatel přihlásí pomocí ověřování Basic nebo Digest, prohlížeč automaticky odešle přihlašovací údaje, dokud relace neskončí.

V tomto kontextu relace odkazuje na relaci na straně klienta, ve které je uživatel ověřen. Nesouvisí to se serverovými relacemi ani s middlewarem relací ASP.NET Core.

Uživatelé mohou chránit před ohroženími zabezpečení CSRF pomocí bezpečnostních opatření:

• Po dokončení se odhlaste z webových aplikací.
• Pravidelně vymažte soubory cookie prohlížeče.

Ohrožení zabezpečení CSRF jsou ale v zásadě problém s webovou aplikací, nikoli koncovým uživatelem.

Základy ověřování

Cookie-založené ověřování je oblíbenou formou ověřování. Systémy ověřování založené na tokenech jsou stále oblíbenější, zejména pro jednostráňové aplikace (SPA).

Cookie-založené ověřování

Když se uživatel přihlásí pomocí uživatelského jména a hesla, je mu vydán token obsahující ověřovací autorizační lístek. Token lze použít k ověřování a autorizaci. Token se uloží jako cookie odesílaný s každým požadavkem, který klient provede. Generování a ověřování tohoto cookie se provádí pomocí middlewaru ověřování cookie. Middleware serializuje uživatelský principál do zašifrovaného cookie. V následných požadavcích middleware ověří cookie, znovu vytvoří hlavní objekt a přiřadí tento hlavní objekt k vlastnosti HttpContext.User.

Ověřování na základě tokenů

Když je uživatel ověřen, obdrží token, nikoli antiforgery token. Token obsahuje informace o uživateli ve formě deklarací identity nebo referenčního tokenu, který odkazuje aplikaci na stav uživatele udržovaný v aplikaci. Když se uživatel pokusí získat přístup k prostředku, který vyžaduje ověření, token se odešle do aplikace s extra autorizační hlavičkou ve formě tokenu Bearer . Díky tomuto přístupu je aplikace bezstavová. V každém dalším požadavku se token předá v požadavku na ověření na straně serveru. Tento token není šifrovaný, je zakódovaný. Na serveru je token dekódován pro přístup k jeho informacím. Pokud chcete token odeslat při dalších požadavcích, uložte ho do místního úložiště prohlížeče. Umístění tokenu do místního úložiště prohlížeče a jeho načtení a jeho použití jako nosný token poskytuje ochranu před útoky CSRF. Pokud je však aplikace zranitelná vůči injektáži skriptu prostřednictvím XSS nebo ohroženého externího javascriptového souboru, může kyberattacker načíst libovolnou hodnotu z místního úložiště a odeslat ji sama sobě. ASP.NET Core ve výchozím nastavení kóduje veškerý výstup na straně serveru z proměnných a snižuje riziko XSS. Pokud toto chování přepíšete pomocí Html.Raw nebo vlastního kódu s nedůvěryhodným vstupem, můžete zvýšit riziko XSS.

Nedělejte si starosti s ohrožením zabezpečení CSRF, pokud je token uložený v místním úložišti prohlížeče. CSRF je riziko, když je token uložen v cookie. Další informace najdete v problému GitHubu SPA code sample adds two cookies.

Více aplikací hostovaných v jedné doméně

Sdílené hostitelské prostředí jsou zranitelná vůči únosu relace, CSRF útokům při přihlášení a dalším útokům.

I když example1.contoso.net a example2.contoso.net jsou různí hostitelé, existuje implicitní vztah důvěryhodnosti mezi hostiteli v rámci *.contoso.net domény. Tento implicitní vztah důvěryhodnosti umožňuje potenciálně nedůvěryhodným hostitelům ovlivnit soubory cookie ostatních (zásady stejného původu, které řídí požadavky AJAX, se nemusí nutně vztahovat na soubory cookie HTTP).

Útoky, které zneužívají důvěryhodné soubory cookie mezi aplikacemi hostovanými ve stejné doméně, je možné zabránit tím, že nesdílí domény. Když je každá aplikace hostovaná ve vlastní doméně, neexistuje žádný implicitní cookie vztah důvěryhodnosti, který by bylo potřeba zneužít.

Antiforgery v ASP.NET Core

Upozornění

ASP.NET Core implementuje antiforgery pomocí ASP.NET Core Data Protection. Zásobník ochrany dat musí být nakonfigurovaný tak, aby fungoval v serverové farmě. Další informace najdete v tématu Konfigurace ochrany dat.

Do kontejneru vkládání závislostí se middleware antiforgery přidá, když je voláno některé z následujících API rozhraní Program.cs:

• AddMvc
• MapRazorPages
• MapControllerRoute
• AddRazorComponents

Další informace naleznete v části Antiforgery s minimálními API rozhraními.

FormTagHelper vkládá do prvků formulářů HTML tokeny proti padělkům. Následující kód v Razor souboru automaticky generuje antiforgery tokeny:

<form method="post">
    <!-- ... -->
</form>

Podobně IHtmlHelper.BeginForm ve výchozím nastavení generuje antiforgery tokeny, pokud metoda formuláře není GET.

Automatické generování tokenů antiforgery pro elementy formuláře HTML nastane, když <form> značka obsahuje method="post" atribut a některé z následujících hodnot jsou pravdivé:

• Atribut akce je prázdný (action="").
• Atribut akce není zadán (<form method="post">).

Automatické generování antiforgerických tokenů pro elementy formuláře HTML lze zakázat:

• Explicitně zakažte antiforgery tokeny s atributem asp-antiforgery :

  <form method="post" asp-antiforgery="false">
      <!-- ... -->
  </form>
  

• Prvek formuláře je vyloučen z pomocníků značek pomocí symbolu ! opt-out symbol:

  <!form method="post">
      <!-- ... -->
  </!form>
  

• Odeberte FormTagHelper ze zobrazení. FormTagHelper lze ze zobrazení odebrat přidáním následující direktivy do Razor zobrazení.

  @removeTagHelper Microsoft.AspNetCore.Mvc.TagHelpers.FormTagHelper, Microsoft.AspNetCore.Mvc.TagHelpers
  

Poznámka:

Razor Stránky jsou automaticky chráněny před XSRF/CSRF. Další informace najdete v tématu XSRF/CSRF a Razor Pages.

Nejběžnějším přístupem k ochraně před útoky CSRF je použití vzoru tokenů synchronizátoru (STP). STP se používá, když uživatel požádá o stránku s daty formuláře:

1. Server odešle klientovi token přidružený k identitě aktuálního uživatele.
2. Klient odešle token zpět na server k ověření.
3. Pokud server obdrží token, který neodpovídá identitě ověřeného uživatele, žádost se odmítne.

Token je jedinečný a nepředvídatelný. Token lze použít také k zajištění správného sekvencování řady požadavků (například k zajištění pořadí požadavků na stránce 1 > strana 2 > strana 3). Všechny formuláře v šablonách ASP.NET Core MVC a Razor Pages generují antiforgery tokeny. Následující dvojice příkladů zobrazení generuje antiforgery tokeny:

<form asp-action="Index" asp-controller="Home" method="post">
    <!-- ... -->
</form>

@using (Html.BeginForm("Index", "Home"))
{
    <!-- ... -->
}

Explicitně přidejte antiforgery token do prvku <form> bez použití značkového pomocníka s pomocnou rutinou HTML @Html.AntiForgeryToken:

<form asp-action="Index" asp-controller="Home" method="post">
    @Html.AntiForgeryToken()

    <!-- ... -->
</form>

V každém z předchozích případů ASP.NET Core přidá skryté pole formuláře podobné následujícímu příkladu:

<input name="__RequestVerificationToken" type="hidden" value="CfDJ8NrAkS ... s2-m9Yw">

ASP.NET Core obsahuje tři filtry pro práci s antiforgery tokeny:

• ValidateAntiForgeryToken
• AutoValidateAntiforgeryToken
• IgnoreAntiforgeryToken

Ochrana proti padělání s AddControllers

Volání AddControllers neaktivuje antiforgery tokeny. AddControllersWithViews musí být volána, aby byla podporována integrovaná antiforgery token.

Více karet prohlížeče a vzor synchronizačního tokenu

Nejsou podporovány více karty přihlášené jako různí uživatelé, nebo přihlášení jako anonymní uživatel.

Nakonfigurujte antiforgery pomocí AntiforgeryOptions

Přizpůsobte AntiforgeryOptions v souboru Program aplikace:

builder.Services.AddAntiforgery(options =>
{
    // Set Cookie properties using CookieBuilder properties†.
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-HEADERNAME";
    options.SuppressXFrameOptionsHeader = false;
});

Nastavte vlastnosti antiforgery cookie pomocí vlastností CookieBuilder třídy, jak je uvedeno v následující tabulce.

Možnost	Popis
Cookie	Určuje nastavení použitá k vytvoření ochranných cookies.
FormFieldName	Název skrytého pole formuláře používaného systémem antiforgery pro vykreslení tokenů antiforgery v zobrazeních.
HeaderName	Název hlavičky používané systémem antiforgery. Pokud null, systém považuje pouze data formuláře.
SuppressXFrameOptionsHeader	Určuje, jestli se má potlačit generování hlavičky X-Frame-Options . Ve výchozím nastavení se hlavička vygeneruje s hodnotou SAMEORIGIN. Výchozí hodnota je false.

Některé prohlížeče neumožňují nezabezpečeným koncovým bodům nastavit soubory cookie s příznakem "secure" nebo přepsat soubory cookie, jejichž je nastavený příznak secure (další informace najdete v tématu Vyřazení změn zabezpečených souborů cookie z nezabezpečených zdrojů). Vzhledem k tomu, že kombinování zabezpečených a nezabezpečených koncových bodů je běžným scénářem v aplikacích, ASP.NET Core zmírňuje omezení zásad zabezpečení u některých souborů cookie, jako například u antiforgery cookie, tím, že nastavuje atribut cookie souboru SecurePolicy na hodnotu CookieSecurePolicy.None. Kdyby uživatel se zlými úmysly ukradl antiforgery cookie, musí také ukrást antiforgery token, který je obvykle odeslán prostřednictvím pole formuláře (běžnější) nebo samostatné hlavičky požadavku (méně běžné) plus autentizaci cookie. Cookies související s ověřováním nebo autorizací používají silnější zásady než CookieSecurePolicy.None.

Volitelně můžete antiforgery cookie zabezpečit v jinýchDevelopment prostředích pomocí protokolu SSL (Secure Sockets Layer) pouze přes PROTOKOL HTTPS s následujícím AntiforgeryOptions.Cookie nastavením vlastnosti v souboru aplikace Program :

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddAntiforgery(o =>
    {
        o.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

Další informace najdete na webu CookieAuthenticationOptions.

Generování antiforgery tokenů pomocí IAntiforgery

IAntiforgery poskytuje rozhraní API ke konfiguraci funkcí proti padělání. IAntiforgery lze požádat v Program.cs pomocí WebApplication.Services. Následující příklad používá middleware z domovské stránky aplikace k vygenerování antiforgery tokenu a jeho odeslání v odpovědi jako cookie.

app.UseRouting();

app.UseAuthorization();

var antiforgery = app.Services.GetRequiredService<IAntiforgery>();

app.Use((context, next) =>
{
    var requestPath = context.Request.Path.Value;

    if (string.Equals(requestPath, "/", StringComparison.OrdinalIgnoreCase)
        || string.Equals(requestPath, "/index.html", StringComparison.OrdinalIgnoreCase))
    {
        var tokenSet = antiforgery.GetAndStoreTokens(context);
        context.Response.Cookies.Append("XSRF-TOKEN", tokenSet.RequestToken!,
            new CookieOptions { HttpOnly = false });
    }

    return next(context);
});

Předchozí příklad nastaví cookie s názvem XSRF-TOKEN. Klient si to cookie může přečíst a zadat jeho hodnotu jako hlavičku připojenou k žádostem AJAX. Angular například obsahuje integrovanou ochranu XSRF, která ve výchozím nastavení čte pojmenovaný cookie.

Vyžadovat ověření proti padělání

Filtr akcí ValidateAntiForgeryToken lze použít u jednotlivé akce, kontroleru nebo globálně. Požadavky provedené na akce, které mají tento filtr použitý, jsou blokované, pokud požadavek neobsahuje platný antiforgery token:

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Index()
{
    // ...

    return RedirectToAction();
}

Atribut ValidateAntiForgeryToken vyžaduje token pro požadavky na metody akce, které označí, včetně požadavků HTTP GET. Pokud se atribut ValidateAntiForgeryToken použije na kontrolery aplikace, můžete ho přepsat pomocí atributu IgnoreAntiforgeryToken.

Automatické ověření tokenů antiforgery pouze pro nebezpečné metody HTTP

Místo široké aplikace atributu ValidateAntiForgeryToken a jeho přepsání pomocí atributů IgnoreAntiforgeryToken lze použít atribut AutoValidateAntiforgeryToken. Tento atribut funguje stejně jako ValidateAntiForgeryToken atribut s tím rozdílem, že nevyžaduje tokeny pro požadavky provedené pomocí následujících metod HTTP:

• GET
• Hlavička
• MOŽNOSTI
• TRACE

Pro scénáře, které nepoužívají rozhraní API, doporučujeme používat AutoValidateAntiforgeryToken široce. Tento atribut zajišťuje, že akce POST jsou ve výchozím nastavení chráněné. Alternativou je ignorovat antiforgery tokeny ve výchozím nastavení, pokud ValidateAntiForgeryToken není použita u jednotlivých metod akcí. V tomto scénáři je pravděpodobnější, že metoda akce POST zůstane nechráněná omylem, takže aplikace bude zranitelná vůči útokům CSRF. Všechny POSTy by měly odesílat antiforgery token.

Rozhraní API nemají automatický způsob odeslání části tokenu bez cookie. Implementace pravděpodobně závisí na implementaci klientského kódu. Tady je několik příkladů:

Příklad na úrovni třídy:

[AutoValidateAntiforgeryToken]
public class HomeController : Controller

Globální příklad:

builder.Services.AddControllersWithViews(options =>
{
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute());
});

Přepsání atributů antiforgery globálního serveru nebo kontroleru

Filtr IgnoreAntiforgeryToken se používá k odstranění potřeby tokenu antiforgery pro danou akci (nebo kontroler). Při použití tento filtr přepíše filtry ValidateAntiForgeryToken a AutoValidateAntiforgeryToken zadané na vyšší úrovni (globálně nebo na řadiči).

[IgnoreAntiforgeryToken]
public IActionResult IndexOverride()
{
    // ...

    return RedirectToAction();
}

Aktualizace tokenů po ověření

Tokeny by se měly aktualizovat po ověření uživatele přesměrováním uživatele na stránku zobrazení nebo Razor stránky.

JavaScript, AJAX a SPA

V tradičních aplikacích založených na HTML se antiforgery tokeny předávají serveru pomocí skrytých polí formuláře. V moderních aplikacích založených na JavaScriptu a SA se mnoho požadavků provádí programově. Tyto požadavky AJAX mohou k odeslání tokenu použít jiné techniky, jako jsou hlavičky požadavků nebo soubory cookie.

Pokud se soubory cookie používají k ukládání ověřovacích tokenů a k ověřování požadavků rozhraní API na serveru, je csrF potenciálním problémem. Pokud se k uložení tokenu používá místní úložiště, může se zmírnit ohrožení zabezpečení CSRF, protože hodnoty z místního úložiště se na server neodesílají automaticky s každou žádostí. Použití místního úložiště k uložení anti-forgery tokenu na klientovi a odeslání tokenu hlavičkou požadavku je doporučený postup.

Blazor

Pro více informací si přečtěte ASP.NET Core Blazor autentizaci a autorizaci.

JavaScript

Pomocí JavaScriptu se zobrazeními lze token vytvořit pomocí služby v zobrazení. IAntiforgery Vložte službu do zobrazení a zavolejteGetAndStoreTokens:

@inject Microsoft.AspNetCore.Antiforgery.IAntiforgery Antiforgery

@{
    ViewData["Title"] = "JavaScript";

    var requestToken = Antiforgery.GetAndStoreTokens(Context).RequestToken;
}

<input id="RequestVerificationToken" type="hidden" value="@requestToken" />

<button id="button" class="btn btn-primary">Submit with Token</button>
<div id="result" class="mt-2"></div>

@section Scripts {
<script>
    document.addEventListener("DOMContentLoaded", () => {
        const resultElement = document.getElementById("result");

        document.getElementById("button").addEventListener("click", async () => {

            const response = await fetch("@Url.Action("FetchEndpoint")", {
                method: "POST",
                headers: {
                    RequestVerificationToken:
                        document.getElementById("RequestVerificationToken").value
                }
            });

            if (response.ok) {
                resultElement.innerText = await response.text();
            } else {
                resultElement.innerText = `Request Failed: ${response.status}`
            }
        });
    });
</script>
}

Předchozí příklad používá JavaScript ke čtení skryté hodnoty pole hlavičky AJAX POST.

Tento přístup eliminuje nutnost zabývat se přímo nastavením souborů cookie ze serveru nebo jejich čtením z klienta. Pokud však vložení IAntiforgery služby není možné, použijte JavaScript pro přístup k tokenům v souborech cookie:

• Přístupové tokeny v dalším požadavku na server, obvykle same-origin.
• Použijte obsah cookie k vytvoření hlavičky s hodnotou tokenu.

Za předpokladu, že skript odešle token v hlavičce požadavku s názvem X-XSRF-TOKEN, nakonfigurujte službu antiforgery tak, aby hledala hlavičku X-XSRF-TOKEN :

builder.Services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");

Následující příklad přidá chráněný koncový bod, který zapíše token požadavku do javascriptově čitelného cookiekódu:

app.UseAuthorization();
app.MapGet("antiforgery/token", (IAntiforgery forgeryService, HttpContext context) =>
{
    var tokens = forgeryService.GetAndStoreTokens(context);
    context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken!,
            new CookieOptions { HttpOnly = false });

    return Results.Ok();
}).RequireAuthorization();

Následující příklad používá JavaScript k vytvoření požadavku AJAX na získání tokenu a provedení dalšího požadavku s příslušnou hlavičkou:

var response = await fetch("/antiforgery/token", {
    method: "GET",
    headers: { "Authorization": authorizationToken }
});

if (response.ok) {
    // https://developer.mozilla.org/docs/web/api/document/cookie
    const xsrfToken = document.cookie
        .split("; ")
        .find(row => row.startsWith("XSRF-TOKEN="))
        .split("=")[1];

    response = await fetch("/JavaScript/FetchEndpoint", {
        method: "POST",
        headers: { "X-XSRF-TOKEN": xsrfToken, "Authorization": authorizationToken }
    });

    if (response.ok) {
        resultElement.innerText = await response.text();
    } else {
        resultElement.innerText = `Request Failed: ${response.status}`
    }
} else {    
    resultElement.innerText = `Request Failed: ${response.status}`
}

Poznámka:

Pokud je token antiforgery zadaný v hlavičce požadavku i v datové části formuláře, ověří se pouze token v hlavičce.

Ochrana proti padělání s minimálními rozhraními API

Zavolejte AddAntiforgery a zaregistrujte služby ochrany proti padělání v DI. Antiforgery tokeny se používají ke zmírnění útoků proti padělání požadavků mezi weby.

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

app.MapGet("/", () => "Hello World!");

app.Run();

Antiforgery middleware:

• Není-li zkráceno provádění zbývající části kanálu požadavku?
• Nastaví IAntiforgeryValidationFeature v HttpContext.Features aktuálního požadavku.

Antiforgery token je ověřen pouze v případě, že:

• Koncový bod obsahuje metadata, která implementují IAntiforgeryMetadata tam, kde RequiresValidation=true.
• Metoda HTTP přidružená ke koncovému bodu je relevantní metoda HTTP typu POST, PUT nebo PATCH.
• Požadavek je přidružený k platnému koncovému bodu.

Antiforgery middleware nezkracuje pipeline požadavků. Kód koncového bodu se vždy spustí, i když selže ověření tokenu. Pokud chcete sledovat výsledek ověření tokenu, vyřešte IAntiforgeryValidationFeature od HttpContext.Features a zkontrolujte jeho vlastnost IsValid nebo vlastnost Error pro podrobnosti o selhání. Tento přístup je užitečný v případě, že koncové body vyžadují vlastní zpracování pro selhavší ověření ochrany proti padělání.

Poznámka: Pokud je antiforgery middleware povolen manuálně, musí být spuštěn po autentizačním a autorizačním middlewaru, aby se zabránilo čtení dat formuláře, když uživatel není ověřený.

Ve výchozím nastavení minimální rozhraní API, která přijímají data formuláře, vyžadují ověření tokenu antiforgery a před spuštěním kódu aplikace selžou, pokud ověření antiforgery není úspěšné.

Zvažte následující GenerateForm metodu:

public static string GenerateForm(string action, 
    AntiforgeryTokenSet token, bool UseToken=true)
{
    string tokenInput = "";
    if (UseToken)
    {
        tokenInput = $@"<input name=""{token.FormFieldName}""
                         type=""hidden"" value=""{token.RequestToken}"" />";
    }

    return $@"
    <html><body>
        <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
            {tokenInput}
            <input type=""text"" name=""name"" />
            <input type=""date"" name=""dueDate"" />
            <input type=""checkbox"" name=""isCompleted"" />
            <input type=""submit"" />
        </form>
    </body></html>
";
}

Předchozí kód obsahuje tři argumenty, akci, token antiforgery a bool indikující, jestli se má token použít.

Podívejte se na následující ukázku:

using Microsoft.AspNetCore.Antiforgery;
using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

// Pass token
app.MapGet("/", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo", token), "text/html");
});

// Don't pass a token, fails
app.MapGet("/SkipToken", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo",token, false ), "text/html");
});

// Post to /todo2. DisableAntiforgery on that endpoint so no token needed.
app.MapGet("/DisableAntiforgery", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo2", token, false), "text/html");
});

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

app.Run();

class Todo
{
    public required string Name { get; set; }
    public bool IsCompleted { get; set; }
    public DateTime DueDate { get; set; }
}

public static class MyHtml
{
    public static string GenerateForm(string action, 
        AntiforgeryTokenSet token, bool UseToken=true)
    {
        string tokenInput = "";
        if (UseToken)
        {
            tokenInput = $@"<input name=""{token.FormFieldName}""
                             type=""hidden"" value=""{token.RequestToken}"" />";
        }

        return $@"
        <html><body>
            <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
                {tokenInput}
                <input type=""text"" name=""name"" />
                <input type=""date"" name=""dueDate"" />
                <input type=""checkbox"" name=""isCompleted"" />
                <input type=""submit"" />
            </form>
        </body></html>
    ";
    }
}

V předchozím kódu se příspěvky odesílají do:

• /todo vyžaduje platný token proti padělání.
• /todo2 nevyžaduje platný antiforgery token, protože DisableAntiforgery je volána.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Upozornění

Volání .DisableAntiforgery() deaktivuje ochranu proti falšování požadavků mezi weby (CSRF) pro daný koncový bod. To by se mělo použít jenom v případě, že koncový bod není zranitelný vůči útokům CSRF, například:

• Koncové body, které se nedají volat z prohlížeče (například interní rozhraní API)
• Koncové body zabezpečené pomocí ověřování nezaloženého na cookie (například bearer tokeny nebo klíče rozhraní API)
• Interní koncové body nebo koncové body infrastruktury, které nespoléhají na soubory cookie uživatelů

Nezakazujte ověřování antiforgery pro koncové body přístupné z prohlížeče, které spoléhají na soubory cookie pro ověřování nebo zpracovávají data formulářů odeslaná uživatelem, protože to zpřístupňuje vaši aplikaci útokům CSRF.

A POST pro:

• /todo z formuláře vygenerovaného / koncovým bodem bude úspěšný, protože token antiforgery je platný.
• /todo z formuláře generovaného /SkipToken selže, protože antiforgery není zahrnutý.
• /todo2 z formuláře vytvořeného koncovým bodem /DisableAntiforgery proběhne úspěšně, protože ochrana proti padělání není vyžadována.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Při odeslání formuláře bez platného antiforgery tokenu:

• Ve prostředí Development se vyvolá výjimka.
• V prostředí Production je zaznamenána zpráva.

Omezení metod HTTP a interakce s HttpMethodOverrideMiddleware

Pro cestu AntiforgeryMiddleware ochrany proti padělání založenou na middlewaru UseAntiforgery() ověřují tokeny ochrany proti padělání pouze pro požadavky HTTP POST, PUT a PATCH. Jiné metody HTTP, například DELETE, se neověřují automaticky.

Pokud chcete ověřit tokeny proti padělání požadavků pro jiné metody HTTP, získejte IAntiforgery z DI a explicitně zavolejte ValidateRequestAsync nebo IsRequestValidAsync:

app.MapDelete("/item/{id}", async (int id, IAntiforgery antiforgery, HttpContext context) =>
{
    await antiforgery.ValidateRequestAsync(context);
    // Process the DELETE request
});

Upozornění

Pokud je HttpMethodOverrideMiddleware nakonfigurován s FormFieldName (režim pole formuláře) a umístěn před AntiforgeryMiddleware, lze požadavek POST přepsat na DELETE (nebo jinou neověřovanou metodu). Protože AntiforgeryMiddleware ověřuje pouze POST, PUT a PATCH, přepsaný požadavek obchází antiforgery ověřování.

Ochrana těchto koncových bodů:

• Preferujte umístění HttpMethodOverrideMiddleware po ověření antiforgery, pokud to kanál umožňuje.
• Vyhněte se přepsání polí formuláře pro koncové body, které spoléhají na ověřování proti padělání.
• Pokud se musí nejprve spustit přepsání pole formuláře, ověřte token antiforgery explicitně pomocí IAntiforgery.ValidateRequestAsync.

Podrobnosti o konfiguraci najdete v ASP.NET Core middlewaru.

Ověřování systému Windows a antiforgery cookies

Při použití ověřování systému Windows musí být koncové body aplikací chráněné proti útokům CSRF stejným způsobem jako u souborů cookie. Prohlížeč implicitně odesílá kontext ověřování na server a koncové body, které musí být chráněné před útoky CSRF.

Rozšířit antifalšování

Tento IAntiforgeryAdditionalDataProvider typ umožňuje vývojářům rozšířit chování systému anti-CSRF tím, že v každém tokenu přetáhne další data. Metoda GetAdditionalData se volá při každém vygenerování tokenu pole a návratová hodnota se vloží do vygenerovaného tokenu. Implementátor by mohl vrátit časové razítko, náhodné číslo nebo jinou hodnotu a potom zavolat ValidateAdditionalData k ověření těchto dat, když se token ověřuje. Uživatelské jméno klienta je již vloženo do vygenerovaných tokenů, takže tyto informace nemusíte obsahovat. Pokud token obsahuje doplňková data, ale není nakonfigurovaná žádná IAntiForgeryAdditionalDataProvider , doplňková data se neověřují.

Další materiály

• Hostování ASP.NET Core ve webové farmě