XSRF/CSRF-Schutz bei ASP.NET MVC und Web Pages

  • Artikel

von Rick Anderson

Die websiteübergreifende Anforderungsfälschung (auch bekannt als XSRF oder CSRF) ist ein Angriff auf im Web gehostete Anwendungen, bei dem eine böswillige Website die Interaktion zwischen einem Clientbrowser und einer Website beeinflussen kann, der von diesem Browser als vertrauenswürdig eingestuft wird. Diese Angriffe werden ermöglicht, da Webbrowser Authentifizierungstoken automatisch mit jeder Anforderung an eine Website senden. Ein typisches Beispiel ist ein Authentifizierungscookie, wie das Authentifizierungsticket von ASP.NET. Allerdings können Websites, die einen beliebigen permanenten Authentifizierungsmechanismus (z. B. Windows-Authentifizierung, Basic usw.) verwenden, von diesen Angriffen angegriffen werden.

Ein XSRF-Angriff unterscheidet sich von einem Phishing-Angriff. Bei Phishing-Angriffen ist die Beihilfe des Opfers erforderlich. Bei einem Phishingangriff imitiert eine böswillige Website die Zielwebsite, und das Opfer wird dazu getäuscht, dem Angreifer vertrauliche Informationen bereitzustellen. Bei einem XSRF-Angriff ist häufig keinerlei Aktion des Opfers erforderlich. Vielmehr verlässt sich der Angreifer darauf, dass der Browser automatisch alle relevanten Cookies an die Zielwebsite sendet.

Weitere Informationen finden Sie unter Open Web Application Security Project (OWASP) XSRF.

Anatomie eines Angriffs

Um einen XSRF-Angriff zu durchlaufen, ziehen Sie einen Benutzer in Betracht, der einige Online-Banking-Transaktionen durchführen möchte. Dieser Benutzer besucht zuerst WoodgroveBank.com und meldet sich an. An diesem Punkt enthält der Antwortheader sein Authentifizierungscookies:

HTTP/1.1 200 OK
Date: Mon, 18 Jun 2012 21:22:33 GMT
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH={authentication-token}; path=/; secure; HttpOnly;
{ Cache-Control, Content-Type, Location, Server and other keys/values not listed. }

Da es sich bei dem Authentifizierungscookies um ein Sitzungscookies handelt, wird es automatisch vom Browser gelöscht, wenn der Browserprozess beendet wird. Bis zu diesem Zeitpunkt schließt der Browser das Cookie jedoch automatisch bei jeder Anforderung an WoodgroveBank.com ein. Der Benutzer möchte jetzt $ 1000 auf ein anderes Konto überweisen, also füllt er ein Formular auf der Bankwebsite aus, und der Browser sendet diese Anforderung an den Server:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=12345&amount=1,000.00

Da dieser Vorgang einen Nebeneffekt hat (er initiiert eine Geldtransaktion), hat sich die Bankwebsite entschieden, einen HTTP POST-Vorgang zu erfordern, um diesen Vorgang zu initiieren. Der Server liest das Authentifizierungstoken aus der Anforderung, sucht die Kontonummer des aktuellen Benutzers, überprüft, ob genügend Mittel vorhanden sind, und initiiert dann die Transaktion im Zielkonto.

Ihr Online-Banking abgeschlossen, der Benutzer navigiert von der Bank-Website und besucht andere Standorte im Web. Eine dieser Websites – fabrikam.com – enthält das folgende Markup auf einer Seite, die in einen <iframe> eingebettet ist:

<form id="theForm" action="https://WoodgroveBank.com/DoTransfer" method="post">
    <input type="hidden" name="toAcct" value="67890" />
    <input type="hidden" name="amount" value="250.00" />
</form>
<script type="text/javascript">
    document.getElementById('theForm').submit();
</script>

Dies führt dann dazu, dass der Browser diese Anforderung sendet:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=67890&amount=250.00

Der Angreifer nutzt die Tatsache aus, dass der Benutzer möglicherweise noch über ein gültiges Authentifizierungstoken für die Zielwebsite verfügt, und er verwendet einen kleinen Javascript-Codeausschnitt, um den Browser dazu zu bringen, automatisch einen HTTP-POST zur Zielwebsite zu erstellen. Wenn das Authentifizierungstoken noch gültig ist, initiiert die Bankwebsite eine Überweisung von 250 US-Dollar auf das Konto des Angreifers.

Ineffektive Entschärfungen

Es ist interessant zu beachten, dass im obigen Szenario die Tatsache, dass auf WoodgroveBank.com über SSL zugegriffen wurde und über ein reines SSL-Authentifizierungscookies verfügte, nicht ausreichte, um den Angriff zu verhindern. Der Angreifer kann das URI-Schema (https) in ihrem <Formularelement> angeben, und der Browser sendet weiterhin nicht abgelaufene Cookies an die Zielwebsite, solange diese Cookies mit dem URI-Schema des beabsichtigten Ziels konsistent sind.

Man könnte argumentieren, dass der Benutzer nicht einfach nicht vertrauenswürdige Websites besuchen sollte, da der Besuch nur vertrauenswürdiger Websites hilft, online sicher zu bleiben. Es gibt eine Wahrheit darüber, aber leider ist dieser Rat nicht immer praktisch. Vielleicht "vertraut" der Benutzer der lokalen Nachrichtenwebsite ConsolidatedMessenger.com und besucht stattdessen diese Website, aber diese Website weist eine XSS-Sicherheitslücke auf, die es einem Angreifer ermöglicht, denselben Codeausschnitt einzuschleusen, der auf fabrikam.com ausgeführt wurde.

Sie können überprüfen, ob eingehende Anforderungen über einen Referer-Header verfügen, der auf Ihre Domäne verweist. Dadurch werden Anforderungen beendet, die unwissentlich von einer Drittanbieterdomäne gesendet werden. Einige Personen deaktivieren jedoch den Referer-Header ihres Browsers aus Datenschutzgründen, und Angreifer können diesen Header manchmal spoofen, wenn das Opfer eine bestimmte unsichere Software installiert hat. Überprüfen, ob der Referer-Header nicht als sicherer Ansatz zur Verhinderung von XSRF-Angriffen angesehen wird.

XSRF-Entschärfungen für Web Stack Runtime

Die ASP.NET Web Stack Runtime verwendet eine Variante des Synchronisierungstokenmusters , um sich vor XSRF-Angriffen zu schützen. Die allgemeine Form des Synchronisierungstokenmusters besteht darin, dass zwei Anti-XSRF-Token mit jedem HTTP POST (zusätzlich zum Authentifizierungstoken) an den Server übermittelt werden: ein Token als Cookie und das andere als Formularwert. Die von der ASP.NET Runtime generierten Tokenwerte sind von einem Angreifer nicht deterministisch oder vorhersagbar. Wenn die Token übermittelt werden, lässt der Server die Fortsetzung der Anforderung nur zu, wenn beide Token eine Vergleichsprüfung bestehen.

Das Sitzungstoken für die Überprüfung der XSRF-Anforderung wird als HTTP-Cookie gespeichert und enthält derzeit die folgenden Informationen in der Nutzlast:

  • Ein Sicherheitstoken, das aus einem zufälligen 128-Bit-Bezeichner besteht.
    Die folgende Abbildung zeigt das Sitzungstoken für die Überprüfung der XSRF-Anforderung, das mit dem Internet Explorer F12-Entwicklertools angezeigt wird: (Beachten Sie, dass dies die aktuelle Implementierung ist und sich wahrscheinlich ändern wird.)

Screenshot: Seite

Das Feldtoken wird als <input type="hidden" /> gespeichert und enthält die folgenden Informationen in der Nutzlast:

Die Nutzlasten der Anti-XSRF-Token sind verschlüsselt und signiert, sodass Sie den Benutzernamen nicht anzeigen können, wenn Sie Tools zum Untersuchen der Token verwenden. Wenn die Webanwendung auf ASP.NET 4.0 ausgerichtet ist, werden kryptografische Dienste von der MachineKey.Encode-Routine bereitgestellt. Wenn die Webanwendung auf ASP.NET Version 4.5 oder höher ausgerichtet ist, werden kryptografische Dienste von der MachineKey.Protect-Routine bereitgestellt, die eine bessere Leistung, Erweiterbarkeit und Sicherheit bietet. Weitere Informationen finden Sie in den folgenden Blogbeiträgen:

Generieren der Token

Um die Anti-XSRF-Token zu generieren, rufen Sie die @Html.AntiForgeryToken-Methode aus einer MVC-Ansicht oder @AntiForgery.GetHtml() von einer Razor-Seite auf. Die Runtime führt dann die folgenden Schritte aus:

  1. Wenn die aktuelle HTTP-Anforderung bereits ein Anti-XSRF-Sitzungstoken (das Anti-XSRF-Cookie __RequestVerificationToken) enthält, wird das Sicherheitstoken daraus extrahiert. Wenn die HTTP-Anforderung kein Anti-XSRF-Sitzungstoken enthält oder wenn die Extraktion des Sicherheitstokens fehlschlägt, wird ein neues zufälliges Anti-XSRF-Token generiert.
  2. Ein Anti-XSRF-Feldtoken wird mithilfe des Sicherheitstokens aus Schritt (1) oben und der Identität des aktuell angemeldeten Benutzers generiert. (Weitere Informationen zum Ermitteln der Benutzeridentität finden Sie weiter unten im Abschnitt Szenarien mit spezieller Unterstützung .) Wenn ein IAntiForgeryAdditionalDataProvider konfiguriert ist, ruft die Runtime die GetAdditionalData-Methode auf und schließt die zurückgegebene Zeichenfolge in das Feldtoken ein. (Weitere Informationen finden Sie im Abschnitt Konfiguration und Erweiterbarkeit .)
  3. Wenn in Schritt (1) ein neues Anti-XSRF-Token generiert wurde, wird ein neues Sitzungstoken erstellt, das es enthält, und es wird der Sammlung ausgehender HTTP-Cookies hinzugefügt. Das Feldtoken aus Schritt (2) wird in ein <input type="hidden" /> -Element umschlossen, und dieses HTML-Markup ist der Rückgabewert von Html.AntiForgeryToken() oder AntiForgery.GetHtml().

Überprüfen der Token

Um die eingehenden Anti-XSRF-Token zu überprüfen, schließt der Entwickler ein ValidateAntiForgeryToken-Attribut in seine MVC-Aktion oder den Controller ein, oder ruft von @AntiForgery.Validate() seiner Razor-Seite auf. Die Runtime führt die folgenden Schritte aus:

  1. Das eingehende Sitzungstoken und das Feldtoken werden gelesen, und das Anti-XSRF-Token wird jeweils extrahiert. Die Anti-XSRF-Token müssen pro Schritt (2) in der Generierungsroutine identisch sein.
  2. Wenn der aktuelle Benutzer authentifiziert ist, wird sein Benutzername mit dem benutzernamen verglichen, der im Feldtoken gespeichert ist. Die Benutzernamen müssen übereinstimmen.
  3. Wenn ein IAntiForgeryAdditionalDataProvider konfiguriert ist, ruft die Runtime ihre ValidateAdditionalData-Methode auf. Die -Methode muss den booleschen Wert true zurückgeben.

Wenn die Validierung erfolgreich ist, kann die Anforderung fortgesetzt werden. Wenn die Überprüfung fehlschlägt, löst das Framework eine HttpAntiForgeryException aus.

Fehlerbedingungen

Ab The ASP.NET Web Stack Runtime v2 enthält jede httpAntiForgeryException , die während der Überprüfung ausgelöst wird, detaillierte Informationen darüber, was schief gelaufen ist. Die derzeit definierten Fehlerbedingungen sind:

  • Das Sitzungstoken oder Formulartoken ist in der Anforderung nicht vorhanden.
  • Das Sitzungstoken oder Formulartoken ist nicht lesbar. Die wahrscheinlichste Ursache hierfür ist eine Farm, in der nicht übereinstimmende Versionen von The ASP.NET Web Stack Runtime ausgeführt werden, oder eine Farm, in der sich das <machineKey-Element> in Web.config von Computer zu Computer unterscheidet. Sie können ein Tool wie Fiddler verwenden, um diese Ausnahme zu erzwingen, indem Sie beide Anti-XSRF-Token manipulieren.
  • Das Sitzungstoken und das Feldtoken wurden ausgetauscht.
  • Das Sitzungstoken und das Feldtoken enthalten nicht übereinstimmende Sicherheitstoken.
  • Der in das Feldtoken eingebettete Benutzername stimmt nicht mit dem Benutzernamen des aktuell angemeldeten Benutzers überein.
  • Die IAntiForgeryAdditionalDataProvider.ValidateAdditionalData-Methode hat false zurückgegeben.

Die Anti-XSRF-Funktionen können auch zusätzliche Überprüfungen während der Tokengenerierung oder -validierung durchführen, und Fehler während dieser Überprüfungen können dazu führen, dass Ausnahmen ausgelöst werden. Weitere Informationen finden Sie in den Abschnitten WIF/ACS/Anspruchsbasierte Authentifizierungund Konfiguration und Erweiterbarkeit .

Szenarien mit besonderer Unterstützung

Anonyme Authentifizierung

Das Anti-XSRF-System enthält spezielle Unterstützung für anonyme Benutzer, wobei "anonym" als Benutzer definiert wird, wobei die IIdentity.IsAuthenticated-Eigenschaftfalse zurückgibt. Szenarien umfassen das Bereitstellen von XSRF-Schutz für die Anmeldeseite (bevor der Benutzer authentifiziert wird) und benutzerdefinierte Authentifizierungsschemas, bei denen die Anwendung einen anderen Mechanismus als IIdentity verwendet, um Benutzer zu identifizieren.

Um diese Szenarien zu unterstützen, denken Sie daran, dass die Sitzungs- und Feldtoken durch ein Sicherheitstoken verbunden sind, bei dem es sich um einen zufällig generierten 128-Bit-Bezeichner handelt. Dieses Sicherheitstoken wird verwendet, um die Sitzung eines einzelnen Benutzers zu verfolgen, während er auf der Website navigiert, sodass es effektiv dem Zweck eines anonymen Bezeichners dient. Anstelle des Benutzernamens wird für die oben beschriebenen Generierungs- und Validierungsroutinen eine leere Zeichenfolge verwendet.

WIF/ACS/Anspruchsbasierte Authentifizierung

Normalerweise verfügen die in der .NET Framework integrierten IIdentity-Klassen über die Eigenschaft, die IIdentity.Name ausreicht, um einen bestimmten Benutzer innerhalb einer bestimmten Anwendung eindeutig zu identifizieren. Beispielsweise gibt FormsIdentity.Name den Benutzernamen zurück, der in der Mitgliedschaftsdatenbank gespeichert ist (die für alle Anwendungen abhängig von dieser Datenbank eindeutig ist), WindowsIdentity.Name gibt die domänenqualifizierte Identität des Benutzers zurück usw. Diese Systeme bieten nicht nur Authentifizierung; sie identifizieren auch Benutzer einer Anwendung.

Die anspruchsbasierte Authentifizierung hingegen erfordert nicht unbedingt die Identifizierung eines bestimmten Benutzers. Stattdessen werden die ClaimsPrincipal- und ClaimsIdentity-Typen einer Reihe von Anspruchsinstanzen zugeordnet, bei denen die einzelnen Ansprüche "ist 18+ Jahre alt" oder "ist ein Administrator" für andere Elemente sein können. Da der Benutzer nicht unbedingt identifiziert wurde, kann die Laufzeit die eigenschaft ClaimsIdentity.Name nicht als eindeutigen Bezeichner für diesen bestimmten Benutzer verwenden. Das Team hat beispiele aus der Praxis gesehen, bei denen ClaimsIdentity.NameNULL zurückgibt, einen Anzeigenamen zurückgibt oder anderweitig eine Zeichenfolge zurückgibt, die für die Verwendung als eindeutiger Bezeichner für den Benutzer nicht geeignet ist.

Viele Bereitstellungen, die anspruchsbasierte Authentifizierung verwenden, verwenden insbesondere Azure Access Control Service (ACS). ACS ermöglicht es dem Entwickler, einzelne Identitätsanbieter (z. B. ADFS, den Microsoft-Kontoanbieter, OpenID-Anbieter wie Yahoo! usw.) zu konfigurieren, und die Identitätsanbieter geben Namensbezeichner zurück. Diese Namensbezeichner können personenbezogene Informationen (Personally Identifiable Information, PII) wie eine E-Mail-Adresse enthalten, oder sie können wie eine private persönliche Id (PPID) anonymisiert werden. Unabhängig davon dient das Tupel (Identitätsanbieter, Namensbezeichner) ausreichend als geeignetes Nachverfolgungstoken für einen bestimmten Benutzer, während er die Website durchsucht, sodass die ASP.NET Web Stack Runtime das Tupel anstelle des Benutzernamens verwenden kann, wenn Anti-XSRF-Feldtoken generiert und überprüft werden. Die spezifischen URIs für den Identitätsanbieter und den Namensbezeichner sind:

  • https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

(Weitere Informationen finden Sie in dieser ACS-Dokumentationsseite .)

Beim Generieren oder Validieren eines Tokens versucht die ASP.NET Web Stack Runtime zur Laufzeit, an die Typen zu binden:

  • Microsoft.IdentityModel.Claims.IClaimsIdentity, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (Für das WIF SDK.)
  • System.Security.Claims.ClaimsIdentity (Für .NET 4.5).

Wenn diese Typen vorhanden sind und die IIIIdentity des aktuellen Benutzers einen dieser Typen implementiert oder unterklassiert, verwendet die XSRF-Anti-XSRF-Funktion das Tupel (Identitätsanbieter, Namensbezeichner) anstelle des Benutzernamens, wenn die Token generiert und überprüft werden. Wenn kein solches Tupel vorhanden ist, schlägt die Anforderung mit einem Fehler fehl, der dem Entwickler beschreibt, wie das Anti-XSRF-System konfiguriert wird, um den jeweiligen verwendeten anspruchsbasierten Authentifizierungsmechanismus zu verstehen. Weitere Informationen finden Sie im Abschnitt Konfiguration und Erweiterbarkeit .

OAuth-/OpenID-Authentifizierung

Schließlich verfügt die Anti-XSRF-Funktion über spezielle Unterstützung für Anwendungen, die die OAuth- oder OpenID-Authentifizierung verwenden. Diese Unterstützung ist heuristischbasiert: Wenn die aktuelle IIdentity.Name mit http:// oder https:// beginnt, werden Benutzernamenvergleiche mithilfe eines Ordinal comparers anstelle des Standardvergleichs OrdinalIgnoreCase durchgeführt.

Konfiguration und Erweiterbarkeit

Gelegentlich möchten Entwickler möglicherweise eine engere Kontrolle über das Anti-XSRF-Generierungs- und Validierungsverhalten. Beispielsweise ist das Standardverhalten der MVC- und Webseitenhilfsprogramme, der Antwort automatisch HTTP-Cookies hinzuzufügen, nicht erwünscht, und der Entwickler möchte die Token möglicherweise an anderer Stelle beibehalten. Es gibt zwei APIs, die sie dabei unterstützen:

AntiForgery.GetTokens(string oldCookieToken, out string newCookieToken, out string formToken);
AntiForgery.Validate(string cookieToken, string formToken);

Die GetTokens-Methode verwendet als Eingabe ein vorhandenes Sitzungstoken für die XSRF-Anforderungsüberprüfung (das null sein kann) und erzeugt als Ausgabe ein neues Sitzungstoken für die Überprüfung der XSRF-Anforderung und ein Feldtoken. Die Token sind einfach undurchsichtige Zeichenfolgen ohne Dekoration. der formToken-Wert für instance nicht in ein <Eingabetag> eingeschlossen werden. Der NewCookieToken-Wert kann NULL sein. wenn dies der Fall ist, ist der OldCookieToken-Wert weiterhin gültig, und es muss kein neues Antwortcookie festgelegt werden. Der Aufrufer von GetTokens ist dafür verantwortlich, alle erforderlichen Antwortcookies beizubehalten oder erforderliche Markups zu generieren. Die GetTokens-Methode selbst ändert die Antwort nicht als Nebeneffekt. Die Validate-Methode akzeptiert die eingehenden Sitzungs- und Feldtoken und führt die oben erwähnte Validierungslogik für sie aus.

AntiForgeryConfig

Der Entwickler kann das Anti-XSRF-System über Application_Start konfigurieren. Die Konfiguration erfolgt programmgesteuert. Die Eigenschaften des statischen AntiForgeryConfig-Typs werden unten beschrieben. Die meisten Benutzer, die Ansprüche verwenden, möchten die UniqueClaimTypeIdentifier-Eigenschaft festlegen.

Eigenschaft Beschreibung
AdditionalDataProvider Ein IAntiForgeryAdditionalDataProvider , der während der Tokengenerierung zusätzliche Daten bereitstellt und während der Tokenvalidierung zusätzliche Daten nutzt. Der Standardwert lautet null. Weitere Informationen finden Sie im Abschnitt IAntiForgeryAdditionalDataProvider .
Cookiename Eine Zeichenfolge, die den Namen des HTTP-Cookies bereitstellt, das zum Speichern des Anti-XSRF-Sitzungstokens verwendet wird. Wenn dieser Wert nicht festgelegt ist, wird automatisch ein Name basierend auf dem bereitgestellten virtuellen Pfad der Anwendung generiert. Der Standardwert lautet null.
Requiressl Ein boolescher Wert, der vorgibt, ob die Anti-XSRF-Token über einen SSL-gesicherten Kanal übermittelt werden müssen. Wenn dieser Wert true ist, wird für alle automatisch generierten Cookies das Flag "secure" festgelegt, und die Anti-XSRF-APIs lösen aus, wenn sie innerhalb einer Anforderung aufgerufen werden, die nicht über SSL übermittelt wird. Der Standardwert ist false.
SuppressIdentityHeuristicChecks Ein boolescher Wert, der vorgibt, ob das Anti-XSRF-System seine Unterstützung für anspruchsbasierte Identitäten deaktivieren soll. Wenn dieser Wert true ist, geht das System davon aus, dass IIdentity.Name für die Verwendung als eindeutiger Benutzerbezeichner geeignet ist, und versucht nicht, IClaimsIdentity oder ClClaimsIdentity in Sonderfällen zu verwenden, wie im Abschnitt WIF/ACS/Anspruchsbasierte Authentifizierung beschrieben. Standardwert: false.
UniqueClaimTypeIdentifier Eine Zeichenfolge, die angibt, welcher Anspruchstyp zur Verwendung als eindeutiger Benutzerbezeichner geeignet ist. Wenn dieser Wert festgelegt ist und die aktuelle IIdentity anspruchsbasiert ist, versucht das System, einen Anspruch des durch UniqueClaimTypeIdentifier angegebenen Typs zu extrahieren, und der entsprechende Wert wird anstelle des Benutzernamens des Benutzers verwendet, wenn das Feldtoken generiert wird. Wenn der Anspruchstyp nicht gefunden wird, schlägt das System die Anforderung fehl. Der Standardwert ist NULL, was angibt, dass das System das Tupel (Identitätsanbieter, Namensbezeichner) verwenden soll, wie zuvor beschrieben anstelle des Benutzernamens des Benutzers.

IAntiForgeryAdditionalDataProvider

Mit dem Typ IAntiForgeryAdditionalDataProvider können Entwickler das Verhalten des Anti-XSRF-Systems erweitern, indem zusätzliche Daten in jedem Token roundtrips ausgeführt 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 beliebigen anderen Wert aus dieser Methode zurückgeben.

Ebenso wird die ValidateAdditionalData-Methode jedes Mal aufgerufen, wenn ein Feldtoken überprüft wird, und die in das Token eingebettete "zusätzliche Daten"-Zeichenfolge wird an die -Methode übergeben. Die Überprüfungsroutine kann ein Timeout (durch Überprüfung der aktuellen Zeit mit der Zeit, die beim Erstellen des Tokens gespeichert wurde), eine Nonce-Überprüfungsroutine oder eine andere gewünschte Logik implementieren.

Entwurfsentscheidungen und Sicherheitsüberlegungen

Das Sicherheitstoken, das die Sitzungs- und Feldtoken verknüpft, ist technisch nur erforderlich, wenn sie versuchen, anonyme/nicht authentifizierte Benutzer vor XSRF-Angriffen zu schützen. Wenn der Benutzer authentifiziert wird, kann das Authentifizierungstoken selbst (vermutlich in Form eines Cookies übermittelt) als eine Hälfte eines Synchrontokenpaars verwendet werden. Es gibt jedoch gültige Szenarien zum Schutz von Anmeldeseiten, die von nicht authentifizierten Benutzern getroffen werden, und die Anti-XSRF-Logik wurde vereinfacht, indem das Sicherheitstoken immer generiert und überprüft wurde, auch für authentifizierte Benutzer. Es bietet auch zusätzlichen Schutz für den Fall, dass ein Feldtoken jemals von einem Angreifer kompromittiert wird, da das Festlegen oder Erraten des Sitzungstokens eine weitere Hürde für den Angreifer darstellen würde.

Entwickler sollten vorsichtshalber vorgehen, wenn mehrere Anwendungen in einer einzelnen Domäne gehostet werden. Obwohl beispielsweise example1.cloudapp.net und example2.cloudapp.net unterschiedliche Hosts sind, besteht eine implizite Vertrauensstellung zwischen allen Hosts unter der Domäne *.cloudapp.net . Diese implizite Vertrauensstellung ermöglicht es potenziell nicht vertrauenswürdigen Hosts, sich gegenseitig auf die Cookies des anderen zu beeinflussen (die Richtlinien des gleichen Ursprungs, die AJAX-Anforderungen regeln, gelten nicht unbedingt für HTTP-Cookies). Die ASP.NET Web Stack Runtime bietet eine gewisse Entschärfung, da der Benutzername in das Feldtoken eingebettet ist. Selbst wenn eine böswillige Unterdomäne ein Sitzungstoken überschreiben kann, kann sie kein gültiges Feldtoken für den Benutzer generieren. Wenn sie jedoch in einer solchen Umgebung gehostet werden, können die integrierten Anti-XSRF-Routinen immer noch nicht gegen Sitzungsentführung oder Anmeldung von XSRF schützen.

Die Anti-XSRF-Routinen schützen derzeit nicht gegen Clickjacking. Anwendungen, die sich gegen Clickjacking verteidigen möchten, können dies problemlos tun, indem sie mit jeder Antwort einen X-Frame-Options: SAMEORIGIN-Header senden. Dieser Header wird von allen aktuellen Browsern unterstützt. Weitere Informationen finden Sie im IE-Blog, im SDL-Blog und im OWASP.For more information, see the IE blog, the SDL blog, and OWASP. Die ASP.NET Web Stack Runtime kann in einer zukünftigen Version dazu führen, dass die MVC- und Webseiten-Anti-XSRF-Hilfsprogramme diesen Header automatisch festlegen, sodass Anwendungen automatisch vor diesem Angriff geschützt werden.

Webentwickler sollten weiterhin sicherstellen, dass ihre Website nicht anfällig für XSS-Angriffe ist. XSS-Angriffe sind sehr leistungsstark, und ein erfolgreicher Exploit würde auch die ASP.NET Web Stack Runtime-Verteidigungen gegen XSRF-Angriffe unterbrechen.

Bestätigung

@LeviBroderick, der einen Großteil der ASP.NET Sicherheitscode für den Großteil dieser Informationen geschrieben hat.