Anpassen von HTTP-Sicherheitsantwortheadern mit AD FS 2019

Active Directory-Verbunddienste (Active Directory Federation Services, 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 allgemeinen Sicherheitsrisiken und ermöglichen es ihnen, die neuesten Fortschritte in browserbasierten Schutzmechanismen zu nutzen. Dieses Feature stammt aus der Einführung von zwei 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 ihrer AD FS 2016 die Funktionalität hinzufügen, indem Sie KB4493473 und KB4507459 installieren.

In diesem Artikel werden häufig verwendete Sicherheits-Response-Header erläutert, um zu veranschaulichen, wie Sie Header, die von AD FS 2019 gesendet werden, anpassen können.

Hinweis

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

Szenarien

Die folgenden Szenarien veranschaulichen, dass Administratoren möglicherweise Sicherheitsheader anpassen müssen.

• Ein Administrator hat HTTP Strict-Transport-Security (HSTS) aktiviert, um die Benutzer zu schützen, die über HTTP von einem öffentlichen WLAN-Zugriffspunkt aus auf die Web-App zugreifen können, der möglicherweise gehackt wird. HSTS zwingt alle Verbindungen zur Nutzung von HTTPS-Verschlüsselung. Sie möchten die Sicherheit weiter stärken, indem sie HSTS für Unterdomänen aktivieren.
• Ein Administrator hat die X-Frame-Options Antwortkopfzeile konfiguriert, um die Webseiten vor Clickjacking zu schützen. X-Frame-Options verhindert das Rendern einer Webseite in einem iFrame. Sie müssen den Headerwert jedoch aufgrund einer neuen Geschäftsanforderung anpassen, um Daten (in iFrame) aus einer Anwendung mit einem anderen Ursprung (Domäne) anzuzeigen.
• Ein Administrator hat X-XSS-Protection aktiviert, um die Seite zu sanitieren und zu blockieren, wenn der Browser skriptübergreifende Angriffe erkennt. X-XSS-Protection verhindert skriptübergreifende Angriffe. Sie müssen jedoch die Kopfzeile anpassen, damit die Seite geladen werden kann, nachdem sie bereinigt wurde.
• Ein Administrator muss Cross Origin Resource Sharing (CORS) aktivieren, und er muss den Ursprung (Domäne) in AD FS festlegen, damit eine Einzelseitenanwendung auf eine Web-API mit einer anderen Domäne zugreifen kann.
• Ein Administrator hat den Header für die Inhaltssicherheitsrichtlinie (Content Security Policy, CSP) aktiviert, um websiteübergreifende Skripting- und Dateneinfügungsangriffe zu verhindern, indem alle domänenübergreifenden Anforderungen deaktiviert werden. Aufgrund einer neuen geschäftsspezifischen Anforderung müssen sie jedoch die Kopfzeile anpassen, damit Webseiten Bilder von jedem Ursprung laden und Medien auf vertrauenswürdige Anbieter beschränken können.

HTTP-Sicherheits-Antwort-Header

AD FS fügt die Antwortheader in die ausgehende HTTP-Antwort ein, die an einen Webbrowser gesendet wird. Sie können die Kopfzeilen mithilfe des Get-AdfsResponseHeaders Cmdlets auflisten, wie im folgenden Screenshot gezeigt.

Das ResponseHeaders-Attribut im Screenshot identifiziert die Sicherheitsheader, die von AD FS in jeder HTTP-Antwort enthalten sind. AD FS sendet die Antwortheader nur, wenn ResponseHeadersEnabled auf True (Standardwert) festgelegt ist. Der Wert kann auf False gesetzt werden, um zu verhindern, dass AD FS Sicherheitsheader in die HTTP-Antwort einfügt. Diese Einstellung wird jedoch nicht empfohlen. Sie können ResponseHeaders auf False mit dem folgenden Befehl festlegen.

Set-AdfsResponseHeaders -EnableResponseHeaders $false

HTTP Strict-Transport-Security (HSTS)

HTTP Strict-Transport-Security (HSTS) ist ein Mechanismus für Websicherheitsrichtlinien, der dazu beiträgt, Protokoll-Downgrade-Angriffe und Cookie-Entführung für Dienste mit HTTP- und HTTPS-Endpunkten zu mindern. Es erlaubt Webservern zu deklarieren, dass Webbrowser oder andere konforme Benutzeragenten nur über HTTPS und nie über das HTTP-Protokoll interagieren sollten.

Alle AD FS-Endpunkte für den Webauthentifizierungsdatenverkehr werden ausschließlich über HTTPS geöffnet. Daher entschärft AD FS effektiv die Bedrohungen, die der HTTP Strict Transport Security-Richtlinienmechanismus bereitstellt. Standardmäßig gibt es kein Downgrade auf HTTP, da es keine Listener in HTTP gibt. Die Kopfzeile kann durch Festlegen der folgenden Parameter angepasst werden:

• max-age=<Ablaufzeit>. Die Ablaufzeit (in Sekunden) gibt an, wie lange die Website nur mit HTTPS aufgerufen werden soll. Der Standardwert und der empfohlene Wert beträgt 31536000 Sekunden (ein Jahr).
• includeSubDomains verwenden. Dieser Parameter ist optional. Wenn 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 den max-age (niedrigeren Maximalalterswert wird nicht empfohlen) ändern 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 über das Set-AdfsResponseHeaders Cmdlet entfernen.

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

X-Frame-Options

AD FS lässt standardmäßig nicht zu, dass externe Anwendungen iFrames beim Ausführen der interaktiven Anmeldung verwenden. Diese Konfiguration verhindert bestimmte Art von Phishingangriffen. Die nicht interaktive Anmeldung kann über iFrame aufgrund der zuvor eingerichteten Sicherheit auf Sitzungsebene durchgeführt werden.

In bestimmten seltenen Fällen können Sie jedoch einer bestimmten Anwendung vertrauen, für die eine interaktive AD FS-Anmeldeseite für iFrame erforderlich ist. Die X-Frame-Options Kopfzeile wird zu diesem Zweck verwendet.

Dieser HTTP-Sicherheits-Antwort-Header wird verwendet, um dem Browser mitzuteilen, ob eine Seite in einem <frame>/<iframe> gerendert werden kann. Die Kopfzeile kann auf einen der folgenden Werte festgelegt werden:

• verweigern. Die Seite in einem Frame wird nicht angezeigt. Diese Konfiguration ist die Standardeinstellung und die empfohlene Einstellung.
• gleicher Ursprung. Die Seite wird nur im Frame angezeigt, wenn der Ursprung mit dem Ursprung der Webseite übereinstimmt. Die Option ist nicht nützlich, es sei denn, alle Vorfahren befinden sich ebenfalls im selben Ursprung.
• allow-from <angegebener Ursprung>. Die Seite wird nur im Frame angezeigt, wenn der Ursprung (zum Beispiel https://www.".com) mit dem spezifischen Ursprung in der Kopfzeile übereinstimmt. Einige Browser unterstützen diese Option möglicherweise nicht.

Anpassung von „X-Frame-Options“

Standardmäßig ist die Kopfzeile auf "Verweigern" festgelegt. Administratoren können den Wert jedoch über das Set-AdfsResponseHeaders Cmdlet ä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 über das Set-AdfsResponseHeaders Cmdlet entfernen.

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

X-XSS-Protection

Dieser HTTP-Sicherheits-Header wird verwendet, um zu verhindern, dass Webseiten geladen werden, wenn Browser website-übergreifende Scripting-Angriffe (XSS) erkennen. Dieser Ansatz wird als XSS-Filterung bezeichnet. Die Kopfzeile kann auf einen der folgenden Werte festgelegt werden:

• 0 deaktiviert die XSS-Filterung. Nicht empfohlen.
• 1 aktiviert die XSS-Filterung. Wenn ein XSS-Angriff erkannt wird, wird die Seite vom Browser sanitiert.
• 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 die Kopfzeile auf 1 festgelegt ; mode=block;. Administratoren können den Wert jedoch über das Set-AdfsResponseHeaders Cmdlet ä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; Administratoren können den Header jedoch über das Set-AdfsResponseHeaders Cmdlet entfernen.

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

CORS-Header (Cross-Origin Resource Sharing)

Die Sicherheit des Webbrowsers verhindert, dass eine Webseite ursprungsübergreifende Anfragen, die von innerhalb von Skripten initiiert werden, vornimmt. Möglicherweise möchten Sie jedoch auf Ressourcen in anderen Ursprüngen (Domänen) zugreifen. 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. Mithilfe von CORS kann ein Server einige ursprungsübergreifende Anforderungen explizit zulassen, während andere abgelehnt werden.

Um eine CORS-Anforderung besser zu verstehen, durchläuft das folgende Szenario eine Instanz, in der 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 auf AD FS 2019 konfiguriert sind und AD FS CORS aktiviert hat. AD FS kann CORS-Header in der HTTP-Anforderung identifizieren, Headerwerte überprüfen und entsprechende CORS-Header in die Antwort einschließen. Ausführliche Informationen zum Aktivieren und Konfigurieren von CORS auf AD FS 2019 finden Sie im Abschnitt "CORS Customization". Der folgende Beispielfluss führt Sie durch das Szenario:

1. Ein Benutzer greift über den Client-Browser auf die SPA zu und wird zur Authentifizierung an den AD FS-Authentifizierungsendpunkt umgeleitet. Da SPA für den impliziten Genehmigungsfluss konfiguriert ist, gibt die Anforderung nach erfolgreicher Authentifizierung ein Zugriffs-+ID-Token an den Browser zurück.

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

   • Optionen – beschreibt die Kommunikationsoptionen für die Zielressource.
   • Origin – enthält den Ursprung der Web-API.
   • Access-Control-Request-Method – identifiziert die HTTP-Methode (z. B. DELETE), die verwendet werden soll, wenn eine tatsächliche Anforderung erfolgt.
   • Access-Control-Request-Headers – identifiziert die HTTP-Header, die verwendet werden sollen, wenn eine tatsächliche Anforderung gestellt wird.

   Hinweis

   Eine CORS-Anforderung ähnelt einer standardmäßigen HTTP-Anforderung. 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 den in AD FS konfigurierten vertrauenswürdigen Ursprüngen aufgeführt ist. Weitere Informationen zum Ändern vertrauenswürdiger Ursprünge finden Sie unter CORS Customization. AD FS antwortet dann mit den folgenden Headern:

   • Access-Control-Allow-Origin - Wert wie im Origin-Header.
   • Access-Control-Allow-Method - Wert wie im Access-Control-Request-Method Header.
   • Access-Control-Allow-Headers - Wert wie im Access-Control-Request-Headers Header.

4. Der Browser sendet die tatsächliche Anforderung einschließlich der folgenden Header:

   • HTTP-Methode (z. B. DELETE).
   • Origin – umfasst den Ursprung der Web-API.
   • Alle im „Access-Control-Allow-Headers“-Antwortheader enthaltenen Header

5. Nach der Überprüfung genehmigt AD FS die Anforderung, indem sie die Web-API-Domäne (Ursprung) in den Antwortheader "Access-Control-Allow-Origin" einfügt.

6. Die Einbeziehung des Access-Control-Allow-Origin-Headers ermöglicht es dem Browser, die angeforderte API aufzurufen.

CORS-Anpassung

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

Set-AdfsResponseHeaders -EnableCORS $true

Nachdem sie aktiviert wurde, können Administratoren eine Liste vertrauenswürdiger Ursprünge mithilfe desselben Cmdlets aufzählen. Beispielsweise würde der folgende Befehl CORS-Anfragen von den Ursprüngen https://example1.com und https://example1.com erlauben.

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 einschließen, obwohl dieser Ansatz aufgrund von Sicherheitsrisiken nicht empfohlen wird und eine Warnmeldung bereitgestellt wird, wenn sie sich dafür entscheiden.

Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)

Dieser HTTP-Sicherheitsheader wird verwendet, um Cross-Site-Scripting, Clickjacking und andere Dateneinfügungsangriffe zu verhindern, indem er verhindert, dass Browser versehentlich schädliche Inhalte ausführen. Browser, die die Inhaltssicherheitsrichtlinie (Content Security Policy, CSP) nicht unterstützen, ignorieren die CSP-Header.

CSP-Anpassung

Die Anpassung des CSP-Headers umfasst das Ändern der Sicherheitsrichtlinie, 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 Standard-src-Direktive wird verwendet, um -src-Direktiven zu ändern, ohne jede Direktive explizit aufzulisten. Im folgenden Beispiel entspricht die Richtlinie 1 beispielsweise der 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 Direktive explizit aufgeführt ist, überschreibt der angegebene Wert den für "default-src" angegebenen Wert. Im folgenden Beispiel akzeptiert der img-src den Wert als "*" (sodass Bilder aus einem beliebigen Ursprung geladen werden können), während andere -src Direktiven den Wert als "self" (einschränken auf denselben Ursprung wie die Webseite) übernehmen.

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 beschränkt die Herkunft des zu ladenden Inhalts auf den Ursprung der Webseite.
• „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" – Wenn Sie diese Quelle angeben, wird das Laden von Inhalten aus jeglichem Ursprung verhindert.
• daten: - Angabe von Daten: URIs ermöglichen Inhaltserstellern das Einbetten kleiner Dateien inline in Dokumente. Die Verwendung wird nicht empfohlen.

Hinweis

AD FS verwendet JavaScript im Authentifizierungsprozess und aktiviert daher JavaScript, indem er "unsichere Inline"- und "unsichere Eval"-Quellen in die Standardrichtlinie einschl.

Benutzerdefinierte Header

Neben den zuvor aufgeführten Sicherheitsantwortheadern (HSTS, CSP, X-Frame-Options, X-XSS-Protection und CORS) können Sie mit AD FS 2019 neue Header festlegen.

Als Beispiel könnten Sie einen neuen Header "TestHeader" und "TestHeaderValue" als Wert festlegen.

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

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

Screenshot von Fiddler im Kopfzeilen-Tab, auf dem TestHeader: TestHeaderValue unter Verschiedenes hervorgehoben wird.

Webbrowserkompatibilität

Verwenden Sie die folgende Tabelle und die Weblinks, um festzustellen, welche Webbrowser mit den jeweiligen Sicherheitsheadern 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
Cross-Origin Resource Sharing (CORS)	CORS-Browserkompatibilität
Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)	CSP-Browserkompatibilität

Weiter

• AD FS-Problembehandlung