Verhindern von Websiteübergreifenden Anforderungsfälschungsangriffen (XSRF/CSRF) in ASP.NET Core

Von Fiyaz Hasan, Rick Andersonund Steve Smith

Websiteübergreifende Anforderungsfälschung (auch bekannt als XSRF oder CSRF) ist ein Angriff auf im Web gehostete Apps, bei dem eine schädliche Web-App die Interaktion zwischen einem Clientbrowser und einer Web-App beeinflussen kann, die diesem Browser vertraut. Diese Angriffe sind möglich, da Webbrowser bei jeder Anforderung an eine Website automatisch einige Arten von Authentifizierungstoken senden. Diese Art von Exploit wird auch als Ein-Klick-Angriff oder Sitzungsangriff bezeichnet, da der Angriff die zuvor authentifizierte Sitzung des Benutzers nutzt.

Ein Beispiel für einen CSRF-Angriff:

  1. Ein Benutzer wird mithilfe der www.good-banking-site.com Formularauthentifizierung bei der -Authentifizierung authentifiziert. Der Server authentifiziert den Benutzer und gibt eine Antwort aus, die eine Authentifizierung cookie enthält. Die Website ist anfällig für Angriffe, da sie jeder empfangenen Anforderung mit einer gültigen Authentifizierung cookie vertraut.

  2. Der Benutzer besucht eine schädliche Website, www.bad-crook-site.com .

    Die schädliche Website www.bad-crook-site.com enthält ein HTML-Formular ähnlich dem folgenden:

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

    Beachten Sie, dass die Beiträge des action Formulars an die anfällige Website und nicht an die schädliche Website veröffentlicht werden. Dies ist der "standortübergreifende" Teil von CSRF.

  3. Der Benutzer wählt die Schaltfläche "Senden" aus. Der Browser führt die Anforderung aus und schließt automatisch die Authentifizierung cookie für die angeforderte Domäne ein. www.good-banking-site.com

  4. Die Anforderung wird auf dem Server mit dem Authentifizierungskontext des Benutzers ausgeführt und kann jede Aktion ausführen, die ein www.good-banking-site.com authentifizierter Benutzer ausführen darf.

Zusätzlich zu dem Szenario, in dem der Benutzer die Schaltfläche zum Übermitteln des Formulars auswählt, könnte die schädliche Website folgende Aktionen unternehmen:

  • Führen Sie ein Skript aus, das das Formular automatisch übermittelt.
  • Senden Sie die Formularübermittlung als AJAX-Anforderung.
  • Blenden Sie das Formular mit CSS aus.

Für diese alternativen Szenarien sind keine Aktionen oder Eingaben des Benutzers erforderlich, außer die böswillige Website zu besuchen.

Die Verwendung von HTTPS verhindert keinen CSRF-Angriff. Die schädliche Website kann eine https://www.good-banking-site.com/ Anforderung genauso einfach wie eine unsichere Anforderung senden.

Einige Angriffe zielen auf Endpunkte ab, die auf GET-Anforderungen reagieren. In diesem Fall kann ein Imagetag verwendet werden, um die Aktion auszuführen. Diese Form von Angriffen wird häufig auf Forumwebsites verwendet, die Bilder zulassen, javaScript jedoch blockieren. Apps, die den Zustand bei GET-Anforderungen ändern, bei denen Variablen oder Ressourcen geändert werden, sind anfällig für böswillige Angriffe. GET-Anforderungen, die den Zustand ändern, sind unsicher. Eine bewährte Methode besteht darin, den Zustand einer GET-Anforderung nie zu ändern.

CSRF-Angriffe sind aus folgenden Gründen gegen Web-Apps möglich, die s für die cookie Authentifizierung verwenden:

  • Browser speichern cookie von einer Web-App ausgegebene .
  • Gespeicherte cookie s enthalten cookie Sitzungs-s für authentifizierte Benutzer.
  • Browser senden alle einer cookie Domäne zugeordneten s an die Web-App, unabhängig davon, wie die Anforderung an die App im Browser generiert wurde.

CSRF-Angriffe sind jedoch nicht auf cookie Exploits beschränkt. Beispielsweise sind die Standard- und Digestauthentifizierung ebenfalls anfällig. Nachdem sich ein Benutzer mit der Standard- oder Digestauthentifizierung anmeldet, sendet der Browser die Anmeldeinformationen automatisch, bis die Sitzung † endet.

†In diesem Kontext bezieht sich session auf die clientseitige Sitzung, während der der Benutzer authentifiziert wird. Sie steht in keinem Zusammenhang mit serverseitigen Sitzungen oder ASP.NET Core Session Middleware.

Benutzer können sich vor CSRF-Sicherheitsrisiken schützen, indem sie Vorsichtsmaßnahmen treffen:

  • Melden Sie sich von Web-Apps ab, wenn Sie sie nicht mehr verwenden.
  • Deaktivieren Sie cookie die Browser in regelmäßigen Abständen.

CSRF-Sicherheitsrisiken sind jedoch im Wesentlichen ein Problem mit der Web-App, nicht mit dem Endbenutzer.

Grundlagen der Authentifizierung

CookieDie -basierte Authentifizierung ist eine beliebte Form der Authentifizierung. Tokenbasierte Authentifizierungssysteme werden immer beliebter, insbesondere bei Single-Page-Anwendungen (SPAs).

Wenn sich ein Benutzer mit dem Benutzernamen und Kennwort authentifiziert, wird ein Token ausgestellt, das ein Authentifizierungsticket enthält, das für die Authentifizierung und Autorisierung verwendet werden kann. Das Token wird als gespeichert, cookie das jede Vom Client ausgeführte Anforderung begleitet. Das Generieren und Überprüfen wird cookie von der Middleware für die Cookie Authentifizierung durchgeführt. Die Middleware serialisiert einen Benutzerprinzipal in einen verschlüsselten cookie . Bei nachfolgenden Anforderungen überprüft die Middleware , erstellt den Prinzipal neu und weist den Prinzipal der cookie User-Eigenschaft von HttpContext zu.

Tokenbasierte Authentifizierung

Wenn ein Benutzer authentifiziert wird, wird ein Token ausgestellt (kein Antifälschungstoken). Das Token enthält Benutzerinformationen in Form von Ansprüchen oder ein Verweistoken, das die App auf den in der App verwalteten Benutzerzustand verweist. Wenn ein Benutzer versucht, auf eine Ressource zu zugreifen, die eine Authentifizierung erfordert, wird das Token mit einem zusätzlichen Autorisierungsheader in Form eines Bearertokens an die App gesendet. Dadurch wird die App zustandslos. In jeder nachfolgenden Anforderung wird das Token in der Anforderung für die serverseitige Validierung übergeben. Dieses Token ist nicht verschlüsselt. ist codiert. Auf dem Server wird das Token decodiert, um auf seine Informationen zu zugreifen. Um das Token bei nachfolgenden Anforderungen zu senden, speichern Sie das Token im lokalen Speicher des Browsers. Machen Sie sich keine Sorgen über csrf-Sicherheitsrisiko, wenn das Token im lokalen Speicher des Browsers gespeichert ist. CSRF ist ein Problem, wenn das Token in einem gespeichert cookie wird. Weitere Informationen finden Sie im GitHub-Issue SPA-Codebeispiel fügt zwei cookie s hinzu.

Mehrere Apps, die in einer Domäne gehostet werden

Freigegebene Hostingumgebungen sind anfällig für Session Hijacking, Anmelde-CSRF und andere Angriffe.

Obwohl example1.contoso.net und example2.contoso.net unterschiedliche Hosts sind, besteht eine implizite Vertrauensstellung zwischen Hosts unter der *.contoso.net Domäne. Diese implizite Vertrauensstellung ermöglicht es potenziell nicht vertrauenswürdigen Hosts, sich gegenseitig zu beeinflussen cookie (die Richtlinien desselben Ursprungs, die AJAX-Anforderungen regeln, gelten nicht unbedingt für cookie HTTP-S).

Angriffe, die vertrauenswürdige S zwischen Apps ausnutzen, cookie die in derselben Domäne gehostet werden, können verhindert werden, indem Domänen nicht gemeinsam genutzt werden. Wenn jede App in ihrer eigenen Domäne gehostet wird, besteht keine implizite cookie Vertrauensstellung, die ausgenutzt werden kann.

ASP.NET Core-Antifälschungskonfiguration

Warnung

ASP.NET Core implementiert Mithilfe von ASP.NET Core Data ProtectionAntifälschung. Der Datenschutzstapel muss für die Arbeit in einer Serverfarm konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren des Schutzes von Daten.

Antiforgery-Middleware wird dem Dependency Injection-Container hinzugefügt, wenn eine der folgenden APIs in aufgerufen Startup.ConfigureServices wird:

Antiforgery-Middleware wird dem Dependency Injection-Container hinzugefügt, wenn AddMvc in aufgerufen wird. Startup.ConfigureServices

In ASP.NET Core 2.0 oder höher fügt FormTagHelper Antifälschungstoken in HTML-Formularelemente ein. Das folgende Markup in einer Razor Datei generiert automatisch Antifälschungstoken:

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

Analog dazu generiert IHtmlHelper.BeginForm standardmäßig Antifälschungstoken, wenn die -Methode des Formulars nicht GET ist.

Die automatische Generierung von Antifälschungstoken für HTML-Formularelemente erfolgt, wenn das <form> -Tag das -Attribut enthält und einer der folgenden Punkte method="post" zutrifft:

  • Das Aktionsattribut ist leer ( action="" ).
  • Das Aktionsattribut wird nicht angegeben ( <form method="post"> ).

Die automatische Generierung von Antifälschungstoken für HTML-Formularelemente kann deaktiviert werden:

  • Deaktivieren Sie Fälschungsschutztoken explizit mit dem asp-antiforgery -Attribut:

    <form method="post" asp-antiforgery="false">
        ...
    </form>
    
  • Das Formularelement wird mithilfe des Symbols Tag Helper ! opt-out von Tag-Hilfsatoren abgemeldet:

    <!form method="post">
        ...
    </!form>
    
  • Entfernen Sie FormTagHelper aus der Ansicht. Der FormTagHelper kann aus einer Ansicht entfernt werden, indem der Ansicht die folgende -Direktive hinzugefügt Razor wird:

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

Hinweis

Razor Seiten werden automatisch vor XSRF/CSRF geschützt. Weitere Informationen finden Sie unter XSRF/CSRF und Razor Pages.

Der gängigste Ansatz zum Schutz vor CSRF-Angriffen ist die Verwendung des Synchronizer Token Pattern (STP). STP wird verwendet, wenn der Benutzer eine Seite mit Formulardaten an fordert:

  1. Der Server sendet ein Token, das der Identität des aktuellen Benutzers zugeordnet ist, an den Client.
  2. Der Client sendet das Token zur Überprüfung an den Server zurück.
  3. Wenn der Server ein Token empfängt, das nicht mit der Identität des authentifizierten Benutzers übereinstimmen kann, wird die Anforderung abgelehnt.

Das Token ist eindeutig und unvorhersehbar. Das Token kann auch verwendet werden, um eine ordnungsgemäße Sequenzierung einer Reihe von Anforderungen sicherzustellen (z. B. sicherstellen, dass die Anforderungssequenz von: Seite 1 > Seite 2 > Seite 3). Alle Formulare in ASP.NET Core MVC- und Razor Pages-Vorlagen generieren Fälschungsschutztoken. In den folgenden Ansichtsbeispielen werden Fälschungsschutztoken generiert:

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

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

Fügen Sie einem -Element explizit ein Antifälschungstoken hinzu, ohne <form> Tag-Hilfselemente mit dem HTML-Hilfselement zu @Html.AntiForgeryToken verwenden:

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

In jedem der obigen Fälle fügt ASP.NET Core ein ausgeblendetes Formularfeld ähnlich dem folgenden hinzu:

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

ASP.NET Core enthält drei Filter für die Arbeit mit Fälschungsschutztoken:

Antifälschungsoptionen

Anpassen von Antifälschungsoptionen in Startup.ConfigureServices :

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

†Legen Sie die Cookie Antifälschungseigenschaften mithilfe der Eigenschaften der Cookie Builder-Klasse fest.

Option Beschreibung
Cookie Bestimmt die Einstellungen, die zum Erstellen der Antifälschungen verwendet cookie werden.
FormFieldName Der Name des ausgeblendeten Formularfelds, das vom Fälschungsschutzsystem zum Rendern von Antifälschungstoken in Ansichten verwendet wird.
Headername Der Name des Headers, der vom Fälschungsschutzsystem verwendet wird. gibt null an, dass das System nur Formulardaten berücksichtigt.
SuppressXFrameOptionsHeader Gibt an, ob die Generierung des Headers unterdrückt werden X-Frame-Options soll. Standardmäßig wird der Header mit dem Wert "SAMEORIGIN" generiert. Der Standardwert lautet 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;
});
Option Beschreibung
Cookie Bestimmt die Einstellungen, die zum Erstellen der Antifälschungen verwendet cookie werden.
CookieDomäne Die Domäne des cookie . Der Standardwert lautet null. Diese Eigenschaft ist veraltet und wird in einer zukünftigen Version entfernt. Die empfohlene Alternative ist Cookie . Domäne.
CookieNamen Der Name von cookie. Wenn diese Einstellung nicht festgelegt ist, generiert das System einen eindeutigen Namen, der mit dem Cookie Standardpräfix (". AspNetCore.Antiforgery."). Diese Eigenschaft ist veraltet und wird in einer zukünftigen Version entfernt. Die empfohlene Alternative ist Cookie . Namen.
CookiePfad Der pfad, der für festgelegt cookie ist. Diese Eigenschaft ist veraltet und wird in einer zukünftigen Version entfernt. Die empfohlene Alternative ist Cookie . Pfad.
FormFieldName Der Name des ausgeblendeten Formularfelds, das vom Fälschungsschutzsystem zum Rendern von Fälschungstoken in Ansichten verwendet wird.
Headername Der Name des Headers, der vom Antifälschungssystem verwendet wird. Gibt null an, dass das System nur Formulardaten berücksichtigt.
Requiressl Gibt an, ob HTTPS für das Antifälschungssystem erforderlich ist. Gibt true an, dass Nicht-HTTPS-Anforderungen fehlschlagen. Der Standardwert lautet false. Diese Eigenschaft ist veraltet und wird in einer zukünftigen Version entfernt. Die empfohlene Alternative ist das Festlegen Cookie von . SecurePolicy.
SuppressXFrameOptionsHeader Gibt an, ob die Generierung des Headers unterdrückt X-Frame-Options werden soll. Standardmäßig wird der Header mit dem Wert "SAMEORIGIN" generiert. Der Standardwert lautet false.

Weitere Informationen finden Sie unter Cookie AuthenticationOptions.

Konfigurieren von Antifälschungsfunktionen mit IAntiforgery

IAntiforgery stellt die API zum Konfigurieren von Antifälschungsfunktionen bereit. IAntiforgery kann in der Configure -Methode der -Klasse angefordert Startup werden. Im folgenden Beispiel wird Middleware von der Startseite der App verwendet, um ein Antifälschungstoken zu generieren und es in der Antwort als zu senden cookie (mithilfe der angular-Standardbenennungskonvention, die weiter unten in diesem Thema beschrieben wird):

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

Anforgery-Überprüfung erforderlich

ValidateAntiForgeryToken ist ein Aktionsfilter, der auf eine einzelne Aktion, einen Controller oder global angewendet werden kann. Anforderungen an Aktionen, auf die dieser Filter angewendet wird, werden blockiert, es sei denn, die Anforderung enthält ein gültiges Antifälschungstoken.

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

Das ValidateAntiForgeryToken -Attribut erfordert ein Token für Anforderungen an die markierten Aktionsmethoden, einschließlich HTTP GET-Anforderungen. Wenn das ValidateAntiForgeryToken Attribut auf die Controller der App angewendet wird, kann es mit dem -Attribut überschrieben IgnoreAntiforgeryToken werden.

Hinweis

ASP.NET Core unterstützt das automatische Hinzufügen von Antifälschungstoken zu GET-Anforderungen nicht.

Automatisches Überprüfen von Antifälschungstoken nur für unsichere HTTP-Methoden

ASP.NET Core-Apps generieren keine Antifälschungstoken für sichere HTTP-Methoden (GET, HEAD, OPTIONS und TRACE). Anstatt das Attribut umfassend anzuwenden ValidateAntiForgeryToken und dann mit Attributen zu überschreiben, IgnoreAntiforgeryToken kann das AutoValidateAntiforgeryToken-Attribut verwendet werden. Dieses Attribut funktioniert identisch mit dem ValidateAntiForgeryToken -Attribut, erfordert jedoch keine Token für Anforderungen, die mit den folgenden HTTP-Methoden ausgeführt werden:

  • GET
  • HEAD
  • OPTIONS
  • TRACE

Es wird empfohlen, für AutoValidateAntiforgeryToken Nicht-API-Szenarien allgemein zu verwenden. Dadurch wird sichergestellt, dass POST-Aktionen standardmäßig geschützt sind. Die Alternative besteht darin, Antifälschungstoken standardmäßig zu ignorieren, es sei denn, ValidateAntiForgeryToken wird auf einzelne Aktionsmethoden angewendet. In diesem Szenario ist es wahrscheinlicher, dass eine POST-Aktionsmethode versehentlich nicht geschützt bleibt, sodass die App anfällig für CSRF-Angriffe bleibt. Alle POSTs sollten das Antifälschungstoken senden.

APIs verfügen nicht über einen automatischen Mechanismus zum Senden des cookie Nichtteils des Tokens. Die Implementierung hängt wahrscheinlich von der Implementierung des Clientcodes ab. Im Folgenden finden Sie einige Beispiele:

Beispiel auf Klassenebene:

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

Globales Beispiel:

Dienstleistungen. AddMvc(options => Optionen. Filters.Add(new AutoValidateAntiforgeryTokenAttribute()));

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

Globale Oder Controller-Antifälschungsattribute überschreiben

Der Filter IgnoreAntiforgeryToken wird verwendet, um die Notwendigkeit eines Fälschungsschutztokens für eine bestimmte Aktion (oder einen Controller) zu vermeiden. Wenn dieser Filter angewendet wird, überschreibt und filtert er, die auf einer höheren Ebene ValidateAntiForgeryToken AutoValidateAntiforgeryToken (global oder auf einem Controller) angegeben sind.

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

Aktualisieren von Token nach der Authentifizierung

Token sollten aktualisiert werden, nachdem der Benutzer authentifiziert wurde, indem der Benutzer zu einer Ansicht oder Razor Seitenseite umgeleitet wird.

JavaScript, AJAX und SPAs

In herkömmlichen HTML-basierten Apps werden Fälschungsschutztoken mithilfe ausgeblendeter Formularfelder an den Server übergeben. In modernen JavaScript-basierten Apps und SPAs werden viele Anforderungen programmgesteuert gestellt. Diese AJAX-Anforderungen können andere Techniken (z. B. Anforderungsheader cookie oder s) verwenden, um das Token zu senden.

Wenn cookie s zum Speichern von Authentifizierungstoken und zum Authentifizieren von API-Anforderungen auf dem Server verwendet werden, ist CSRF ein potenzielles Problem. Wenn der lokale Speicher zum Speichern des Tokens verwendet wird, kann das CSRF-Sicherheitsrisiko verringert werden, da Werte aus dem lokalen Speicher nicht bei jeder Anforderung automatisch an den Server gesendet werden. Daher wird empfohlen, den lokalen Speicher zum Speichern des Fälschungsschutztokens auf dem Client zu verwenden und das Token als Anforderungsheader zu senden.

JavaScript

Wenn Sie JavaScript mit Ansichten verwenden, kann das Token mithilfe eines Diensts in der Ansicht erstellt werden. Injizieren Sie den Dienst Microsoft.AspNetCore.Antiforgery.IAntiforgery in die Ansicht, und rufen Sie GetAndStoreTokens auf:

@{
    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>

Bei diesem Ansatz entfällt die Notwendigkeit, direkt mit dem Festlegen von s vom Server oder dem cookie Lesen vom Client zu umgehen.

Im vorherigen Beispiel wird JavaScript verwendet, um den ausgeblendeten Feldwert für den AJAX POST-Header zu lesen.

JavaScript kann auch auf Token in s zugreifen cookie und den Inhalt von cookie verwenden, um einen Header mit dem Tokenwert zu erstellen.

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

Angenommen, das Skript fordert an, das Token in einem Header namens zu X-CSRF-TOKEN senden, konfigurieren Sie den Antiforgery-Dienst so, dass er nach dem X-CSRF-TOKEN Header sucht:

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

Im folgenden Beispiel wird JavaScript verwendet, um eine AJAX-Anforderung mit dem entsprechenden Header zu erstellen:

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 verwendet eine Konvention, um CSRF zu behandeln. Wenn der Server eine cookie mit dem Namen XSRF-TOKEN sendet, fügt der AngularJS-Dienst $http den Wert einem Header cookie hinzu, wenn er eine Anforderung an den Server sendet. Dieser Prozess erfolgt automatisch. Der Header muss im Client nicht explizit festgelegt werden. Der Headername lautet X-XSRF-TOKEN . Der Server sollte diesen Header erkennen und seinen Inhalt überprüfen.

Damit ASP.NET Core-API bei Ihrem Anwendungsstart mit dieser Konvention funktioniert:

  • Konfigurieren Sie Ihre App so, dass sie ein Token in einem cookie namens XSRF-TOKEN bereitstellt.
  • Konfigurieren Sie den Antifälschungsdienst so, dass nach einem Header mit dem Namen gesucht X-XSRF-TOKEN wird.
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");
}

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Windows-Authentifizierung und cookie Fälschungsschutz

Bei Verwendung der Windows-Authentifizierung müssen Anwendungsendpunkte auf die gleiche Weise wie bei s vor CSRF-Angriffen geschützt cookie werden. Der Browser sendet implizit den Authentifizierungskontext an den Server. Daher müssen Endpunkte vor CSRF-Angriffen geschützt werden.

Erweitern der Antifälschung

Mit dem IAntiForgeryAdditionalDataProvider-Typ können Entwickler das Verhalten des Anti-CSRF-Systems erweitern, indem zusätzliche Daten in jedem Token per Roundtrip übertragen werden. Die GetAdditionalData-Methode wird jedes Mal aufgerufen, wenn ein Feldtoken generiert wird, und der Rückgabewert wird in das generierte Token eingebettet. Ein Implementierer kann einen Zeitstempel, eine Nonce oder einen anderen Wert zurückgeben und dann ValidateAdditionalData aufrufen, um diese Daten zu überprüfen, wenn das Token überprüft wird. Der Benutzername des Clients ist bereits in die generierten Token eingebettet, sodass diese Informationen nicht enthalten sein müssen. Wenn ein Token zusätzliche Daten enthält, aber keine konfiguriert ist, werden die zusätzlichen Daten IAntiForgeryAdditionalDataProvider nicht überprüft.

Zusätzliche Ressourcen