| Produkt/Dienst |
Artikel |
|
Microsoft Entra ID |
|
|
IoT-Gerät |
|
|
Azure DocumentDB |
|
|
ADFS |
|
|
Identity Server |
|
|
Webanwendung |
|
|
Web-API |
|
Implementieren Sie die ordnungsgemäße Abmeldung mit MSAL-Methoden bei der Verwendung von Microsoft Entra ID
Beispiel
services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
options.Events.OnRedirectToIdentityProviderForSignOut = async context =>
{
//Your logic here
};
});
Verwenden von begrenzten Gültigkeitsdauern für generierte SAS-Token
| Titel |
Einzelheiten |
|
Komponente |
IoT-Gerät |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
– |
|
Schritte |
SAS-Token, die für die Authentifizierung für Azure IoT Hub generiert werden, sollten über einen begrenzten Ablaufzeitraum verfügen. Halten Sie die Gültigkeitsdauern von SAS-Token möglichst kurz, um den verfügbaren Zeitraum für die erneute Verwendung zu begrenzen, falls die Token kompromittiert werden. |
Verwenden von minimalen Tokengültigkeitsdauern für generierte Ressourcentoken
| Titel |
Einzelheiten |
|
Komponente |
Azure DocumentDB |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
– |
|
Schritte |
Reduzieren Sie die Zeitspanne von Ressourcentoken auf das erforderliche Minimum. Ressourcentoken sind standardmäßig eine Stunde lang gültig. |
Bei Verwendung von ADFS korrekte Abmeldung mit WsFederation-Methoden implementieren.
| Titel |
Einzelheiten |
|
Komponente |
ADFS |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
– |
|
Schritte |
Wenn für die Anwendung von ADFS ausgestellte STS-Token benötigt werden, sollte der Abmeldeereignishandler die WSFederationAuthenticationModule.FederatedSignOut()-Methode aufrufen, um den Benutzer abzumelden. Außerdem sollte die aktuelle Sitzung zerstört werden, und der Sitzungstokenwert sollte zurückgesetzt und aufgehoben werden. |
Beispiel
[HttpPost, ValidateAntiForgeryToken]
[Authorization]
public ActionResult SignOut(string redirectUrl)
{
if (!this.User.Identity.IsAuthenticated)
{
return this.View("LogOff", null);
}
// Removes the user profile.
this.Session.Clear();
this.Session.Abandon();
HttpContext.Current.Response.Cookies.Add(new System.Web.HttpCookie("ASP.NET_SessionId", string.Empty)
{
Expires = DateTime.Now.AddDays(-1D),
Secure = true,
HttpOnly = true
});
// Signs out at the specified security token service (STS) by using the WS-Federation protocol.
Uri signOutUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Issuer);
Uri replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm);
if (!string.IsNullOrEmpty(redirectUrl))
{
replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm + redirectUrl);
}
// Signs out of the current session and raises the appropriate events.
var authModule = FederatedAuthentication.WSFederationAuthenticationModule;
authModule.SignOut(false);
// Signs out at the specified security token service (STS) by using the WS-Federation
// protocol.
WSFederationAuthenticationModule.FederatedSignOut(signOutUrl, replyUrl);
return new RedirectResult(redirectUrl);
}
Implementierung der richtigen Abmeldung bei der Verwendung von Identity Server
| Titel |
Einzelheiten |
|
Komponente |
Identitätsserver |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
– |
|
Schritte |
Für IdentityServer wird die Erstellung eines Verbunds mit externen Identitätsanbietern unterstützt. Wenn sich ein Benutzer eines vorgeschalteten Identitätsanbieters abmeldet, ist es je nach verwendetem Protokoll unter Umständen möglich, nach dem Abmelden des Benutzers eine Benachrichtigung zu erhalten. IdentityServer kann dann seine Clients benachrichtigen, damit diese den Benutzer ebenfalls abmelden können. Die Details der Implementierung finden Sie in der Dokumentation, die im Bereich „Referenzen“ angegeben ist. |
Für Anwendungen, die per HTTPS verfügbar sind, müssen sichere Cookies verwendet werden
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
Umgebungstyp – OnPrem |
|
Referenzen |
httpCookies-Element (ASP.NET-Einstellungsschema), HttpCookie.Secure-Eigenschaft |
|
Schritte |
Auf Cookies kann normalerweise nur über die Domäne zugegriffen werden, für die sie zugeordnet wurden. Die Definition von „Domäne“ enthält leider nicht das Protokoll, sodass auf Cookies, die per HTTPS erstellt werden, über HTTP zugegriffen werden kann. Mit dem Attribut „secure“ wird für den Browser angegeben, dass das Cookie nur per HTTPS verfügbar gemacht werden sollte. Stellen Sie sicher, dass für alle Cookies, die per HTTPS festgelegt werden, das Attribut secure verwendet wird. Die Anforderung kann in der Datei „web.config“ erzwungen werden, indem das Attribut „requireSSL“ auf „TRUE“ festgelegt wird. Dies ist der bevorzugte Ansatz, da hiermit das Attribut secure für alle aktuellen und zukünftigen Cookies erzwungen wird, ohne dass zusätzliche Codeänderungen vorgenommen werden müssen. |
Beispiel
<configuration>
<system.web>
<httpCookies requireSSL="true"/>
</system.web>
</configuration>
Diese Einstellung wird auch erzwungen, wenn für den Zugriff auf die Anwendung HTTP verwendet wird. Bei Verwendung von HTTP zum Zugriff auf die Anwendung führt die Einstellung dazu, dass die Anwendung nicht mehr funktioniert, da die Cookies mit dem Attribut 'Sicher' (secure) festgelegt werden und der Browser sie nicht an die Anwendung zurücksendet.
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Webformulare, MVC5 |
|
Attribute |
Umgebungstyp – OnPrem |
|
Referenzen |
– |
|
Schritte |
Wenn die Webanwendung die vertrauende Seite ist und der IdP der ADFS-Server ist, kann das Attribut „secure“ des FedAuth-Tokens konfiguriert werden, indem „requireSSL“ im Abschnitt system.identityModel.services der Datei „web.config“ auf „True“ festgelegt wird: |
Beispiel
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:20:0" />
....
</federationConfiguration>
</system.identityModel.services>
Für alle HTTP-basierten Anwendungen sollte HTTP nur für die Cookiedefinition angegeben werden
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
Secure Cookie Attribute (Cookieattribut „Secure“) |
|
Schritte |
Für Cookies wurde das neue Attribut „httpOnly“ eingeführt, um das Risiko einer Offenlegung von Informationen bei einem XSS-Angriff (Cross-Site Scripting) zu verringern. Es wird von allen bekannteren Browsern unterstützt. Mit dem Attribut wird angegeben, dass ein Cookie nicht per Skript zugänglich ist. Durch die Verwendung von HttpOnly-Cookies wird für eine Webanwendung die Gefahr verringert, dass im Cookie enthaltene vertrauliche Informationen per Skript gestohlen und an die Website eines Angreifers gesendet werden. |
Beispiel
Für alle HTTP-basierten Anwendungen, die Cookies verwenden, sollte in der Cookiedefinition „HttpOnly“ angegeben werden, indem die folgende Konfiguration in „web.config“ implementiert wird:
<system.web>
.
.
<httpCookies requireSSL="false" httpOnlyCookies="true"/>
.
.
</system.web>
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Webformulare |
|
Attribute |
– |
|
Referenzen |
FormsAuthentication.RequireSSL-Eigenschaft |
|
Schritte |
Der RequireSSL-Eigenschaftswert wird in der Konfigurationsdatei für eine ASP.NET-Anwendung festgelegt, indem das requireSSL-Attribut des Konfigurationselements verwendet wird. Sie können in der Datei „Web.config“ für Ihre ASP.NET-Anwendung angeben, ob TLS (Transport Layer Security), früher als SSL (Secure Sockets Layer) bezeichnet, zum Zurückgeben des Forms-Authentifizierungscookies an den Server erforderlich ist, indem Sie das Attribut requireSSL festlegen. |
Beispiel
Im folgenden Codebeispiel wird das Attribut „requireSSL“ in der Datei „Web.config“ festgelegt.
<authentication mode="Forms">
<forms loginUrl="member_login.aspx" cookieless="UseCookies" requireSSL="true"/>
</authentication>
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
MVC5 |
|
Attribute |
Umgebungstyp – OnPrem |
|
Referenzen |
Windows Identity Foundation (WIF) Configuration – Part II (WIF-Konfiguration (Windows Identity Foundation) – Teil II) |
|
Schritte |
Zum Angeben des Attributs „httpOnly“ für FedAuth-Cookies sollte der Wert für das Attribut „hideFromScript“ auf „True“ festgelegt werden. |
Beispiel
Hier ist die richtige Konfiguration dargestellt:
<federatedAuthentication>
<cookieHandler mode="Custom"
hideFromScript="true"
name="FedAuth"
path="/"
requireSsl="true"
persistentSessionLifetime="25">
</cookieHandler>
</federatedAuthentication>
Einleiten von Gegenmaßnahmen für Angriffe vom Typ „Websiteübergreifende Anforderungsfälschung“ (CSRF) auf ASP.NET-Webseiten
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
– |
|
Schritte |
Websiteübergreifende Anforderungsfälschung (CSRF oder XSRF) ist ein Angriffstyp, bei dem ein Angreifer Aktionen im Sicherheitskontext einer etablierten Sitzung eines anderen Benutzers auf einer Website ausführen kann. Das Ziel ist das Ändern oder Löschen von Inhalten, wenn die Zielwebsite ausschließlich Sitzungscookies zum Authentifizieren der empfangenen Anforderungen verwendet. Ein Angreifer kann dieses Sicherheitsrisiko ausnutzen, indem er den Browser eines anderen Benutzers zum Laden einer URL mit einem Befehl einer anfälligen Website verwendet, auf der der Benutzer bereits angemeldet ist. Für einen Angreifer gibt es hierfür viele Möglichkeiten, z.B. das Hosten einer anderen Website, die eine Ressource vom anfälligen Server lädt, oder das Verleiten des Benutzers zum Klicken auf einen Link. Dieser Angriff kann verhindert werden, wenn der Server ein weiteres Token an den Client sendet, die Verwendung dieses Tokens in allen zukünftigen Anforderungen zur Bedingung macht und sicherstellt, dass alle zukünftigen Anforderungen ein Token enthalten, das zur aktuellen Sitzung gehört. Zu diesem Zweck kann AntiForgeryToken oder ViewState von ASP.NET verwendet werden. |
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
MVC5, MVC6 |
|
Attribute |
– |
|
Referenzen |
XSRF/CSRF Prevention in ASP.NET MVC and Web Pages (XSRF/CSRF-Verhinderung in ASP.NET MVC und -Webseiten) |
|
Schritte |
Anti-CSRF und ASP.NET-MVC-Formulare: Verwenden Sie die AntiForgeryToken-Hilfsmethode für Ansichten. Fügen Sie Html.AntiForgeryToken() in das Formular ein, z.B.: |
Beispiel
@using (Html.BeginForm("UserProfile", "SubmitUpdate")) {
@Html.ValidationSummary(true)
@Html.AntiForgeryToken()
<fieldset>
Beispiel
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Beispiel
Gleichzeitig erhält der Besucher mit Html.AntiForgeryToken() ein Cookie mit dem Namen „__RequestVerificationToken“. Der Wert entspricht dem oben dargestellten zufälligen ausgeblendeten Wert. Fügen Sie als Nächstes den Filter [ValidateAntiForgeryToken] zur Zielaktionsmethode hinzu, um eine eingehende Formulareingabe zu überprüfen. Beispiel:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Autorisierungsfilter, mit dem Folgendes überprüft wird:
- Die eingehende Anforderung enthält das Cookie „__RequestVerificationToken“.
- Die eingehende Anforderung enthält den
Request.Form-Eintrag „__RequestVerificationToken“.
- Diese Cookie- und
Request.Form-Werte stimmen überein. Sofern keine weiteren Bedenken vorliegen, wird die Anforderung normal verarbeitet. Wenn nicht, tritt ein Autorisierungsfehler mit einer Meldung der Art „Ein erforderliches Antifälschungstoken wurde nicht bereitgestellt oder war ungültig“ auf.
Beispiel
Anti-CSRF und AJAX: Das Formulartoken kann für AJAX-Anforderungen ein Problem darstellen, da eine AJAX-Anforderung unter Umständen JSON-Daten und keine HTML-Formulardaten sendet. Eine Lösung besteht darin, die Token in einem benutzerdefinierten HTTP-Header zu senden. Im folgenden Code wird Razor-Syntax zum Generieren der Token verwendet, und anschließend werden die Token einer AJAX-Anforderung hinzugefügt.
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Beispiel
Extrahieren Sie beim Verarbeiten der Anforderung die Token aus dem Anforderungsheader. Rufen Sie anschließend die AntiForgery.Validate-Methode auf, um die Token zu überprüfen. Die Validate-Methode löst eine Ausnahme aus, wenn die Token nicht gültig sind.
void ValidateRequestHeader(HttpRequestMessage request)
{
string cookieToken = "";
string formToken = "";
IEnumerable<string> tokenHeaders;
if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
{
string[] tokens = tokenHeaders.First().Split(':');
if (tokens.Length == 2)
{
cookieToken = tokens[0].Trim();
formToken = tokens[1].Trim();
}
}
AntiForgery.Validate(cookieToken, formToken);
}
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Webformulare |
|
Attribute |
– |
|
Referenzen |
Nutzen Sie die integrierten Funktionen von ASP.NET, um Webangriffe abzuwehren |
|
Schritte |
CSRF-Angriffen in WebForm-basierten Anwendungen kann begegnet werden, indem Sie „ViewStateUserKey“ auf eine zufällige Zeichenfolge festlegen, die für jeden Benutzer variiert (Benutzer-ID oder, noch besser, Sitzungs-ID). Aus verschiedenen technischen und sozialen Gründen ist die Sitzungs-ID hier deutlich besser geeignet, weil sie unvorhersagbar ist, abläuft und sich von Benutzer zu Benutzer unterscheidet. |
Beispiel
Hier ist der Code angegeben, der auf allen Seiten vorhanden sein muss:
void Page_Init (object sender, EventArgs e) {
ViewStateUserKey = Session.SessionID;
:
}
Einrichten der Sitzung für die Inaktivitätsgültigkeitsdauer
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
HttpSessionState.Timeout-Eigenschaft |
|
Schritte |
Das Sitzungstimeout entspricht dem Ereignis, das eintritt, wenn Benutzer während eines (vom Webserver vorgegebenen) Intervallzeitraums keine Aktion auf einer Website durchführen. Mit dem Ereignis wird auf Serverseite der Status der Benutzersitzung in „Ungültig“ (z. B. „Nicht mehr verwendet“) geändert, und der Webserver wird angewiesen, die Sitzung zu zerstören (Löschen aller enthaltenen Daten). Im folgenden Codebeispiel wird das Attribut für das Sitzungstimeout in der Datei „Web.config“ auf 15 Minuten festgelegt. |
Beispiel
<configuration>
<system.web>
<sessionState mode="InProc" cookieless="true" timeout="15" />
</system.web>
</configuration>
Aktivieren der Bedrohungserkennung in Azure SQL
Beispiel
<forms name=".ASPXAUTH" loginUrl="login.aspx" defaultUrl="default.aspx" protection="All" timeout="15" path="/" requireSSL="true" slidingExpiration="true"/>
</forms>
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Webformulare, MVC5 |
|
Attribute |
Umgebungstyp – OnPrem |
|
Referenzen |
ASDEQA |
|
Schritte |
Wenn die Webanwendung die vertrauende Seite und ADFS der Sicherheitstokendienst (STS) ist, kann die Lebensdauer der Authentifizierungscookies (FedAuth-Token) mit der folgenden Konfiguration in „web.config“ festgelegt werden: |
Beispiel
<system.identityModel.services>
<federationConfiguration>
<!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
<cookieHandler requireSsl="true" persistentSessionLifetime="0.0:15:0" />
<!-- Set requireHttps=true; -->
<wsFederation passiveRedirectEnabled="true" issuer="http://localhost:39529/" realm="https://localhost:44302/" reply="https://localhost:44302/" requireHttps="true"/>
<!--
Use the code below to enable encryption-decryption of claims received from ADFS. Thumbprint value varies based on the certificate being used.
<serviceCertificate>
<certificateReference findValue="4FBBBA33A1D11A9022A5BF3492FF83320007686A" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
</serviceCertificate>
-->
</federationConfiguration>
</system.identityModel.services>
Beispiel
Die Gültigkeitsdauer für das von ADFS ausgestellte SAML-Anspruchstoken sollte ebenfalls auf 15 Minuten festgelegt werden, indem der folgende PowerShell-Befehl auf dem ADFS-Server ausgeführt wird:
Set-ADFSRelyingPartyTrust -TargetName "<RelyingPartyWebApp>" -ClaimsProviderName @("Active Directory") -TokenLifetime 15 -AlwaysRequireAuthentication $true
Implementieren der richtigen Abmeldung von der Anwendung
| Titel |
Einzelheiten |
|
Komponente |
Webanwendung. |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
– |
|
Schritte |
Führen Sie eine korrekte Abmeldung von der Anwendung durch, wenn Benutzer auf die Schaltfläche „Abmelden“ klicken. Beim Abmelden sollte die Anwendung die Sitzung des Benutzers zerstören und außerdem den Sitzungscookiewert zurücksetzen und aufheben. Dies gilt auch für den Authentifizierungscookiewert. Wenn mehrere Sitzungen an eine einzelne Benutzeridentität gebunden sind, müssen sie bei einem Timeout oder bei der Abmeldung alle zusammen beendet werden. Stellen Sie abschließend sicher, dass die Abmeldefunktionalität auf jeder Seite verfügbar ist. |
Abmilderung von CSRF (Websiteübergreifende Anforderungsfälschung) Angriffen auf ASP.NET-Web-APIs
| Titel |
Einzelheiten |
|
Komponente |
Web-API |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
Allgemein |
|
Attribute |
– |
|
Referenzen |
– |
|
Schritte |
Websiteübergreifende Anforderungsfälschung (CSRF oder XSRF) ist ein Angriffstyp, bei dem ein Angreifer Aktionen im Sicherheitskontext einer etablierten Sitzung eines anderen Benutzers auf einer Website ausführen kann. Das Ziel ist das Ändern oder Löschen von Inhalten, wenn die Zielwebsite ausschließlich Sitzungscookies zum Authentifizieren der empfangenen Anforderungen verwendet. Ein Angreifer kann dieses Sicherheitsrisiko ausnutzen, indem er den Browser eines anderen Benutzers zum Laden einer URL mit einem Befehl einer anfälligen Website verwendet, auf der der Benutzer bereits angemeldet ist. Für einen Angreifer gibt es hierfür viele Möglichkeiten, z.B. das Hosten einer anderen Website, die eine Ressource vom anfälligen Server lädt, oder das Verleiten des Benutzers zum Klicken auf einen Link. Dieser Angriff kann verhindert werden, wenn der Server ein weiteres Token an den Client sendet, die Verwendung dieses Tokens in allen zukünftigen Anforderungen zur Bedingung macht und sicherstellt, dass alle zukünftigen Anforderungen ein Token enthalten, das zur aktuellen Sitzung gehört. Zu diesem Zweck kann AntiForgeryToken oder ViewState von ASP.NET verwendet werden. |
| Titel |
Einzelheiten |
|
Komponente |
Web-API |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
MVC5, MVC6 |
|
Attribute |
– |
|
Referenzen |
Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET Web API (Verhindern von Angriffen mit websiteübergreifender Anforderungsfälschung in der ASP.NET-Web-API) |
|
Schritte |
Anti-CSRF und AJAX: Das Formulartoken kann für AJAX-Anforderungen ein Problem darstellen, da eine AJAX-Anforderung unter Umständen JSON-Daten und keine HTML-Formulardaten sendet. Eine Lösung besteht darin, die Token in einem benutzerdefinierten HTTP-Header zu senden. Im folgenden Code wird Razor-Syntax zum Generieren der Token verwendet, und anschließend werden die Token einer AJAX-Anforderung hinzugefügt. |
Beispiel
<script>
@functions{
public string TokenHeaderValue()
{
string cookieToken, formToken;
AntiForgery.GetTokens(null, out cookieToken, out formToken);
return cookieToken + ":" + formToken;
}
}
$.ajax("api/values", {
type: "post",
contentType: "application/json",
data: { }, // JSON data goes here
dataType: "json",
headers: {
'RequestVerificationToken': '@TokenHeaderValue()'
}
});
</script>
Beispiel
Extrahieren Sie beim Verarbeiten der Anforderung die Token aus dem Anforderungsheader. Rufen Sie anschließend die AntiForgery.Validate-Methode auf, um die Token zu überprüfen. Die Validate-Methode löst eine Ausnahme aus, wenn die Token nicht gültig sind.
void ValidateRequestHeader(HttpRequestMessage request)
{
string cookieToken = "";
string formToken = "";
IEnumerable<string> tokenHeaders;
if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
{
string[] tokens = tokenHeaders.First().Split(':');
if (tokens.Length == 2)
{
cookieToken = tokens[0].Trim();
formToken = tokens[1].Trim();
}
}
AntiForgery.Validate(cookieToken, formToken);
}
Beispiel
Anti-CSRF- und ASP.NET MVC-Formulare: Verwenden Sie die AntiForgeryToken-Hilfsmethode für Ansichten. Fügen Sie „Html.AntiForgeryToken()“ in das Formular ein, z.B.:
@using (Html.BeginForm("UserProfile", "SubmitUpdate")) {
@Html.ValidationSummary(true)
@Html.AntiForgeryToken()
<fieldset>
}
Beispiel
Im obigen Beispiel wird etwa Folgendes ausgegeben:
<form action="/UserProfile/SubmitUpdate" method="post">
<input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
<!-- rest of form goes here -->
</form>
Beispiel
Gleichzeitig erhält der Besucher mit Html.AntiForgeryToken() ein Cookie mit dem Namen „__RequestVerificationToken“. Der Wert entspricht dem oben dargestellten zufälligen ausgeblendeten Wert. Fügen Sie als Nächstes den Filter [ValidateAntiForgeryToken] zur Zielaktionsmethode hinzu, um eine eingehende Formulareingabe zu überprüfen. Beispiel:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}
Autorisierungsfilter, mit dem Folgendes überprüft wird:
- Die eingehende Anforderung enthält das Cookie „__RequestVerificationToken“.
- Die eingehende Anforderung enthält den
Request.Form-Eintrag „__RequestVerificationToken“.
- Diese Cookie- und
Request.Form-Werte stimmen überein. Sofern keine weiteren Bedenken vorliegen, wird die Anforderung normal verarbeitet. Wenn nicht, tritt ein Autorisierungsfehler mit einer Meldung der Art „Ein erforderliches Antifälschungstoken wurde nicht bereitgestellt oder war ungültig“ auf.
| Titel |
Einzelheiten |
|
Komponente |
Web-API |
|
SDL-Phase |
Entwickeln |
|
Zutreffende Technologien |
MVC5, MVC6 |
|
Attribute |
Identitätsanbieter: ADFS, Identitätsanbieter: Microsoft Entra ID |
|
Referenzen |
Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2 (Schützen einer Web-API mit einzelnen Konten und lokaler Anmeldung in ASP.NET-Web-API 2.2) |
|
Schritte |
Wenn die Web-API mit OAuth 2.0 geschützt wird, wird im Autorisierungsheader der Anforderung ein Bearertoken erwartet und nur dann Zugriff auf die Anforderung gewährt, wenn das Token gültig ist. Im Gegensatz zur cookie-basierten Authentifizierung fügen Browser die Bearer-Tokens nicht an Anfragen an. Der anfordernde Client muss das Bearertoken explizit im Anforderungsheader anfügen. Daher werden Bearertoken für ASP.NET-Web-APIs, die per OAuth 2.0 geschützt sind, als Verteidigung gegen CSRF-Angriffe angesehen. Beachten Sie Folgendes: Wenn im MVC-Teil der Anwendung die Formularauthentifizierung verwendet wird (also Cookies), müssen für die MVC-Web-App Antifälschungstoken genutzt werden. |
Beispiel
Die Web-API muss angewiesen werden, NUR Bearertoken und keine Cookies zu verwenden. Sie können dazu die folgende Konfiguration in der WebApiConfig.Register-Methode verwenden:
config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));
Die SuppressDefaultHostAuthentication-Methode weist die Web-API an, jegliche Authentifizierung zu ignorieren, die entweder von IIS oder OWIN-Middleware durchgeführt wurde, bevor die Anforderung die Web-API-Pipeline erreicht. Auf diese Weise können Sie die Authentifizierung der Web-API ausschließlich auf Bearertoken einschränken.