Freigeben über

Anpassen der HTTP-Sicherheitsantwortheader mit AD FS 2019

Active Directory-Verbunddienste (AD FS) 2019 fügt die Funktionalität zum Anpassen der von AD FS gesendeten HTTP-Sicherheitsantwortheader hinzu. Diese Tools helfen Administratoren beim Schutz vor häufigen Sicherheitsrisiken und ermöglichen es ihnen, von den neuesten Entwicklungen bei browserbasierten Schutzmechanismen zu profitieren. Diese Funktion ergibt sich aus der Einführung der beiden neuen Cmdlets: Get-AdfsResponseHeaders und Set-AdfsResponseHeaders.

Hinweis

Die Funktionalität zum Anpassen der HTTP-Sicherheitsantwortheader (ausgenommen CORS-Header) mithilfe der Cmdlets Get-AdfsResponseHeaders und Set-AdfsResponseHeaders wurde nach AD FS 2016 zurückportiert. Sie können die Funktionalität Ihrem AD FS 2016 hinzufügen, indem Sie KB4493473 und KB4507459 installieren.

In diesem Artikel werden häufig verwendete Sicherheitsantwortheader erläutert, um zu veranschaulichen, wie von AD FS 2019 gesendete Header angepasst werden können.

Hinweis

Im Artikel wird davon ausgegangen, dass Sie AD FS 2019 installiert haben.

Szenarien

Die folgenden Szenarien zeigen, dass Administratoren die Sicherheitsheader unter Umständen anpassen müssen.

  • Ein/e Administrator*in hat HTTP Strict-Transport-Security (HSTS) aktiviert, um die Benutzer*innen, die möglicherweise über HTTP auf die Web-App zugreifen, vor einem öffentlichen WLAN-Zugriffspunkt zu schützen, der eventuell gehackt wurde. HSTS erzwingt für alle Verbindungen die HTTPS-Verschlüsselung. Er möchte die Sicherheit durch die Aktivierung von HSTS für Unterdomänen noch weiter erhöhen.
  • Ein/e Administrator*in hat den X-Frame-Options-Antwortheader konfiguriert, um die Webseiten vor Clickjacking zu schützen. X-Frame-Options verhindert, dass Webseiten in einem iFrame gerendert werden. Er muss jedoch den Headerwert aufgrund einer neuen Geschäftsanforderung anpassen, damit Daten (in einem iFrame) aus einer Anwendung mit einem anderen Ursprung (Domäne) angezeigt werden.
  • Ein/e Administrator*in hat X-XSS-Protection aktiviert, um die Seite zu bereinigen und zu blockieren, wenn der Browser Cross-Scripting-Angriffe erkennt. X-XSS-Protection verhindert Cross-Scripting-Angriffe. Der Header muss jedoch so angepasst werden, dass die Seite nach der Bereinigung geladen werden darf.
  • Ein/e Administrator*in muss CORS (Cross Origin Resource Sharing) aktivieren und den Ursprung (Domäne) auf AD FS festlegen, damit eine Einzelseitenanwendung auf eine Web-API mit einer anderen Domäne zugreifen kann.
  • Ein/e Administrator*in hat den CSP (Content Security Policy)-Header aktiviert, um Cross-Site-Scripting- und Dateneinschleusungsangriffe zu verhindern, indem domänenübergreifende Anforderungen nicht zugelassen werden. Aufgrund einer neuen Geschäftsanforderung muss der Header jedoch so angepasst werden, dass die Webseite das Laden von Bildern von jedem Ursprung zulässt und Medien auf vertrauenswürdige Anbieter beschränkt.

HTTP-Sicherheitsantwortheader

AD FS fügt die Antwort-Header in die ausgehende HTTP-Antwort ein, die von einem Webbrowser gesendet wird. Sie können die Header mit dem Cmdlet Get-AdfsResponseHeaders auflisten, wie im folgenden Screenshot gezeigt.

Screenshot that shows the PowerShell output from Get-AdfsResponseHeaders.

Das ResponseHeaders-Attribut im obigen Screenshot identifiziert die Sicherheitsheader, die von AD FS in jede HTTP-Antwort aufgenommen werden. AD FS sendet die Antwortheader nur dann, wenn ResponseHeadersEnabled auf True (Standardwert) festgelegt ist. Der Wert kann auf False festgelegt werden, um zu verhindern, dass AD FS einen der Sicherheitsheader in die HTTP-Antwort aufnimmt. Diese Einstellung wird jedoch nicht empfohlen. Sie können ResponseHeaders mit dem folgenden Befehl auf False festlegen:

Set-AdfsResponseHeaders -EnableResponseHeaders $false

HTTP Strict-Transport-Security (HSTS)

HSTS (HTTP Strict Transport Security) ist ein Richtlinienmechanismus für Websicherheit, mit dessen Hilfe Angriffe zur Herabstufung des Protokolls und Cookieübernahme für Dienste reduziert werden, die sowohl über HTTP- als auch über HTTPS-Endpunkte verfügen. Auf diese Weise können Webserver erklären, dass Webbrowser (oder andere entsprechende Benutzer-Agents) nur über HTTPS und niemals über das HTTP-Protokoll interagieren sollten.

Alle AD FS-Endpunkte für den Webauthentifizierungsdatenverkehr werden ausschließlich über HTTPS geöffnet. Infolgedessen entschärft AD FS wirksam die Bedrohungen, die der Richtlinienmechanismus HTTP Strict Transport Security bietet. Standardmäßig ist kein Downgrade auf HTTP möglich, da es in HTTP keine Listener gibt. Der Header kann durch Festlegen der folgenden Parameter angepasst werden:

  • max-age=<expire-time>. Die Ablaufzeit (in Sekunden) gibt an, wie lange nur über HTTPS auf die Website zugegriffen werden soll. Der Standardwert (und der empfohlene Wert) ist 31536000 Sekunden (1 Jahr).
  • includeSubDomains. Dieser Parameter ist optional. Falls angegeben, gilt die HSTS-Regel auch für alle Unterdomänen.

HSTS-Anpassung

Standardmäßig ist der Header aktiviert und max-age auf ein Jahr festgelegt. Administratoren können max-age jedoch ändern (das Herabsetzen des „max-age“-Werts wird nicht empfohlen) oder HSTS für Unterdomänen über das Cmdlet Set-AdfsResponseHeaders aktivieren.

Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=<seconds>; includeSubDomains"

Beispiel:

Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=31536000; includeSubDomains"

Standardmäßig ist der Header im ResponseHeaders-Attribut enthalten. Administratoren können den Header jedoch mit dem Cmdlet Set-AdfsResponseHeaders entfernen.

Set-AdfsResponseHeaders -RemoveHeaders "Strict-Transport-Security"

X-Frame-Options

AD FS lässt standardmäßig nicht zu, dass externe Anwendungen beim Durchführen interaktiver Anmeldungen iFrames verwenden. Diese Konfiguration verhindert eine bestimmte Art von Phishing-Angriffen. Nicht-interaktive Anmeldungen können über iFrame ausgeführt werden, da zuvor Sicherheitsmaßnahmen auf Sitzungsebene eingerichtet wurden.

In einigen seltenen Fällen kann es jedoch vorkommen, dass Sie einer bestimmten Anwendung vertrauen, die eine iFrame-fähige interaktive AD FS-Anmeldeseite erfordert. Zu diesem Zweck wird der X-Frame-Options-Header verwendet.

Dieser HTTP-Sicherheitsantwortheader wird verwendet, um dem Browser mitzuteilen, ob er eine Seite in einem <Frame>/<iframe> rendern kann. Der Header kann auf einen der folgenden Werte festgelegt werden:

  • deny (verweigern). Die in einem Frame enthaltene Seite wird nicht angezeigt. Diese Konfiguration ist die Standardeinstellung und die empfohlene Einstellung.
  • sameorigin (gleicher Ursprung). Die Seite wird nur im Frame angezeigt, wenn dessen Ursprung mit dem Ursprung der Webseite identisch ist. Diese Option ist nur sinnvoll, wenn alle Vorfahren denselben Ursprung haben.
  • allow-from <angegebener Ursprung>. Die Seite wird nur dann im Frame angezeigt, wenn der Ursprung (z. B. https://www.".com) dem im Header angegebenen Ursprung entspricht. Diese Option wird möglicherweise nicht von allen Browsern unterstützt.

Anpassung von „X-Frame-Options“

Standardmäßig wird der Header auf „deny“ (verweigern) festgelegt. Administratoren können den Wert jedoch mit dem Cmdlet Set-AdfsResponseHeaders ändern.

Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "<deny/sameorigin/allow-from<specified origin>>"

Beispiel:

Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "allow-from https://www.example.com"

Standardmäßig ist der Header im ResponseHeaders-Attribut enthalten. Administratoren können den Header jedoch mit dem Cmdlet Set-AdfsResponseHeaders entfernen.

Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"

X-XSS-Protection

Dieser HTTP-Sicherheitsantwortheader wird verwendet, um das Laden von Webseiten zu verhindern, wenn Browser XSS-Angriffe (Cross-Site Scripting) erkennen. Dieser Ansatz wird als XSS-Filterung bezeichnet. Der Header kann auf einen der folgenden Werte festgelegt werden:

  • 0 deaktiviert die XSS-Filterung. Nicht empfehlenswert.
  • 1 aktiviert die XSS-Filterung. Wenn ein XSS-Angriff erkannt wird, bereinigt der Browser die Seite.
  • 1; mode=block aktiviert die XSS-Filterung. Wenn ein XSS-Angriff erkannt wird, verhindert der Browser das Rendern der Seite. Diese Einstellung ist die Standardeinstellung und die empfohlene Einstellung.

Anpassung von „X-XSS-Protection“

Standardmäßig ist der Header auf 1; mode=block;festgelegt. Administratoren können den Wert jedoch mit dem Cmdlet Set-AdfsResponseHeaders ändern.

Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "<0/1/1; mode=block/1; report=<reporting-uri>>"

Beispiel:

Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "1"

Standardmäßig ist der Header im ResponseHeaders-Attribut enthalten. Allerdings können Administratoren den Header mit dem Cmdlet Set-AdfsResponseHeaders entfernen.

Set-AdfsResponseHeaders -RemoveHeaders "X-XSS-Protection"

CORS-Header (Cross-Origin Resource Sharing)

Die Webbrowsersicherheit verhindert, dass eine Webseite ursprungsübergreifende Anforderungen ausführt, die aus Skripts initiiert werden. Es kann jedoch vorkommen, dass Sie auf Ressourcen an anderen Ursprüngen (Domänen) zugreifen möchten. CORS (Cross Origin Resource Sharing; Ressourcenfreigabe zwischen verschiedenen Ursprüngen) ist ein W3C-Standard, der einem Server eine weniger strenge Anwendung der Richtlinie des gleichen Ursprungs ermöglicht. Durch die Verwendung von CORS kann ein Server explizit einige usprungsübergreifende Anforderungen zulassen und andere ablehnen.

Um CORS-Anforderungen besser zu verstehen, wird im folgenden Szenario ein Fall durchgespielt, in dem eine Einzelseitenanwendung (Single Page Application, SPA) eine Web-API mit einer anderen Domäne aufrufen muss. Beachten Sie außerdem, dass sowohl SPA als auch API in AD FS 2019 konfiguriert sind und CORS in AD FS aktiviert ist. AD FS kann CORS-Header in der HTTP-Anforderung identifizieren, Headerwerte überprüfen und entsprechende CORS-Header in die Antwort aufnehmen. Ausführliche Informationen zum Aktivieren und Konfigurieren von CORS in AD FS 2019 finden Sie im Abschnitt CORS-Anpassung. Der folgende Beispielflow führt Sie durch das Szenario:

  1. Ein Benutzer/eine Benutzerin greift über den Clientbrowser auf die SPA zu und wird zur Authentifizierung an den AD FS-Authentifizierungsendpunkt weitergeleitet. Da die SPA für den impliziten Gewährungsflow konfiguriert ist, gibt die Anforderung nach erfolgreicher Authentifizierung ein Zugriffs- und ID-Token an den Browser zurück.

  2. Nach der Benutzerauthentifizierung stellt das in der SPA enthaltene Front-End-JavaScript eine Anforderung zum Zugriff auf die Web-API. Die Anforderung wird mit den folgenden Headern an AD FS umgeleitet:

    • „Options“: Beschreibt die Kommunikationsoptionen für die Zielressource.
    • „Origin“: Schließt den Ursprung der Web-API ein.
    • Access-Control-Request-Method: Gibt die HTTP-Methode (z. B. DELETE) an, die in einer tatsächlichen Anforderung verwendet werden soll.
    • „Access-Control-Request-Headers“: Identifiziert die HTTP-Header, die in einer tatsächlichen Anforderung verwendet werden sollen.

    Hinweis

    Eine CORS-Anforderung ähnelt einer HTTP-Standardanforderung. Das Vorhandensein eines Origin-Headers signalisiert jedoch, dass die eingehende Anforderung mit CORS zusammenhängt.

  3. AD FS überprüft, ob der im Header enthaltene Web-API-Ursprung in der in AD FS konfigurierten Liste vertrauenswürdiger Ursprünge aufgeführt ist. Weitere Informationen zum Ändern vertrauenswürdiger Ursprünge finden Sie unter CORS-Anpassung. AD FS antwortet dann mit den folgenden Headern:

    • „Access-Control-Allow-Origin“: Identischer Wert wie im Origin-Header.
    • „Access-Control-Allow-Method“: Identischer Wert wie im „Access-Control-Request-Method“-Header.
    • „Access-Control-Allow-Headers“: Identischer Wert wie im „Access-Control-Request-Headers“-Header.

  4. Der Browser sendet die tatsächliche Anforderung mit den folgenden Headern:

    • HTTP-Methode (z. B. DELETE).
    • „Origin“: Schließt den Ursprung der Web-API ein.
    • Alle im „Access-Control-Allow-Headers“-Antwortheader enthaltenen Header.

  5. Nach erfolgreicher Überprüfung genehmigt AD FS die Anforderung, indem die Web-API-Domäne (Ursprung) in den „Access-Control-Allow-Origin“-Antwortheader aufgenommen wird.

  6. Durch Einbindung des „Access-Control-Allow-Origin“-Headers wird es dem Browser ermöglicht, die angeforderte API aufzurufen.

CORS-Anpassung

Standardmäßig ist die CORS-Funktionalität nicht aktiviert. Administratoren können die Funktionalität jedoch über das Cmdlet Set-AdfsResponseHeaders aktivieren.

Set-AdfsResponseHeaders -EnableCORS $true

Nach der Aktivierung können Administratoren mithilfe desselben Cmdlets eine Liste vertrauenswürdiger Ursprünge erstellen. Der folgende Befehl würde beispielsweise CORS-Anforderungen von den Ursprüngen https&#58;//example1.com und https&#58;//example1.com zulassen.

Set-AdfsResponseHeaders -CORSTrustedOrigins https://example1.com,https://example2.com

Hinweis

Administratoren können CORS-Anforderungen von jedem Ursprung zulassen, indem sie „*“ in die Liste der vertrauenswürdigen Ursprünge einfügen. Jedoch wird dieser Ansatz aufgrund von Sicherheitsrisiken nicht empfohlen, und es wird eine Warnmeldung angezeigt, wenn sie ihn dennoch verwenden.

Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)

Dieser HTTP-Sicherheitsantwortheader wird verwendet, um Cross-Site-Scripting, Clickjacking und andere Dateneinschleusungsangriffe zu verhindern, indem Browser daran gehindert werden, versehentlich schädliche Inhalte auszuführen. Browser, die keine Inhaltssicherheitsrichtlinie (Content Security Policy, CSP) unterstützen, ignorieren die CSP-Antwortheader.

CSP-Anpassung

Bei der Anpassung des CSP-Headers wird die Sicherheitsrichtlinie geändert, die die Ressourcen definiert, die der Browser für die Webseite laden darf. Die Standardsicherheitsrichtlinie lautet:

Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:;

Die default-src-Anweisung wird verwendet, um -src-Anweisungen zu ändern, ohne dabei jede Anweisung explizit aufzulisten. Im folgenden Beispiel ist beispielsweise Richtlinie 1 identisch mit Richtlinie 2.

Richtlinie 1

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'"

Richtlinie 2

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "script-src 'self'; img-src 'self'; font-src 'self';
frame-src 'self'; manifest-src 'self'; media-src 'self';"

Wenn eine Anweisung explizit aufgeführt wird, überschreibt der angegebene Wert den für „default-src“ angegebenen Wert. Im folgenden Beispiel nimmt „img-src“ den Wert „*“ an (was das Laden von Bildern von jedem Ursprung zulässt), während andere „-src“-Anweisungen den Wert „self“ annehmen (und dadurch auf denselben Ursprung wie die Webseite beschränkt sind).

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'; img-src *"

Die folgenden Quellen können für die „default-src“-Richtlinie definiert werden:

  • „self“: Die Angabe dieser Quelle schränkt den Ursprung zu ladender Inhalte auf den Ursprung der Webseite ein.
  • „unsafe-inline“: Die Angabe dieser Quelle in der Richtlinie ermöglicht die Verwendung von Inline-JavaScript und -CSS.
  • „unsafe-eval“: Die Angabe dieser Quelle in der Richtlinie ermöglicht die Verwendung von Text-zu-JavaScript-Mechanismen wie „eval“.
  • „none“: Die Angabe dieser Quelle schränkt das Laden von Inhalten jeglichen Ursprungs ein.
  • „data“: Die Angabe von „data: URIs“ ermöglicht Inhaltsersteller*innen, kleine Dateien inline in Dokumente einzubetten. Die Verwendung wird nicht empfohlen.

Hinweis

AD FS verwendet JavaScript im Authentifizierungsprozess und aktiviert somit JavaScript, indem die Quellen „unsafe-inline“ und „unsafe-eval“ in die Standardrichtlinie eingeschlossen werden.

Benutzerdefinierte Header

Zusätzlich zu den oben aufgeführten Sicherheitsantwortheadern (HSTS, CSP, X-Frame-Options, X-XSS-Protection und CORS) können Sie in AD FS 2019 neue Header festlegen.

Beispielsweise könnten Sie einen neuen Header „TestHeader“ mit dem Wert „TestHeaderValue“ festlegen.

Set-AdfsResponseHeaders -SetHeaderName "TestHeader" -SetHeaderValue "TestHeaderValue"

Nachdem der neue Header festgelegt wurde, wird er in der AD FS-Antwort gesendet, wie im folgenden Fiddler-Codeausschnitt gezeigt:

Screenshot of Fiddler on the headers tab that highlights TestHeader: TestHeaderValue under Miscellaneous.

Webbrowserkompatibilität

Verwenden Sie die folgende Tabelle und die Links, um zu ermitteln, welche Webbrowser mit den einzelnen Sicherheitsantwortheadern kompatibel sind.

HTTP-Sicherheitsantwortheader Browserkompatibilität
HTTP Strict-Transport-Security (HSTS) HSTS-Browserkompatibilität
X-Frame-Options „X-Frame-Options“-Browserkompatibilität
X-XSS-Protection „X-XSS-Protection“-Browserkompatibilität
Ressourcenfreigabe zwischen verschiedenen Ursprüngen (CORS) CORS-Browserkompatibilität
Inhaltssicherheitsrichtlinie (Content Security Policy, CSP) CSP-Browserkompatibilität

Nächste