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

Fiyaz Hasan, Rick Andersona Steve Smith

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

Příklad útoku CSRF:

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

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

   Škodlivý web www.bad-crook-site.com obsahuje formulář HTML podobný následujícímu:

   <h1>Congratulations! You're a Winner!</h1>
   <form action="http://good-banking-site.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 příspěvky action formuláře na zranitelný web, nikoli na škodlivý web. Toto je část CSRF "mezi weby".

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

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

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

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

Tyto alternativní scénáře nevyžadují žádnou akci ani vstup od uživatele kromě toho, že na začátku navštíví škodlivý web.

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

Některé útoky cílí na koncové body, které reagují na požadavky GET. V takovém případě je možné k provedení akce použít značku image. Tato forma útoku je běžná na webech ve fórech, které povolují 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é mění stav, jsou nezabezpečené. Osvědčeným postupem je nikdy změnit stav požadavku GET.

Útoky CSRF jsou možné proti webovým aplikacím, které k cookie ověřování používají s, protože:

• Obchody cookie s prohlížeči vystavené webovou aplikací.
• Uložené cookie relace zahrnují relace pro cookie ověřené uživatele.
• Prohlížeče odesílaly všechny y přidružené k doméně do webové aplikace každý požadavek bez ohledu na to, jak se požadavek na aplikaci cookie vygeneroval v prohlížeči.

Útoky CSRF se ale omezují na cookie zneužití. Ohrožené jsou například také základní ověřování a ověřování hodnotou hash. Jakmile se uživatel přihlásí pomocí základního ověřování nebo ověřování hodnotou hash, prohlížeč automaticky odešle přihlašovací údaje, dokud relace † neskončí.

†V tomto kontextu relace odkazuje na relaci na straně klienta, během které je uživatel ověřen. Nesouvisí s relacemi na straně serveru ani ASP.NET Core middlewaru relace.

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

• Po dokončení jejich používání webové aplikace odhlásit.
• Pravidelně cookie vymažte soubory prohlížeče.

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

Základy ověřování

CookieOvěřování založené na systému je oblíbenou formou ověřování. Systémy ověřování založené na tokenech narůstají na popularitě, zejména u jedno stránkových aplikací (SPA).

CookieOvěřování na základě

Když se uživatel ověří pomocí svého uživatelského jména a hesla, vydá se token obsahující ověřovací lístek, který se může použít k ověřování a autorizaci. Token se uloží jako , cookie který doprovází každý požadavek, který klient provede. K vygenerování cookie a ověření se používá ověřovací Cookie middleware. Middleware serializuje objekt zabezpečení uživatele do šifrovaného cookie objektu . V následných požadavcích middleware ověří , znovu vytvoří objekt zabezpečení a přiřadí objekt zabezpečení k vlastnosti cookie User objektu HttpContext.

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

Při ověření uživatele se uživateli vystaví token (ne token proti padělku). Token obsahuje informace o uživateli ve formě deklarací identity nebo referenční token, který odkazuje aplikaci na stav uživatele udržovaný v aplikaci. Když se uživatel pokusí o přístup k prostředku, který vyžaduje ověření, token se do aplikace odesílá s další autorizační hlavičkou ve formě bearer tokenu. Díky tomu je aplikace beze stavu. 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 kódovaný . Na serveru je token dekódovaný pro přístup k jeho informacím. Pokud chcete token odeslat při následných požadavcích, uložte ho do místního úložiště prohlížeče. Pokud je token uložený v místním úložišti prohlížeče, nedělejte si starosti s ohrožením zabezpečení CSRF. CSRF je problém, když je token uložený v cookie . Další informace najdete v ukázce kódu SPA GitHub problém přidává cookie dvě.

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

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

Přestože example1.contoso.net example2.contoso.net jsou a různými hostiteli, 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 na sebe navzájem (zásady stejného původu, které řídí požadavky AJAX nemusí nutně platit cookie pro cookie HTTP).

Útokům, které zneužívají důvěryhodné domény mezi aplikacemi hostovaným ve stejné doméně, se může zabránit cookie tím, že domény nesídí. Pokud je každá aplikace hostovaná ve vlastní doméně, neexistuje žádný implicitní cookie vztah důvěryhodnosti, který by bylo možné zneužít.

ASP.NET Core proti padělku

Ve ASP.NET Core verze 2.0 nebo novější vloží formovací třída FormTagHelper tokeny proti padělkům do prvků formuláře HTML. Následující kód v souboru Razor automaticky generuje tokeny proti padělkům:

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

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

Automatické generování tokenů proti padělkům pro prvky formuláře HTML nastane, když značka obsahuje atribut a platí která <form> method="post" z následujících podmínek:

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

Automatické generování tokenů proti padělkům pro prvky formuláře HTML je možné zakázat:

• Explicitně zakažte tokeny proti padělkům s asp-antiforgery atributem :

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

• Element formuláře je výslovně odhlásit z pomocných prvků značek pomocí symbolu pro odhlášení pomocných prvků značek! :

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

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

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

Nejběžnějším přístupem k obraně před útoky CSRF je použití vzorce 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 serveru k ověření.
3. Pokud server obdrží token, který neodpovídá identitě ověřeného uživatele, požadavek se zamítne.

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

<form asp-controller="Todo" asp-action="Create" method="post">
    ...
</form>

@using (Html.BeginForm("Create", "Todo"))
{
    ...
}

Explicitní přidání tokenu proti padělku do elementu bez použití pomocných prvků značek <form> pomocí pomocné pomocníka @Html.AntiForgeryToken HTML:

<form action="/" method="post">
    @Html.AntiForgeryToken()
</form>

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

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

ASP.NET Core obsahuje tři filtry pro práci s tokeny proti padělkům:

• ValidateAntiForgeryToken
• AutoValidateAntiforgeryToken
• IgnoreAntiforgeryToken

Možnosti proti padělku

Přizpůsobení možností proti padělku v Startup.ConfigureServices nástroji :

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

services.AddAntiforgery(options => 
{
    options.CookieDomain = "contoso.com";
    options.CookieName = "X-CSRF-TOKEN-COOKIENAME";
    options.CookiePath = "Path";
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-HEADERNAME";
    options.RequireSsl = false;
    options.SuppressXFrameOptionsHeader = false;
});

Další informace najdete v tématu Cookie AuthenticationOptions.

Konfigurace funkcí proti padělku pomocí IAntiforgery

IAntiforgery poskytuje rozhraní API pro konfiguraci funkcí proti padělku. IAntiforgery lze vyžádat Configure v metodě Startup třídy . Následující příklad používá middleware z domovské stránky aplikace k vygenerování tokenu proti padělku a jeho odeslání v odpovědi jako (pomocí výchozí konvence vytváření názvů Angular, která je popsaná dále v cookie tomto tématu):

public void Configure(IApplicationBuilder app, IAntiforgery antiforgery)
{
    app.Use(next => context =>
    {
        string path = context.Request.Path.Value;

        if (
            string.Equals(path, "/", StringComparison.OrdinalIgnoreCase) ||
            string.Equals(path, "/index.html", StringComparison.OrdinalIgnoreCase))
        {
            // The request token can be sent as a JavaScript-readable cookie, 
            // and Angular uses it by default.
            var tokens = antiforgery.GetAndStoreTokens(context);
            context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken, 
                new CookieOptions() { HttpOnly = false });
        }

        return next(context);
    });
}

Vyžadování ověření proti padělku

ValidateAntiForgeryToken je filtr akcí, který se může použít u jednotlivých akcí, kontroleru nebo globálně. Požadavky na akce s použitým tímto filtrem se zablokují, pokud požadavek nebude obsahovat platný token proti padělku.

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> RemoveLogin(RemoveLoginViewModel account)
{
    ManageMessageId? message = ManageMessageId.Error;
    var user = await GetCurrentUserAsync();

    if (user != null)
    {
        var result = 
            await _userManager.RemoveLoginAsync(
                user, account.LoginProvider, account.ProviderKey);

        if (result.Succeeded)
        {
            await _signInManager.SignInAsync(user, isPersistent: false);
            message = ManageMessageId.RemoveLoginSuccess;
        }
    }

    return RedirectToAction(nameof(ManageLogins), new { Message = message });
}

Atribut ValidateAntiForgeryToken vyžaduje token pro požadavky na metody akcí, které označuje, včetně požadavků HTTP GET. Pokud je ValidateAntiForgeryToken atribut použit napříč kontrolery aplikace, je možné ho přepsat IgnoreAntiforgeryToken atributem .

Automatické ověření tokenů proti padělkům pouze pro nebezpečné metody HTTP

ASP.NET Core negenerují tokeny proti padělkům pro bezpečné metody HTTP (GET, HEAD, OPTIONS a TRACE). Místo širšího použití atributu a jeho přepsání atributy lze použít atribut ValidateAntiForgeryToken IgnoreAntiforgeryToken AutoValidateAntiforgeryToken. Tento atribut funguje stejně jako atribut s tím rozdílem, že nevyžaduje tokeny pro požadavky provedené ValidateAntiForgeryToken pomocí následujících metod HTTP:

• GET
• HEAD
• MOŽNOSTI
• TRACE

Pro scénáře mimo rozhraní API doporučujeme používat AutoValidateAntiforgeryToken širokou škálu možností. Tím se zajistí, že akce POST budou ve výchozím nastavení chráněné. Alternativou je ve výchozím nastavení ignorovat tokeny proti padělkům, pokud se na jednotlivé ValidateAntiForgeryToken metody akcí nepouží. V tomto scénáři je pravděpodobnější, že metoda akce POST omylem ponechává nechráněnou, takže aplikace je zranitelná vůči útokům CSRF. Všechny posměšné soubory by měly odeslat token proti padělku.

Rozhraní API nemají automatický mechanismus pro odesílání tokenu, který není cookie součástí tokenu. Implementace pravděpodobně závisí na implementaci klientského kódu. Tady je několik příkladů:

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

[Authorize]
[AutoValidateAntiforgeryToken]
public class ManageController : Controller
{

Globální příklad:

services.AddControllersWithViews(options =>
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute()));

Přepsání globálních atributů nebo atributů proti padělku kontroleru

Filtr IgnoreAntiforgeryToken slouží k eliminaci potřeby tokenu proti padělku pro danou akci (nebo kontroler). Při použití se tato přepsání filtru a filtry zapíšou na vyšší úrovni ValidateAntiForgeryToken AutoValidateAntiforgeryToken (globálně nebo na kontroleru).

[Authorize]
[AutoValidateAntiforgeryToken]
public class ManageController : Controller
{
    [HttpPost]
    [IgnoreAntiforgeryToken]
    public async Task<IActionResult> DoSomethingSafe(SomeViewModel model)
    {
        // no antiforgery token required
    }
}

Aktualizace tokenů po ověření

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

JavaScript, AJAX a rozhraní SPA

V tradičních aplikacích založených na HTML se tokeny proti padělkům předaly serveru pomocí skrytých polí formuláře. V moderních aplikacích založených na JavaScriptu a na SSP se mnoho požadavků provádí programově. Tyto požadavky AJAX mohou k odeslání tokenu použít jiné techniky (například hlavičky požadavků nebo cookie s).

Pokud se k ukládání ověřovacích tokenů a ověřování požadavků rozhraní API na serveru používají cookie y, CSRF je potenciální problém. Pokud se k uložení tokenu používá místní úložiště, může dojít ke zmírnění ohrožení zabezpečení CSRF, protože hodnoty z místního úložiště se při každém požadavku automaticky neposílané na server. Proto se doporučuje použít místní úložiště k uložení tokenu proti padělku na straně klienta a odeslat token jako hlavičku požadavku.

JavaScript

Pomocí JavaScriptu se zobrazeními je možné token vytvořit pomocí služby v rámci zobrazení. Do zobrazení vložte službu Microsoft.AspNetCore.Antiforgery.IAntiforgery a zavolejte GetAndStoreTokens:

@{
    ViewData["Title"] = "AJAX Demo";
}
@inject Microsoft.AspNetCore.Antiforgery.IAntiforgery Xsrf
@functions{
    public string GetAntiXsrfRequestToken()
    {
        return Xsrf.GetAndStoreTokens(Context).RequestToken;
    }
}

<input type="hidden" id="RequestVerificationToken" 
       name="RequestVerificationToken" value="@GetAntiXsrfRequestToken()">

<h2>@ViewData["Title"].</h2>
<h3>@ViewData["Message"]</h3>

<div class="row">
    <p><input type="button" id="antiforgery" value="Antiforgery"></p>
    <script>
        var xhttp = new XMLHttpRequest();
        xhttp.onreadystatechange = function() {
            if (xhttp.readyState == XMLHttpRequest.DONE) {
                if (xhttp.status == 200) {
                    alert(xhttp.responseText);
                } else {
                    alert('There was an error processing the AJAX request.');
                }
            }
        };

        document.addEventListener('DOMContentLoaded', function() {
            document.getElementById("antiforgery").onclick = function () {
                xhttp.open('POST', '@Url.Action("Antiforgery", "Home")', true);
                xhttp.setRequestHeader("RequestVerificationToken", 
                    document.getElementById('RequestVerificationToken').value);
                xhttp.send();
            }
        });
    </script>
</div>

Tento přístup eliminuje nutnost řešit přímo nastavení ze serveru nebo je cookie číst z klienta.

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

JavaScript může také přistupovat k tokenům v souboru s a pomocí jeho obsahu vytvořit hlavičku s cookie cookie hodnotou tokenu.

context.Response.Cookies.Append("CSRF-TOKEN", tokens.RequestToken, 
    new Microsoft.AspNetCore.Http.CookieOptions { HttpOnly = false });

Za předpokladu, že skript požádá o odeslání tokenu v hlavičce s názvem , nakonfigurujte službu proti padělku tak, aby hlavičku X-CSRF-TOKEN X-CSRF-TOKEN vyhleděla:

services.AddAntiforgery(options => options.HeaderName = "X-CSRF-TOKEN");

Následující příklad používá JavaScript k požadavku AJAX s příslušnou hlavičkou:

function getCookie(cname) {
    var name = cname + "=";
    var decodedCookie = decodeURIComponent(document.cookie);
    var ca = decodedCookie.split(';');
    for (var i = 0; i < ca.length; i++) {
        var c = ca[i];
        while (c.charAt(0) === ' ') {
            c = c.substring(1);
        }
        if (c.indexOf(name) === 0) {
            return c.substring(name.length, c.length);
        }
    }
    return "";
}

var csrfToken = getCookie("CSRF-TOKEN");

var xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function () {
    if (xhttp.readyState === XMLHttpRequest.DONE) {
        if (xhttp.status === 204) {
            alert('Todo item is created successfully.');
        } else {
            alert('There was an error processing the AJAX request.');
        }
    }
};
xhttp.open('POST', '/api/items', true);
xhttp.setRequestHeader("Content-type", "application/json");
xhttp.setRequestHeader("X-CSRF-TOKEN", csrfToken);
xhttp.send(JSON.stringify({ "name": "Learn C#" }));

AngularJS

AngularJS používá konvenci pro řešení CSRF. Pokud server odešle cookie s názvem XSRF-TOKEN , $http Služba AngularJS cookie při odeslání požadavku na server přidá hodnotu do hlavičky. Tento proces je automatický. Záhlaví není v klientovi nutné nastavit explicitně. Název hlavičky je X-XSRF-TOKEN . Server by měl detekovat tuto hlavičku a ověřit její obsah.

ASP.NET Core rozhraní API pro práci s touto konvencí ve vašem spuštění aplikace:

• Nakonfigurujte svou aplikaci tak, aby poskytovala token ve cookie volání XSRF-TOKEN .
• Nakonfigurujte službu proti padělání, aby hledala hlavičku s názvem X-XSRF-TOKEN .

public void Configure(IApplicationBuilder app, IAntiforgery antiforgery)
{
    app.Use(next => context =>
    {
        string path = context.Request.Path.Value;

        if (
            string.Equals(path, "/", StringComparison.OrdinalIgnoreCase) ||
            string.Equals(path, "/index.html", StringComparison.OrdinalIgnoreCase))
        {
            // The request token can be sent as a JavaScript-readable cookie, 
            // and Angular uses it by default.
            var tokens = antiforgery.GetAndStoreTokens(context);
            context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken, 
                new CookieOptions() { HttpOnly = false });
        }

        return next(context);
    });
}

public void ConfigureServices(IServiceCollection services)
{
    // Angular's default header name for sending the XSRF token.
    services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");
}

Zobrazit nebo stáhnout ukázkový kód (Jak stáhnout)

ověřování Windows a antipadělání cookie s

při použití ověřování Windows musí být koncové body aplikace chráněny před útoky CSRF stejným způsobem jako u cookie s. Prohlížeč implicitně odesílá kontext ověřování serveru, takže koncové body je potřeba chránit před CSRF útoky.

Rozšiřování antipadělání

Typ IAntiForgeryAdditionalDataProvider umožňuje vývojářům roztáhnout chování systému anti-CSRF s kulatými Trip dalšími daty v každém tokenu. Metoda GetAdditionalData je volána při každém vygenerování tokenu pole a návratová hodnota je vložena do vygenerovaného tokenu. Implementátor by mohl vrátit časové razítko, hodnotu NONCE nebo jakoukoli jinou hodnotu a pak zavolat ValidateAdditionalData , aby ověřil tato data při ověření tokenu. Uživatelské jméno klienta je již vloženo do vygenerovaných tokenů, takže není nutné tyto informace zahrnout. Pokud token zahrnuje doplňková data, ale není IAntiForgeryAdditionalDataProvider nakonfigurovaná, doplňují se data neověřují.

Další materiály

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