Verhindern von Angriffen durch websiteübergreifende Anforderungsfälschung (XSRF/CSRF) in ASP.NET Core

Von Fiyaz Hasan, Rick Anderson und Steve Smith

Websiteübergreifende Anforderungs-Fälschung (auch als XSRF oder CSRF bezeichnet) ist ein Angriff auf web gehostete Apps, bei denen eine bösartige Web-App die Interaktion zwischen einem Clientbrowser und einer Web-App beeinflussen kann, die diesem Browser vertraut. Diese Angriffe sind möglich, da Webbrowser einige Arten von Authentifizierungstoken automatisch mit jeder Anforderung an eine Website senden. Diese Form des Exploits wird auch als Ein-Klick-Angriff oder Sitzungsfahren bezeichnet, da der Angriff die zuvor authentifizierte Sitzung des Benutzers nutzt.

Ein Beispiel für einen CSRF-Angriff:

  1. Ein Benutzer meldet sich mit www.good-banking-site.example.com der Formularauthentifizierung an. Der Server authentifiziert den Benutzer und gibt eine Antwort aus, die eine Authentifizierung cookieenthält. Die Website ist anfällig für Angriffe, da sie jeder Anforderung vertraut, die sie mit einer gültigen Authentifizierung cookieempfängt.

  2. Der Benutzer besucht eine bösartige Website, www.bad-crook-site.example.com.

    Die böswillige Website www.bad-crook-site.example.comenthält ein HTML-Formular ähnlich dem folgenden Beispiel:

    <h1>Congratulations! You're a Winner!</h1>
    <form action="https://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 Formulars action an die anfällige Website, nicht an die bösartige Website. Dies ist der "siteübergreifende" Teil von CSRF.

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

  4. Die Anforderung wird auf dem www.good-banking-site.example.com Server mit dem Authentifizierungskontext des Benutzers ausgeführt und kann jede Aktion ausführen, die ein 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 bösartige Website Folgendes ausführen:

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

Diese alternativen Szenarien erfordern keine Aktion oder Eingabe des anderen Benutzers als zunächst den Besuch der böswilligen Website.

Die Verwendung von HTTPS verhindert keinen CSRF-Angriff. Die bösartige Website kann eine https://www.good-banking-site.com/ Anforderung genauso einfach senden, wie sie eine unsichere Anforderung senden kann.

Einige Angriffszielendpunkte, die auf GET-Anforderungen reagieren, in diesem Fall kann ein Bildtag verwendet werden, um die Aktion auszuführen. Diese Art von Angriff ist auf Forumwebsites üblich, die Bilder zulassen, aber JavaScript blockieren. Apps, die den Status von 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 Status einer GET-Anforderung nie zu ändern.

CSRF-Angriffe sind für Web-Apps möglich, die für die Authentifizierung verwendet werden cookie, da:

  • Browserspeicher cookie, die von einer Web-App ausgestellt wurden.
  • Gespeicherte cookies umfassen Sitzungss s cookiefür authentifizierte Benutzer.
  • Browser senden alle cookiemit einer Domäne verknüpften Dateien an die Web-App, unabhängig davon, wie die Anforderung an die App im Browser generiert wurde.

CSRF-Angriffe sind jedoch nicht auf Exploits cookiebeschränkt. Beispielsweise sind die Standard- und Digestauthentifizierung auch anfällig. Nachdem sich ein Benutzer mit der Standard- oder Digestauthentifizierung angemeldet hat, sendet der Browser automatisch die Anmeldeinformationen, bis die Sitzung endet.

In diesem Kontext bezieht sich die Sitzung auf die clientseitige Sitzung, während der der Benutzer authentifiziert wird. Es ist nicht mit serverseitigen Sitzungen oder ASP.NET Core Session Middleware verbunden.

Benutzer können vor CSRF-Sicherheitsrisiken schützen, indem Sie Vorsichtsmaßnahmen ergreifen:

  • Melden Sie sich bei der Verwendung von Web-Apps ab.
  • Löschen Sie die Browser cookiein regelmäßigen Abständen.

CSRF-Sicherheitsrisiken sind jedoch grundsätzlich ein Problem mit der Web-App, nicht dem Endbenutzer.

Grundlagen der Authentifizierung

Cookie-basierte Authentifizierung ist eine beliebte Form der Authentifizierung. Tokenbasierte Authentifizierungssysteme werden zunehmend beliebter, insbesondere für Single Page Applications (SPAs).

Wenn sich ein Benutzer mithilfe seines Benutzernamens und kennworts authentifiziert, wird ein Token ausgestellt, das ein Authentifizierungsticket enthält, das für die Authentifizierung und Autorisierung verwendet werden kann. Das Token wird als ein cookie Token gespeichert, das mit jeder Anforderung gesendet wird, die der Client vornimmt. Generieren und Überprüfen ders cookie erfolgt durch die Cookie Authentifizierungs-Middleware. Die Middleware serialisiert einen Benutzerprinzipal in eine verschlüsselte cookie. Bei nachfolgenden Anforderungen überprüft die Middleware den cookiePrinzipal, erstellt den Prinzipal neu und weist der Eigenschaft den HttpContext.User Prinzipal zu.

Tokenbasierte Authentifizierung

Wenn ein Benutzer authentifiziert wird, wird ein Token ausgestellt (kein Antiforgery-Token). Das Token enthält Benutzerinformationen in Form von Ansprüchen oder einem Referenztoken, das die App auf den in der App verwalteten Benutzerstatus verweist. Wenn ein Benutzer versucht, auf eine Ressource zuzugreifen, die eine Authentifizierung erfordert, wird das Token mit einem zusätzlichen Autorisierungsheader in Form eines Bearer-Tokens an die App gesendet. Dieser Ansatz macht die App zustandslos. In jeder nachfolgenden Anforderung wird das Token in der Anforderung für die serverseitige Überprüfung übergeben. Dieses Token ist nicht verschlüsselt; es ist codiert. Auf dem Server wird das Token decodiert, um auf seine Informationen zuzugreifen. Um das Token für nachfolgende Anforderungen zu senden, speichern Sie das Token im lokalen Speicher des Browsers. Achten Sie nicht auf DIE CSRF-Sicherheitsanfälligkeit, wenn das Token im lokalen Speicher des Browsers gespeichert ist. CSRF ist ein Problem, wenn das Token in einem cookie. Weitere Informationen finden Sie im GitHub-Problemcodebeispiel FÜR SPA-Codebeispiele, in dem zwei cookies hinzugefügt werden.

Mehrere Apps, die in einer Domäne gehostet werden

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

Obwohl example1.contoso.net es example2.contoso.net verschiedene Hosts gibt, gibt es eine implizite Vertrauensstellung zwischen Hosts unter der *.contoso.net Domäne. Diese implizite Vertrauensstellung ermöglicht es potenziell nicht vertrauenswürdigen Hosts, sich auf die Anderen zu auswirken cookie(die Richtlinien mit demselben Ursprung, die AJAX-Anforderungen steuern, gelten nicht unbedingt für HTTP-Nachrichten cookie).

Angriffe, die vertrauenswürdige cookieS zwischen Apps ausnutzen, die in derselben Domäne gehostet werden, können durch keine Freigabedomänen verhindert werden. Wenn jede App in einer eigenen Domäne gehostet wird, gibt es keine implizite cookie Vertrauensstellung, die ausgenutzt werden soll.

Antiforgerie in ASP.NET Core

Warnung

ASP.NET Core implementiert Antiforgerie mithilfe von ASP.NET Core Datenschutz. Der Datenschutzstapel muss für die Arbeit in einer Serverfarm konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren des Datenschutzes.

Die Antiforgery-Middleware wird dem Container "Abhängigkeitseinfügung " hinzugefügt, wenn eine der folgenden APIs aufgerufen Program.cswird:

Das Formulartag-Hilfsprogramm injiziert Anti-XSRF/CSRF-Token in HTML-Formularelemente. Das folgende Markup in einer Razor Datei generiert automatisch Antiforgery-Token:

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

Generiert standardmäßig Antiforgery-Token, IHtmlHelper.BeginForm wenn die Methode des Formulars nicht GET ist.

Die automatische Generierung von Antiforgery-Token für HTML-Formularelemente erfolgt, wenn das <form> Tag das method="post" Attribut enthält, und eines der folgenden sind true:

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

Die automatische Generierung von Antiforgery-Token für HTML-Formularelemente kann deaktiviert werden:

  • Deaktivieren Sie Antiforgery-Token explizit mit dem asp-antiforgery Attribut:

    <form method="post" asp-antiforgery="false">
        <!-- ... -->
    </form>
    
  • Das Formularelement ist mit dem Tag-Helper !-Opt-Out-Symbol abgemeldet:

    <!form method="post">
        <!-- ... -->
    </!form>
    
  • Entfernen Sie die FormTagHelper Ansicht. Die FormTagHelper Kann aus einer Ansicht entfernt werden, indem Sie der Razor Ansicht die folgende Direktive hinzufügen:

    @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 am häufigsten verwendete Ansatz zum Schutz vor CSRF-Angriffen besteht darin, das Synchronizer-Tokenmuster (Synchronizer Token Pattern , STP) zu verwenden. STP wird verwendet, wenn der Benutzer eine Seite mit Formulardaten anfordert:

  1. Der Server sendet ein Token, das der Identität des aktuellen Benutzers an den Client zugeordnet ist.
  2. Der Client sendet das Token zurück an den Server zur Überprüfung.
  3. Wenn der Server ein Token empfängt, das nicht mit der Identität des authentifizierten Benutzers übereinstimmt, 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. die Sicherstellung der Anforderungssequenz von: Seite 1 > Seite 2 > Seite 3). Alle Formulare in ASP.NET Core MVC- und Razor Seitenvorlagen generieren Antiforgery-Token. Das folgende Ansichtspaar generiert Antiforgery-Token:

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

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

Fügen Sie einem <form> Element explizit ein Antiforgery-Token hinzu, ohne Tag-Hilfselemente mit dem HTML-Hilfsprogramm @Html.AntiForgeryTokenzu verwenden:

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

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

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

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

ASP.NET Core enthält drei Filter für die Arbeit mit Antiforgery-Token:

Antiforgery mit AddControllers

Das Aufrufen AddControllers aktiviert keine Antiforgery-Token. AddControllersWithViews Muss aufgerufen werden, um integrierte Antiforgery-Tokenunterstützung zu haben.

Mehrere Browserregisterkarten und das Syncrtokenmuster

Mit dem Syncr-Tokenmuster enthält nur die zuletzt geladene Seite ein gültiges Antiforgery-Token. Die Verwendung mehrerer Registerkarten kann problematisch sein. Wenn ein Benutzer beispielsweise mehrere Registerkarten öffnet:

  • Nur die zuletzt geladene Registerkarte enthält ein gültiges Antiforgery-Token.
  • Anforderungen aus zuvor geladenen Registerkarten führen zu einem Fehler: Antiforgery token validation failed. The antiforgery cookie token and request token do not match

Berücksichtigen Sie alternative CSRF-Schutzmuster, wenn dies ein Problem darstellt.

Konfigurieren von Antiforgerie mit AntiforgeryOptions

Anpassen AntiforgeryOptions in Program.cs:

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

Legen Sie die Eigenschaften der Antiforgerie Cookie mithilfe der Eigenschaften der Klasse fest, wie in der CookieBuilder folgenden Tabelle dargestellt.

Option BESCHREIBUNG
Cookie Bestimmt die Einstellungen, die zum Erstellen der Antiforgerys cookieverwendet werden.
FormFieldName Der Name des ausgeblendeten Formularfelds, das vom Antiforgery-System verwendet wird, um Antiforgery-Token in Ansichten zu rendern.
HeaderName Der Name der Kopfzeile, die vom Antiforgery-System verwendet wird. Wenn nulldas System nur Formulardaten berücksichtigt.
SuppressXFrameOptionsHeader Gibt an, ob die Generation der X-Frame-Options Kopfzeile unterdrückt werden soll. Standardmäßig wird der Header mit einem Wert von "SAMEORIGIN" generiert. Wird standardmäßig auf false festgelegt.

Weitere Informationen finden Sie unter CookieAuthenticationOptions.

Generieren von Antiforgery-Token mit IAntiforgery

IAntiforgery stellt die API bereit, um Antiforgery-Features zu konfigurieren. IAntiforgery kann mithilfe Program.csWebApplication.Servicesvon . Im folgenden Beispiel wird Middleware aus der Startseite der App verwendet, um ein Antiforgerytoken zu generieren und als Antwort zu cookiesenden:

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

Im vorherigen Beispiel wird ein cookie benannter Wert XSRF-TOKENfestgelegt. Der Client kann dies cookie lesen und seinen Wert als Kopfzeile angeben, der an AJAX-Anforderungen angefügt ist. Beispielsweise enthält Angular integrierten XSRF-Schutz, der standardmäßig einen cookie benannten Namen XSRF-TOKEN liest.

Erfordern einer Antiforgerieüberprüfung

Der ValidAntiForgeryToken-Aktionsfilter kann auf eine einzelne Aktion, einen Controller oder global angewendet werden. Anforderungen an Aktionen, die diesen Filter angewendet haben, werden blockiert, es sei denn, die Anforderung enthält ein gültiges Antiforgery-Token:

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

    return RedirectToAction();
}

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

Automatische Überprüfung von Antiforgerytoken für unsichere HTTP-Methoden nur

Anstatt das ValidateAntiForgeryToken Attribut breit anzuwenden und dann mit IgnoreAntiforgeryToken Attributen außer Kraft zu setzen, kann das AutoValidateAntiforgeryToken-Attribut verwendet werden. Dieses Attribut funktioniert identisch mit dem Attribut, außer dass es keine Token für Anforderungen erfordert, die mithilfe der ValidateAntiForgeryToken folgenden HTTP-Methoden vorgenommen wurden:

  • GET
  • HEAD
  • OPTIONS
  • TRACE

Es wird empfohlen, eine allgemeine Verwendung für AutoValidateAntiforgeryToken Nicht-API-Szenarien zu verwenden. Dieses Attribut stellt sicher, dass POST-Aktionen standardmäßig geschützt sind. Die Alternative besteht darin, Antiforgery-Token standardmäßig zu ignorieren, es sei ValidateAntiForgeryToken denn, es wird auf einzelne Aktionsmethoden angewendet. Es ist wahrscheinlicher, dass in diesem Szenario eine POST-Aktionsmethode nicht geschützt wird, indem die App für CSRF-Angriffe anfällig ist. Alle POSTs sollten das Antiforgery-Token senden.

APIs verfügen nicht über einen automatischen Mechanismus zum Senden des Nichtteilscookie des Token. Die Implementierung hängt wahrscheinlich von der Clientcodeimplementierung ab. Einige Beispiele werden unten gezeigt:

Beispiel für Klassenebene:

[AutoValidateAntiforgeryToken]
public class HomeController : Controller

Globales Beispiel:

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

Überschreiben von globalen oder Controller-Antiforgery-Attributen

Der Filter "IgnoreAntiforgeryToken" wird verwendet, um die Notwendigkeit eines Antiforgerytokens für eine bestimmte Aktion (oder Controller) zu beseitigen. Bei Anwendung überschreibt ValidateAntiForgeryToken dieser Filter die AutoValidateAntiforgeryToken auf höherer Ebene angegebenen Filter (global oder auf einem Controller).

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

    return RedirectToAction();
}

Aktualisieren von Token nach der Authentifizierung

Token sollten aktualisiert werden, nachdem der Benutzer authentifiziert wurde, indem der Benutzer auf eine Ansichts- oder Razor Seitenseite umgeleitet wird.

JavaScript, AJAX und SPAs

In herkömmlichen HTML-basierten Apps werden Antiforgery-Token mit ausgeblendeten Formularfeldern an den Server übergeben. In modernen JavaScript-basierten Apps und SPAs werden viele Anforderungen programmgesteuert vorgenommen. Diese AJAX-Anforderungen können andere Techniken (z. B. Anforderungsheader oder cookieS) verwenden, um das Token zu senden.

Wenn cookies verwendet wird, um Authentifizierungstoken zu speichern und API-Anforderungen auf dem Server zu authentifizieren, ist CSRF ein potenzielles Problem. Wenn der lokale Speicher zum Speichern des Token verwendet wird, kann die CSRF-Sicherheitsanfälligkeit verringert werden, da Werte aus dem lokalen Speicher nicht automatisch an den Server mit jeder Anforderung gesendet werden. Wenn Sie den lokalen Speicher verwenden, um das Antiforgery-Token auf dem Client zu speichern und das Token als Anforderungsheader zu senden, ist ein empfohlener Ansatz.

JavaScript

Mithilfe von JavaScript mit Ansichten kann das Token mithilfe eines Diensts aus der Ansicht erstellt werden. Einfügen des Diensts in die IAntiforgery Ansicht und den Aufruf GetAndStoreTokens:

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

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

Dieser Ansatz entfernt die Notwendigkeit, direkt mit den Einstellungen cookievom Server zu umgehen oder sie aus dem Client zu lesen. Wenn sie den IAntiforgery Dienst injizieren, ist jedoch nicht möglich, verwenden Sie JavaScript, um auf Token in cookies zuzugreifen:

  • Zugriffstoken in einer zusätzlichen Anforderung an den Server, normalerweise same-origin.
  • Verwenden Sie den Inhalt des cookieTokens, um eine Kopfzeile mit dem Wert des Token zu erstellen.

Wenn das Skript das Token in einer Anforderungskopfzeile sendet X-XSRF-TOKEN, konfigurieren Sie den Antiforgery-Dienst, um nach der X-XSRF-TOKEN Kopfzeile zu suchen:

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

Im folgenden Beispiel wird ein geschützter Endpunkt hinzugefügt, der das Anforderungstoken in ein JavaScript-lesbares cookieSchreibt:

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

Im folgenden Beispiel wird JavaScript verwendet, um eine AJAX-Anforderung zum Abrufen des Token zu erstellen und eine weitere Anforderung mit dem entsprechenden Header vorzunehmen:

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

Antiforgerie mit minimalen APIs

Minimal APIs unterstützt nicht die Verwendung der enthaltenen Filter (ValidateAntiForgeryToken, AutoValidateAntiforgeryToken, IgnoreAntiforgeryToken), stellt jedoch die erforderlichen APIs bereit, IAntiforgery um eine Anforderung zu überprüfen.

Im folgenden Beispiel wird ein Filter erstellt, der das Antiforgery-Token überprüft:

internal static class AntiForgeryExtensions
{
    public static TBuilder ValidateAntiforgery<TBuilder>(this TBuilder builder) where TBuilder : IEndpointConventionBuilder
    {
        return builder.AddEndpointFilter(routeHandlerFilter: async (context, next) =>
        {
            try
            {
                var antiForgeryService = context.HttpContext.RequestServices.GetRequiredService<IAntiforgery>();
                await antiForgeryService.ValidateRequestAsync(context.HttpContext);
            }
            catch (AntiforgeryValidationException)
            {
                return Results.BadRequest("Antiforgery token validation failed.");
            }

            return await next(context);

        });
    }
}

Der Filter kann dann auf einen Endpunkt angewendet werden:

app.MapPost("api/upload", (IFormFile name) => Results.Accepted())
    .RequireAuthorization()
    .ValidateAntiforgery();

Windows-Authentifizierung und Antiforgerys cookie

Bei Verwendung der Windows-Authentifizierung müssen Anwendungsendpunkte auf die gleiche Weise wie für cookies geschützt sein. Der Browser sendet implizit den Authentifizierungskontext an den Server und Endpunkte, die vor CSRF-Angriffen geschützt werden müssen.

Erweitern von Antiforgerie

Mit IAntiforgeryAdditionalDataProvider dem Typ können Entwickler das Verhalten des Anti-CSRF-Systems erweitern, indem zusätzliche Daten in jedem Token rundet werden. Die GetAdditionalData Methode wird jedes Mal aufgerufen, wenn ein Feldtoken generiert wird, und der Rückgabewert wird innerhalb des generierten Token eingebettet. Ein Implementierunger kann einen Zeitstempel, einen 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 eingeschlossen werden müssen. Wenn ein Token zusätzliche Daten enthält, aber keine IAntiForgeryAdditionalDataProvider konfiguriert ist, wird die ergänzungsdaten nicht überprüft.

Zusätzliche Ressourcen

Websiteübergreifende Anforderungs forgery (auch als XSRF oder CSRF bezeichnet) ist ein Angriff auf web gehostete Apps, wobei eine böswillige Web-App die Interaktion zwischen einem Clientbrowser und einer Web-App beeinflussen kann, die diesem Browser vertrauen. Diese Angriffe sind möglich, da Webbrowser einige Arten von Authentifizierungstoken automatisch mit jeder Anforderung an eine Website senden. Diese Form des Exploits wird auch als Ein-Klick-Angriff oder Sitzungsfahren bezeichnet, da der Angriff die zuvor authentifizierte Sitzung des Benutzers nutzt.

Ein Beispiel für einen CSRF-Angriff:

  1. Ein Benutzer meldet sich mit www.good-banking-site.example.com der Formularauthentifizierung an. Der Server authentifiziert den Benutzer und gibt eine Antwort, die eine Authentifizierung cookieenthält. Die Website ist anfällig für Angriffe, da sie jeder Anforderung vertraut, die sie mit einer gültigen Authentifizierung cookieempfängt.

  2. Der Benutzer besucht eine bösartige Website, www.bad-crook-site.example.com.

    Die bösartige Website, www.bad-crook-site.example.comenthält ein HTML-Formular ähnlich dem folgenden Beispiel:

    <h1>Congratulations! You're a Winner!</h1>
    <form action="https://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 Formulars action an die anfällige Website, nicht an die bösartige Website. Dies ist der Teil der "cross-site" von CSRF.

  3. Der Benutzer wählt die Schaltfläche "Übermitteln" aus. Der Browser stellt die Anforderung vor und enthält automatisch die Authentifizierung cookie für die angeforderte Domäne. www.good-banking-site.example.com

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

Neben dem Szenario, in dem der Benutzer die Schaltfläche zum Übermitteln des Formulars auswählt, könnte die böswillige Website folgendes sein:

  • Führen Sie ein Skript aus, das das Formular automatisch sendet.
  • Senden Sie die Formularübermittlung als AJAX-Anforderung.
  • Ausblenden des Formulars mithilfe von CSS.

Diese alternativen Szenarien erfordern keine Aktion oder Eingabe des anderen Benutzers als zunächst den Besuch der böswilligen Website.

Die Verwendung von HTTPS verhindert keinen CSRF-Angriff. Die bösartige Website kann eine Anforderung genauso einfach senden, wie sie eine https://www.good-banking-site.com/ unsichere Anforderung senden kann.

Einige Angriffe zielen auf Endpunkte ab, die auf GET-Anforderungen reagieren, in diesem Fall kann ein Bildtag verwendet werden, um die Aktion auszuführen. Diese Art von Angriff ist auf Forumwebsites üblich, die Bilder zulassen, aber JavaScript blockieren. Apps, die den Zustand von GET-Anforderungen ändern, bei denen Variablen oder Ressourcen geändert werden, sind anfällig für böswillige Angriffe. GET-Anforderungen, die den Status ändern, sind unsicher. Eine bewährte Methode besteht darin, den Status einer GET-Anforderung nie zu ändern.

CSRF-Angriffe sind gegen Web-Apps möglich, die für die Authentifizierung verwenden cookie, da:

  • Browserspeicher cookie, die von einer Web-App ausgestellt wurden.
  • Gespeicherte cookies umfassen Sitzungss cookies für authentifizierte Benutzer.
  • Browser senden alle cookiemit einer Domäne verknüpften Domänen an die Web-App, unabhängig davon, wie die Anforderung an die App innerhalb des Browsers generiert wurde.

CSRF-Angriffe sind jedoch nicht auf Exploits cookiebeschränkt. Die Standard- und Digestauthentifizierung ist beispielsweise auch anfällig. Nachdem sich ein Benutzer mit der Standard- oder Digestauthentifizierung angemeldet hat, sendet der Browser die Anmeldeinformationen automatisch, bis die Sitzung endet.

In diesem Zusammenhang bezieht sich die Sitzung auf die clientseitige Sitzung, während der der Benutzer authentifiziert wird. Es ist nicht mit serverseitigen Sitzungen oder ASP.NET Core Session Middleware verbunden.

Benutzer können vor CSRF-Sicherheitsrisiken schützen, indem Sie Vorsichtsmaßnahmen ergreifen:

  • Melden Sie sich bei der Verwendung von Web-Apps ab.
  • Löschen Sie den Browser cookieregelmäßig.

CSRF-Sicherheitsrisiken sind jedoch grundsätzlich ein Problem mit der Web-App, nicht dem Endbenutzer.

Grundlagen der Authentifizierung

Cookie-basierte Authentifizierung ist eine beliebte Authentifizierungsform. Tokenbasierte Authentifizierungssysteme werden zunehmend beliebt, insbesondere für Single Page Applications (SPAs).

Wenn ein Benutzer den Benutzernamen und das 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 cookie eine gespeichert, die mit jeder Anforderung gesendet wird, die der Client erstellt. Dies wird durch die Cookie Authentifizierungs-Middleware generiert und überprüftcookie. Die Middleware serialisiert einen Benutzerprinzipal in eine verschlüsselte cookie. Bei nachfolgenden Anforderungen überprüft die Middleware den cookiePrinzipal, erstellt den Prinzipal neu und weist den Prinzipal der HttpContext.User Eigenschaft zu.

Tokenbasierte Authentifizierung

Wenn ein Benutzer authentifiziert wird, wird ein Token (kein Antiforgery-Token) ausgestellt. Das Token enthält Benutzerinformationen in Form von Ansprüchen oder einem Referenztoken, das die App auf den in der App verwalteten Benutzerstatus verweist. Wenn ein Benutzer versucht, auf eine Ressource zuzugreifen, die Authentifizierung erfordert, wird das Token mit einem zusätzlichen Autorisierungsheader in Form eines Bearer-Token an die App gesendet. Dieser Ansatz macht die App zustandslos. In jeder nachfolgenden Anforderung wird das Token in der Anforderung für die serverseitige Überprüfung übergeben. Dieses Token ist nicht verschlüsselt; es ist codiert. Auf dem Server wird das Token entschlüsselt, um auf seine Informationen zuzugreifen. Um das Token auf nachfolgenden Anforderungen zu senden, speichern Sie das Token im lokalen Speicher des Browsers. Bedenken Sie nicht, dass die CSRF-Sicherheitsanfälligkeit besteht, wenn das Token im lokalen Speicher des Browsers gespeichert ist. CSRF ist ein Problem, wenn das Token in einem cookie. Weitere Informationen finden Sie im GitHub-Problemcodebeispiel mit zwei cookies.

Mehrere Apps, die in einer Domäne gehostet werden

Freigegebene Hostingumgebungen sind anfällig für die Sitzungs hijacking, login CSRF und andere Angriffe.

Obwohl example1.contoso.net und example2.contoso.net verschiedene Hosts sind, gibt es eine implizite Vertrauensstellung zwischen Hosts unter der *.contoso.net Domäne. Diese implizite Vertrauensstellung ermöglicht potenziell nicht vertrauenswürdigen Hosts, sich auf die Anderen zu auswirken cookie(die gleichen Ursprungsrichtlinien, die AJAX-Anforderungen steuern, gelten nicht unbedingt für HTTP-S cookie).

Angriffe, die vertrauenswürdige cookieS zwischen Apps ausnutzen, die in derselben Domäne gehostet werden, können verhindert werden, indem keine Domänen freigegeben werden. Wenn jede App in einer eigenen Domäne gehostet wird, gibt es keine implizite cookie Vertrauensstellungsbeziehung zum Exploit.

Antiforgerie in ASP.NET Core

Warnung

ASP.NET Core implementiert Antiforgerie mit ASP.NET Core Datenschutz. Der Datenschutzstapel muss für die Arbeit in einer Serverfarm konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren des Datenschutzes.

Die Antiforgery-Middleware wird dem Dependency-Injektionscontainer hinzugefügt, wenn eine der folgenden APIs aufgerufen Program.cswird:

Das Formulartag-Hilfsprogramm injiziert Anti-XSRF/CSRF-Token in HTML-Formularelemente. Das folgende Markup in einer Razor Datei generiert automatisch Antiforgery-Token:

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

IHtmlHelper.BeginForm Generiert standardmäßig Antiforgery-Token, wenn die Methode des Formulars nicht GET ist.

Die automatische Generierung von Antiforgery-Token für HTML-Formularelemente geschieht, wenn das <form> Tag das method="post" Attribut enthält, und eine der folgenden sind wahr:

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

Die automatische Generierung von Antiforgery-Token für HTML-Formularelemente kann deaktiviert werden:

  • Deaktivieren Sie explizit Antiforgery-Token mit dem asp-antiforgery Attribut:

    <form method="post" asp-antiforgery="false">
        <!-- ... -->
    </form>
    
  • Das Formularelement ist mit dem Symbol "Tag Helper ! opt-out" von Tag-Hilfshilfen deaktiviert:

    <!form method="post">
        <!-- ... -->
    </!form>
    
  • Entfernen Sie die FormTagHelper Ansicht. Dies FormTagHelper kann aus einer Ansicht entfernt werden, indem Sie der Razor Ansicht die folgende Richtlinie hinzufügen:

    @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 am häufigsten verwendete Ansatz zum Schutz vor CSRF-Angriffen besteht darin, das Syncr-Tokenmuster (STP) zu verwenden. STP wird verwendet, wenn der Benutzer eine Seite mit Formulardaten anfordert:

  1. Der Server sendet ein Token, das der Identität des aktuellen Benutzers an den Client zugeordnet ist.
  2. Der Client sendet das Token an den Server zur Überprüfung zurück.
  3. Wenn der Server ein Token empfängt, das nicht mit der Identität des authentifizierten Benutzers übereinstimmt, 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. die Anforderungssequenz von: Seite 1 > Seite 2 > Seite 3). Alle Formulare in ASP.NET Core MVC- und Razor Seitenvorlagen generieren Antiforgery-Token. Die folgenden Ansichtsbeispiele generieren Antiforgery-Token:

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

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

Fügen Sie einem <form> Element explizit ein Antiforgery-Token hinzu, ohne Tag-Hilfselemente mit dem HTML-Hilfsprogramm @Html.AntiForgeryTokenzu verwenden:

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

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

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

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

ASP.NET Core enthält drei Filter für die Arbeit mit Antiforgery-Token:

Antiforgery mit AddControllers

Das Aufrufen AddControllers aktiviert keine Antiforgery-Token. AddControllersWithViews Muss aufgerufen werden, um integrierte Antiforgery-Tokenunterstützung zu haben.

Mehrere Browserregisterkarten und das Synchronizer-Tokenmuster

Mit dem Synchronizer-Tokenmuster enthält nur die zuletzt geladene Seite ein gültiges Antiforgery-Token. Die Verwendung mehrerer Registerkarten kann problematisch sein. Wenn ein Benutzer beispielsweise mehrere Registerkarten öffnet:

  • Nur die zuletzt geladene Registerkarte enthält ein gültiges Antiforgery-Token.
  • Anforderungen aus zuvor geladenen Registerkarten schlagen mit einem Fehler fehl: Antiforgery token validation failed. The antiforgery cookie token and request token do not match

Erwägen Sie alternative CSRF-Schutzmuster, wenn dies ein Problem darstellt.

Konfigurieren von Antiforgerie mit AntiforgeryOptions

Anpassen AntiforgeryOptions in Program.cs:

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

Legen Sie die Antiforgery-Eigenschaften Cookie mithilfe der Eigenschaften der CookieBuilder Klasse fest, wie in der folgenden Tabelle dargestellt.

Option BESCHREIBUNG
Cookie Bestimmt die Einstellungen, die zum Erstellen der Antiforgerys cookieverwendet werden.
FormFieldName Der Name des ausgeblendeten Formularfelds, das vom Antiforgery-System zum Rendern von Antiforgery-Token in Ansichten verwendet wird.
HeaderName Der Name des Headers, der vom Antiforgery-System verwendet wird. Wenn nulldas System nur Formulardaten betrachtet.
SuppressXFrameOptionsHeader Gibt an, ob die Generierung des X-Frame-Options Headers unterdrückt werden soll. Standardmäßig wird der Header mit dem Wert "SAMEORIGIN" generiert. Wird standardmäßig auf false festgelegt.

Weitere Informationen finden Sie unter CookieAuthenticationOptions.

Generieren von Antiforgery-Token mit IAntiforgery

IAntiforgery stellt die API bereit, um Antiforgery-Features zu konfigurieren. IAntiforgery kann mithilfe Program.cs von WebApplication.Services. Im folgenden Beispiel wird Middleware von der Startseite der App verwendet, um ein Antiforgery-Token zu generieren und als Antwort zu cookiesenden:

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

Im vorherigen Beispiel wird ein benannter cookie Wert festgelegt XSRF-TOKEN. Der Client kann dies cookie lesen und seinen Wert als Header bereitstellen, der an AJAX-Anforderungen angefügt ist. Beispielsweise enthält Angular integrierten XSRF-Schutz, der standardmäßig einen cookie benannten XSRF-TOKEN Namen liest.

Antiforgery-Überprüfung erforderlich

Der ValidateAntiForgeryToken-Aktionsfilter kann auf eine einzelne Aktion, einen Controller oder global angewendet werden. Anforderungen an Aktionen, die diesen Filter angewendet haben, werden blockiert, es sei denn, die Anforderung enthält ein gültiges Antiforgery-Token:

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

    return RedirectToAction();
}

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

Automatische Überprüfung von Antiforgerytoken für unsichere HTTP-Methoden

Anstatt das ValidateAntiForgeryToken Attribut allgemein anzuwenden und es dann mit IgnoreAntiforgeryToken Attributen außer Kraft zu setzen, kann das AutoValidateAntiforgeryToken-Attribut verwendet werden. Dieses Attribut funktioniert identisch mit dem ValidateAntiForgeryToken Attribut, außer dass es keine Token für Anforderungen erfordert, die mit den folgenden HTTP-Methoden vorgenommen werden:

  • GET
  • HEAD
  • OPTIONS
  • TRACE

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

APIs verfügen nicht über einen automatischen Mechanismus zum Senden des Nichtteilscookie des Tokens. Die Implementierung hängt wahrscheinlich von der Clientcodeimplementierung ab. Einige Beispiele sind unten dargestellt:

Beispiel auf Klassenebene:

[AutoValidateAntiforgeryToken]
public class HomeController : Controller

Globales Beispiel:

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

Überschreiben von globalen oder Controller-Antiforgery-Attributen

Der Filter "IgnoreAntiforgeryToken " wird verwendet, um die Notwendigkeit eines Antiforgery-Tokens für eine bestimmte Aktion (oder controller) zu beseitigen. Wenn dieser Filter angewendet wird ValidateAntiForgeryToken , überschreibt dieser Filter und AutoValidateAntiforgeryToken Filter, die auf einer höheren Ebene (global oder auf einem Controller) angegeben sind.

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

    return RedirectToAction();
}

Aktualisieren von Token nach der Authentifizierung

Token sollten aktualisiert werden, nachdem der Benutzer authentifiziert wurde, indem er den Benutzer zu einer Ansichts- oder Razor Seitenseite umleitet.

JavaScript, AJAX und SPAs

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

Wenn cookieS verwendet wird, um Authentifizierungstoken zu speichern und API-Anforderungen auf dem Server zu authentifizieren, ist CSRF ein potenzielles Problem. Wenn der lokale Speicher verwendet wird, um das Token zu speichern, kann DIE CSRF-Sicherheitsanfälligkeit abgemildert werden, da Werte aus lokalem Speicher nicht automatisch an den Server mit jeder Anforderung gesendet werden. Die Verwendung des lokalen Speichers zum Speichern des Antiforgery-Tokens auf dem Client und das Senden des Tokens als Anforderungsheader ist ein empfohlener Ansatz.

JavaScript

Mithilfe von JavaScript mit Ansichten kann das Token mithilfe eines Diensts aus der Ansicht erstellt werden. Einfügen des Diensts IAntiforgery in die Ansicht und Aufruf GetAndStoreTokens:

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

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

Dieser Ansatz beseitigt die Notwendigkeit, direkt mit Einstellungseinstellungen cookievom Server zu umgehen oder sie vom Client zu lesen. Wenn das Einfügen des IAntiforgery Diensts jedoch nicht möglich ist, kann JavaScript auch auf Token zugreifen cookie, die von einer zusätzlichen Anforderung an den Server abgerufen werden (normalerweise same-origin), und verwenden Sie den Inhalt des cookieServers, um einen Header mit dem Wert des Tokens zu erstellen.

Wenn das Skript das Token in einem Anforderungsheader sendet, der aufgerufen X-XSRF-TOKENwird, konfigurieren Sie den Antiforgery-Dienst, um nach dem X-XSRF-TOKEN Header zu suchen:

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

Im folgenden Beispiel wird ein geschützter Endpunkt hinzugefügt, der das Anforderungstoken in ein JavaScript-lesbares cookieObjekt schreibt:

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

Im folgenden Beispiel wird JavaScript verwendet, um eine AJAX-Anforderung zum Abrufen des Tokens zu erstellen und eine weitere Anforderung mit dem entsprechenden Header vorzunehmen:

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

Windows-Authentifizierung und Antiforgery cookies

Bei verwendung der Windows-Authentifizierung müssen Anwendungsendpunkte auf die gleiche Weise wie für cookies vor CSRF-Angriffen geschützt werden. Der Browser sendet implizit den Authentifizierungskontext an den Server und so müssen Endpunkte vor CSRF-Angriffen geschützt werden.

Antiforgerie erweitern

Mit IAntiforgeryAdditionalDataProvider dem Typ können Entwickler das Verhalten des Anti-CSRF-Systems erweitern, indem zusätzliche Daten in jedem Token umgerundet werden. Die GetAdditionalData Methode wird jedes Mal aufgerufen, wenn ein Feldtoken generiert wird, und der Rückgabewert wird innerhalb des generierten Tokens eingebettet. Ein Implementierungser kann einen Zeitstempel, einen Nonce oder einen anderen Wert zurückgeben und dann aufrufen ValidateAdditionalData , 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 eingeschlossen werden müssen. Wenn ein Token ergänzende Daten enthält, aber nicht IAntiForgeryAdditionalDataProvider konfiguriert ist, werden die ergänzenden Daten nicht überprüft.

Zusätzliche Ressourcen

Websiteübergreifende Anforderungs-Fälschung (auch als XSRF oder CSRF bezeichnet) ist ein Angriff auf web gehostete Apps, bei denen eine bösartige Web-App die Interaktion zwischen einem Clientbrowser und einer Web-App beeinflussen kann, die diesem Browser vertraut. Diese Angriffe sind möglich, da Webbrowser einige Arten von Authentifizierungstoken automatisch mit jeder Anforderung an eine Website senden. Diese Form des Exploits wird auch als Ein-Klick-Angriff oder Sitzungsfahren bezeichnet, da der Angriff die zuvor authentifizierte Sitzung des Benutzers nutzt.

Ein Beispiel für einen CSRF-Angriff:

  1. Ein Benutzer meldet sich mit www.good-banking-site.example.com der Formularauthentifizierung an. Der Server authentifiziert den Benutzer und gibt eine Antwort aus, die eine Authentifizierung cookieenthält. Die Website ist anfällig für Angriffe, da sie jeder Anforderung vertraut, die sie mit einer gültigen Authentifizierung cookieempfängt.

  2. Der Benutzer besucht eine bösartige Website, www.bad-crook-site.example.com.

    Die böswillige Website www.bad-crook-site.example.comenthält ein HTML-Formular ähnlich dem folgenden Beispiel:

    <h1>Congratulations! You're a Winner!</h1>
    <form action="https://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 Formulars action an die anfällige Website, nicht an die bösartige Website. Dies ist der "siteübergreifende" Teil von CSRF.

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

  4. Die Anforderung wird auf dem www.good-banking-site.example.com Server mit dem Authentifizierungskontext des Benutzers ausgeführt und kann jede Aktion ausführen, die ein 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 bösartige Website Folgendes ausführen:

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

Diese alternativen Szenarien erfordern keine Aktion oder Eingabe des anderen Benutzers als zunächst den Besuch der böswilligen Website.

Die Verwendung von HTTPS verhindert keinen CSRF-Angriff. Die bösartige Website kann eine https://www.good-banking-site.com/ Anforderung genauso einfach senden, wie sie eine unsichere Anforderung senden kann.

Einige Angriffszielendpunkte, die auf GET-Anforderungen reagieren, in diesem Fall kann ein Bildtag verwendet werden, um die Aktion auszuführen. Diese Art von Angriff ist auf Forumwebsites üblich, die Bilder zulassen, aber JavaScript blockieren. Apps, die den Status von 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 Status einer GET-Anforderung nie zu ändern.

CSRF-Angriffe sind für Web-Apps möglich, die für die Authentifizierung verwendet werden cookie, da:

  • Browserspeicher cookie, die von einer Web-App ausgestellt wurden.
  • Gespeicherte cookies umfassen Sitzungss s cookiefür authentifizierte Benutzer.
  • Browser senden alle cookiemit einer Domäne verknüpften Dateien an die Web-App, unabhängig davon, wie die Anforderung an die App im Browser generiert wurde.

CSRF-Angriffe sind jedoch nicht auf Exploits cookiebeschränkt. Beispielsweise sind die Standard- und Digestauthentifizierung auch anfällig. Nachdem sich ein Benutzer mit der Standard- oder Digestauthentifizierung angemeldet hat, sendet der Browser automatisch die Anmeldeinformationen, bis die Sitzung endet.

In diesem Kontext bezieht sich die Sitzung auf die clientseitige Sitzung, während der der Benutzer authentifiziert wird. Es ist nicht mit serverseitigen Sitzungen oder ASP.NET Core Session Middleware verbunden.

Benutzer können vor CSRF-Sicherheitsrisiken schützen, indem Sie Vorsichtsmaßnahmen ergreifen:

  • Melden Sie sich bei der Verwendung von Web-Apps ab.
  • Löschen Sie die Browser cookiein regelmäßigen Abständen.

CSRF-Sicherheitsrisiken sind jedoch grundsätzlich ein Problem mit der Web-App, nicht dem Endbenutzer.

Grundlagen der Authentifizierung

Cookie-basierte Authentifizierung ist eine beliebte Form der Authentifizierung. Tokenbasierte Authentifizierungssysteme werden zunehmend beliebter, insbesondere für Single Page Applications (SPAs).

Wenn sich ein Benutzer mithilfe seines Benutzernamens und kennworts authentifiziert, wird ein Token ausgestellt, das ein Authentifizierungsticket enthält, das für die Authentifizierung und Autorisierung verwendet werden kann. Das Token wird als ein cookie Token gespeichert, das mit jeder Anforderung gesendet wird, die der Client vornimmt. Generieren und Überprüfen ders cookie erfolgt durch die Cookie Authentifizierungs-Middleware. Die Middleware serialisiert einen Benutzerprinzipal in eine verschlüsselte cookie. Bei nachfolgenden Anforderungen überprüft die Middleware den cookiePrinzipal, erstellt den Prinzipal neu und weist der Eigenschaft den HttpContext.User Prinzipal zu.

Tokenbasierte Authentifizierung

Wenn ein Benutzer authentifiziert wird, wird ein Token ausgestellt (kein Antiforgery-Token). Das Token enthält Benutzerinformationen in Form von Ansprüchen oder einem Referenztoken, das die App auf den in der App verwalteten Benutzerstatus verweist. Wenn ein Benutzer versucht, auf eine Ressource zuzugreifen, die eine Authentifizierung erfordert, wird das Token mit einem zusätzlichen Autorisierungsheader in Form eines Bearer-Tokens an die App gesendet. Dieser Ansatz macht die App zustandslos. In jeder nachfolgenden Anforderung wird das Token in der Anforderung für die serverseitige Überprüfung übergeben. Dieses Token ist nicht verschlüsselt; es ist codiert. Auf dem Server wird das Token decodiert, um auf seine Informationen zuzugreifen. Um das Token für nachfolgende Anforderungen zu senden, speichern Sie das Token im lokalen Speicher des Browsers. Achten Sie nicht auf DIE CSRF-Sicherheitsanfälligkeit, wenn das Token im lokalen Speicher des Browsers gespeichert ist. CSRF ist ein Problem, wenn das Token in einem cookie. Weitere Informationen finden Sie im GitHub-Problemcodebeispiel FÜR SPA-Codebeispiele, in dem zwei cookies hinzugefügt werden.

Mehrere Apps, die in einer Domäne gehostet werden

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

Obwohl example1.contoso.net es example2.contoso.net verschiedene Hosts gibt, gibt es eine implizite Vertrauensstellung zwischen Hosts unter der *.contoso.net Domäne. Diese implizite Vertrauensstellung ermöglicht es potenziell nicht vertrauenswürdigen Hosts, sich auf die Anderen zu auswirken cookie(die Richtlinien mit demselben Ursprung, die AJAX-Anforderungen steuern, gelten nicht unbedingt für HTTP-Nachrichten cookie).

Angriffe, die vertrauenswürdige cookieS zwischen Apps ausnutzen, die in derselben Domäne gehostet werden, können durch keine Freigabedomänen verhindert werden. Wenn jede App in einer eigenen Domäne gehostet wird, gibt es keine implizite cookie Vertrauensstellung, die ausgenutzt werden soll.

ASP.NET Core Antiforgery-Konfiguration

Warnung

ASP.NET Core implementiert Antiforgerie mithilfe von ASP.NET Core Datenschutz. Der Datenschutzstapel muss für die Arbeit in einer Serverfarm konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren des Datenschutzes.

Die Antiforgery-Middleware wird dem Container "Abhängigkeitseinfügung " hinzugefügt, wenn eine der folgenden APIs aufgerufen Startup.ConfigureServiceswird:

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

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

Generiert standardmäßig Antiforgery-Token, IHtmlHelper.BeginForm wenn die Methode des Formulars nicht GET ist.

Die automatische Generierung von Antiforgery-Token für HTML-Formularelemente erfolgt, wenn das <form> Tag das method="post" Attribut enthält, und eines der folgenden sind true:

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

Die automatische Generierung von Antiforgery-Token für HTML-Formularelemente kann deaktiviert werden:

  • Deaktivieren Sie Antiforgery-Token explizit mit dem asp-antiforgery Attribut:

    <form method="post" asp-antiforgery="false">
        ...
    </form>
    
  • Das Formularelement ist mit dem Tag-Helper !-Opt-Out-Symbol abgemeldet:

    <!form method="post">
        ...
    </!form>
    
  • Entfernen Sie die FormTagHelper Ansicht. Die FormTagHelper Kann aus einer Ansicht entfernt werden, indem Sie der Razor Ansicht die folgende Direktive hinzufügen:

    @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 am häufigsten verwendete Ansatz zum Schutz vor CSRF-Angriffen besteht darin, das Synchronizer-Tokenmuster (Synchronizer Token Pattern , STP) zu verwenden. STP wird verwendet, wenn der Benutzer eine Seite mit Formulardaten anfordert:

  1. Der Server sendet ein Token, das der Identität des aktuellen Benutzers an den Client zugeordnet ist.
  2. Der Client sendet das Token zurück an den Server zur Überprüfung.
  3. Wenn der Server ein Token empfängt, das nicht mit der Identität des authentifizierten Benutzers übereinstimmt, 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. die Sicherstellung der Anforderungssequenz von: Seite 1 > Seite 2 > Seite 3). Alle Formulare in ASP.NET Core MVC- und Razor Seitenvorlagen generieren Antiforgery-Token. Das folgende Ansichtspaar generiert Antiforgery-Token:

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

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

Fügen Sie einem <form> Element explizit ein Antiforgery-Token hinzu, ohne Die Tag-Hilfsprogramm mit dem HTML-Hilfsprogramm @Html.AntiForgeryTokenzu verwenden:

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

In jedem der vorherigen Fälle fügt ASP.NET Core ein ausgeblendetes Formularfeld hinzu, das dem folgenden Beispiel ähnelt:

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

ASP.NET Core enthält drei Filter zum Arbeiten mit Antiforgery-Token:

Antiforgery-Optionen

Anpassen AntiforgeryOptions in Startup.ConfigureServices:

services.AddAntiforgery(options => 
{
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-HEADERNAME";
    options.SuppressXFrameOptionsHeader = false;
});

Legen Sie die Antiforgery-Eigenschaften Cookie mithilfe der Eigenschaften der CookieBuilder Klasse fest, wie in der folgenden Tabelle dargestellt.

Option BESCHREIBUNG
Cookie Bestimmt die Einstellungen, die zum Erstellen der Antiforgerys cookieverwendet werden.
FormFieldName Der Name des ausgeblendeten Formularfelds, das vom Antiforgery-System zum Rendern von Antiforgery-Token in Ansichten verwendet wird.
HeaderName Der Name des Headers, der vom Antiforgery-System verwendet wird. Wenn nulldas System nur Formulardaten betrachtet.
SuppressXFrameOptionsHeader Gibt an, ob die Generierung des X-Frame-Options Headers unterdrückt werden soll. Standardmäßig wird der Header mit dem Wert "SAMEORIGIN" generiert. Wird standardmäßig auf false festgelegt.

Weitere Informationen finden Sie unter CookieAuthenticationOptions.

Konfigurieren von Antiforgery-Features mit IAntiforgery

IAntiforgery stellt die API bereit, um Antiforgery-Features zu konfigurieren. IAntiforgery kann in der Configure Methode der Startup Klasse angefordert werden.

Im folgenden Beispiel:

  • Middleware von der Startseite der App wird verwendet, um ein Antiforgery-Token zu generieren und sie als Antwort zu cookiesenden.
  • Das Anforderungstoken wird als JavaScript-lesbar cookie mit der standardmäßigen Angular Benennungskonvention gesendet, die im abschnitt AngularJS 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))
        {
            var tokens = antiforgery.GetAndStoreTokens(context);
            context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken, 
                new CookieOptions() { HttpOnly = false });
        }

        return next(context);
    });
}

Erfordern einer Antiforgerieüberprüfung

ValidAntiForgeryToken ist ein Aktionsfilter, der auf eine einzelne Aktion, einen Controller oder global angewendet werden kann. Anforderungen an Aktionen, die diesen Filter angewendet haben, werden blockiert, es sei denn, die Anforderung enthält ein gültiges Antiforgery-Token.

[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 Aktionsmethoden, die er markiert, einschließlich HTTP GET-Anforderungen. Wenn das ValidateAntiForgeryToken Attribut auf die Controller der App angewendet wird, kann er mit dem IgnoreAntiforgeryToken Attribut außer Kraft gesetzt werden.

Hinweis

ASP.NET Core unterstützt das Hinzufügen von Antiforgery-Token nicht automatisch zu GET-Anforderungen.

Automatische Überprüfung von Antiforgerytoken für unsichere HTTP-Methoden nur

ASP.NET Core Apps generieren keine Antiforgerytoken für sichere HTTP-Methoden (GET, HEAD, OPTIONS und TRACE). Anstatt das ValidateAntiForgeryToken Attribut breit anzuwenden und dann mit IgnoreAntiforgeryToken Attributen außer Kraft zu setzen, kann das AutoValidateAntiforgeryToken-Attribut verwendet werden. Dieses Attribut funktioniert identisch mit dem Attribut, außer dass es keine Token für Anforderungen erfordert, die mithilfe der ValidateAntiForgeryToken folgenden HTTP-Methoden vorgenommen wurden:

  • GET
  • HEAD
  • OPTIONS
  • TRACE

Es wird empfohlen, eine allgemeine Verwendung für AutoValidateAntiforgeryToken Nicht-API-Szenarien zu verwenden. Dieses Attribut stellt sicher, dass POST-Aktionen standardmäßig geschützt sind. Die Alternative besteht darin, Antiforgery-Token standardmäßig zu ignorieren, es sei ValidateAntiForgeryToken denn, es wird auf einzelne Aktionsmethoden angewendet. Es ist wahrscheinlicher, dass in diesem Szenario eine POST-Aktionsmethode nicht geschützt wird, indem die App für CSRF-Angriffe anfällig ist. Alle POSTs sollten das Antiforgery-Token senden.

APIs verfügen nicht über einen automatischen Mechanismus zum Senden des Nichtteilscookie des Token. Die Implementierung hängt wahrscheinlich von der Clientcodeimplementierung ab. Einige Beispiele werden unten gezeigt:

Beispiel für Klassenebene:

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

Globales Beispiel:

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

Überschreiben von globalen oder Controller-Antiforgery-Attributen

Der Filter "IgnoreAntiforgeryToken" wird verwendet, um die Notwendigkeit eines Antiforgerytokens für eine bestimmte Aktion (oder Controller) zu beseitigen. Bei Anwendung überschreibt ValidateAntiForgeryToken dieser Filter die AutoValidateAntiforgeryToken auf höherer Ebene angegebenen Filter (global oder auf einem Controller).

[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 auf eine Ansichts- oder Razor Seitenseite umgeleitet wird.

JavaScript, AJAX und SPAs

In herkömmlichen HTML-basierten Apps werden Antiforgery-Token mit ausgeblendeten Formularfeldern an den Server übergeben. In modernen JavaScript-basierten Apps und SPAs werden viele Anforderungen programmgesteuert vorgenommen. Diese AJAX-Anforderungen können andere Techniken (z. B. Anforderungsheader oder cookieS) verwenden, um das Token zu senden.

Wenn cookies verwendet wird, um Authentifizierungstoken zu speichern und API-Anforderungen auf dem Server zu authentifizieren, ist CSRF ein potenzielles Problem. Wenn der lokale Speicher zum Speichern des Token verwendet wird, kann die CSRF-Sicherheitsanfälligkeit verringert werden, da Werte aus dem lokalen Speicher nicht automatisch an den Server mit jeder Anforderung gesendet werden. Wenn Sie den lokalen Speicher verwenden, um das Antiforgery-Token auf dem Client zu speichern und das Token als Anforderungsheader zu senden, ist ein empfohlener Ansatz.

JavaScript

Mithilfe von JavaScript mit Ansichten kann das Token mithilfe eines Diensts aus der Ansicht erstellt werden. Einfügen des Diensts in die IAntiforgery Ansicht und den Aufruf 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>

Dieser Ansatz entfernt die Notwendigkeit, direkt mit den Einstellungen cookievom Server zu umgehen oder sie aus dem Client zu lesen.

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

JavaScript kann auch auf Token in cookies zugreifen und den Inhalt des cookieTokens verwenden, um eine Kopfzeile mit dem Wert des Token zu erstellen.

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

Angenommen, die Skriptanforderungen zum Senden des Token in einer Kopfzeile namens X-CSRF-TOKEN, konfigurieren Sie den Antiforgery-Dienst, um nach der X-CSRF-TOKEN Kopfzeile zu suchen:

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

Angular verwendet eine Konvention zum Adressieren vonJS CSRF. Wenn der Server einen cookie Namen XSRF-TOKENsendet, fügt der Angular-DienstJS$http einen cookie Wert zu einer Kopfzeile hinzu, wenn er eine Anforderung an den Server sendet. Dieser Prozess ist automatisch. Der Client muss die Kopfzeile nicht explizit festlegen. Der Kopfzeilenname ist X-XSRF-TOKEN. Der Server sollte diesen Header erkennen und dessen Inhalt überprüfen.

Damit ASP.NET Core-API mit dieser Konvention in Ihrem Anwendungsstart arbeiten kann:

  • Konfigurieren Sie Ihre App, um ein Token in einem cookie aufgerufenen XSRF-TOKENToken bereitzustellen.
  • Konfigurieren Sie den Antiforgery-Dienst, um nach einem Header namens X-XSRF-TOKENzu suchen, der Angular Standardheadername für das Senden des XSRF-Token ist.
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))
        {
            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)
{
    services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");
}

Windows-Authentifizierung und Antiforgerys cookie

Bei Verwendung der Windows-Authentifizierung müssen Anwendungsendpunkte auf die gleiche Weise wie für cookies geschützt sein. Der Browser sendet implizit den Authentifizierungskontext an den Server und so müssen Endpunkte vor CSRF-Angriffen geschützt werden.

Erweitern von Antiforgerie

Mit IAntiforgeryAdditionalDataProvider dem Typ können Entwickler das Verhalten des Anti-CSRF-Systems erweitern, indem zusätzliche Daten in jedem Token rundet werden. Die GetAdditionalData Methode wird jedes Mal aufgerufen, wenn ein Feldtoken generiert wird, und der Rückgabewert wird innerhalb des generierten Token eingebettet. Ein Implementierunger kann einen Zeitstempel, einen 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 eingeschlossen werden müssen. Wenn ein Token zusätzliche Daten enthält, aber keine IAntiForgeryAdditionalDataProvider konfiguriert ist, wird die ergänzungsdaten nicht überprüft.

Zusätzliche Ressourcen