Mit der OpenIdConnect-Middleware von ASP.NET Core kann Ihre App den Aufruf an den Microsoft Identity Platform-Abmeldeendpunkt durch die Bereitstellung eines OpenId Connect-Ereignisses namens OnRedirectToIdentityProviderForSignOut abfangen.
Verwenden von begrenzten Gültigkeitsdauern für generierte SAS-Token
Titel
Details
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
Details
Komponente
Azure DocumentDB
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Reduzieren Sie die Zeitspanne von Ressourcentoken auf das erforderliche Minimum. Ressourcentoken verfügen über einen gültigen Zeitspannenwert von einer Stunde.
Implementieren der richtigen Abmeldung mit WsFederation-Methoden bei Verwendung von ADFS
Titel
Details
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);
}
Implementieren der richtigen Abmeldung bei Verwendung von Identity Server
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
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.
Diese Einstellung wird auch erzwungen, wenn für den Zugriff auf die Anwendung HTTP verwendet wird. Bei Verwendung von HTTP zum Zugreifen auf die Anwendung führt die Einstellung für die Anwendung zu einem Fehler, da die Cookies mit dem Attribut „secure“ festgelegt werden und der Browser sie nicht zurück an die Anwendung sendet.
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Web Forms, MVC5
Attribute
EnvironmentType – 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
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:
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.
Einleiten von Gegenmaßnahmen für Angriffe vom Typ „Websiteübergreifende Anforderungsfälschung“ auf ASP.NET-Webseiten
Titel
Details
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.
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.:
<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 zum Überprüfen einer eingehenden Formularbereitstellung der Zielaktionsmethode als Nächstes den Filter [ValidateAntiForgeryToken] hinzu. 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 die Token beim Verarbeiten der Anforderung 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.
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:
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.
Wenn die Webanwendung die vertrauende Seite und AD FS der Sicherheitstokendienst 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:
Implementieren der richtigen Abmeldung von der Anwendung
Titel
Details
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.
Einleiten von Gegenmaßnahmen für Angriffe vom Typ „Websiteübergreifende Anforderungsfälschung“ auf ASP.NET-Web-APIs
Titel
Details
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.
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 die Token beim Verarbeiten der Anforderung 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.
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.:
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 zum Überprüfen einer eingehenden Formularbereitstellung der Zielaktionsmethode als Nächstes den Filter [ValidateAntiForgeryToken] hinzu. 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
Details
Komponente
Web-API
SDL-Phase
Entwickeln
Zutreffende Technologien
MVC5, MVC6
Attribute
Identitätsanbieter: ADFS, Identitätsanbieter: Microsoft Entra ID
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 cookiebasierten Authentifizierung fügen Browser die Bearertoken nicht an Anforderungen 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:
Die SuppressDefaultHostAuthentication-Methode weist die Web-API an, Authentifizierungen zu ignorieren, die vor dem Empfang der Anforderung in der Web-API-Pipeline durchgeführt wurden. Dazu wird IIS oder OWIN-Middleware verwendet. Auf diese Weise können Sie die Authentifizierung der Web-API ausschließlich auf Bearertoken einschränken.