Personnalisation des en-têtes de réponse de sécurité HTTP avec AD FS 2019
Les services de fédération Active Directory (AD FS) 2019 ajoutent la fonctionnalité permettant de personnaliser les en-têtes de réponse de sécurité HTTP envoyés par AD FS. Ces outils aident les administrateurs à se protéger contre les vulnérabilités de sécurité courantes et à tirer parti des dernières avancées des mécanismes de protection basés sur un navigateur. Cette fonctionnalité provient de l’introduction de deux nouvelles cmdlets : Get-AdfsResponseHeaders
et Set-AdfsResponseHeaders
.
Notes
La fonctionnalité permettant de personnaliser les en-têtes de réponse de sécurité HTTP (à l’exception des en-têtes CORS) à l’aide des cmdlets Get-AdfsResponseHeaders
et Set-AdfsResponseHeaders
a été rétroportée vers AD FS 2016. Pour pouvoir ajouter des fonctionnalités à AD FS 2016, installez KB4493473 et KB4507459.
Cet article aborde les en-têtes de réponse de sécurité couramment utilisés pour montrer comment personnaliser les en-têtes envoyés par AD FS 2019.
Notes
L’article part du principe que vous avez installé AD FS 2019.
Scénarios
Les scénarios suivants illustrent la nécessité pour les administrateurs de personnaliser les en-têtes de sécurité.
- Un administrateur a activé HTTP Strict-Transport-Security (HSTS) pour protéger les utilisateurs qui peuvent accéder à l’application web à l’aide du protocole HTTP à partir d’un point d’accès Wi-Fi public susceptible d’avoir été piraté. HSTS force toutes les connexions par chiffrement HTTPS. Il aimerait renforcer la sécurité en activant le mécanisme HSTS pour les sous-domaines.
- Un administrateur a configuré l’en-tête de réponse X-Frame-Options pour protéger les pages web contre le détournement de clic. X-Frame-Options empêche le rendu d’une page web dans un iFrame. Toutefois, il doit personnaliser la valeur d’en-tête en raison d’une nouvelle exigence métier qui impose d’afficher les données (dans iFrame) d’une application dont l’origine (domaine) est différente.
- Un administrateur a activé X-XSS-Protection pour assainir et bloquer la page si le navigateur détecte des attaques par scripts intersites. X-XSS-Protection empêche les attaques par scripts intersites. Toutefois, il doit personnaliser l’en-tête pour permettre à la page de se charger une fois assainie.
- Un administrateur doit activer le mécanisme CORS (Cross-Origin Resource Sharing) et définir l’origine (domaine) sur AD FS pour permettre à une application monopage d’accéder à une API web avec un autre domaine.
- Un administrateur a activé l’en-tête Stratégie de sécurité du contenu (CSP) pour empêcher les attaques par scripts intersites et injection de données en refusant les demandes interdomaines. Toutefois, il doit personnaliser l’en-tête en raison d’une nouvelle exigence métier pour permettre à la page web de charger des images provenant de n’importe quelle origine et limiter les médias aux fournisseurs approuvés.
En-têtes de réponse de sécurité HTTP
AD FS inclut les en-têtes de réponse dans la réponse HTTP sortante envoyée à un navigateur web. Vous pouvez répertorier les en-têtes à l’aide de la cmdlet Get-AdfsResponseHeaders
comme illustré dans la capture d’écran suivante.
L’attribut ResponseHeaders dans la capture d’écran identifie les en-têtes de sécurité inclus par AD FS dans chaque réponse HTTP. AD FS envoie les en-têtes de réponse uniquement si ResponseHeadersEnabled a la valeur True
(valeur par défaut). Il est possible de définir la valeur sur False
pour empêcher AD FS d’inclure les en-têtes de sécurité dans la réponse HTTP. Toutefois, ce paramètre n’est pas recommandé. Vous pouvez définir ResponseHeaders sur la valeur False
avec la commande suivante :
Set-AdfsResponseHeaders -EnableResponseHeaders $false
HTTP Strict-Transport-Security (HSTS)
La sécurité HSTS est un mécanisme de stratégie de sécurité web qui aide à atténuer les attaques par rétrogradation de protocole et le piratage de cookies pour les services qui ont des points de terminaison HTTP et HTTPS. Elle permet aux serveurs web de déclarer que les navigateurs web ou d’autres agents utilisateur conformes doivent interagir avec eux uniquement à l’aide de HTTPS et jamais par le biais du protocole HTTP.
Tous les points de terminaison AD FS pour le trafic d’authentification web sont ouverts exclusivement sur HTTPS. Ainsi, AD FS atténue efficacement les menaces fournies par le mécanisme de stratégie HSTS. Par défaut, il n’existe pas de rétrogradation vers le protocole HTTP, car celui-ci ne comporte pas d’écouteurs. Pour personnaliser l’en-tête, définissez les paramètres suivants :
- max-age=<expire-time>. Le délai d’expiration (en secondes) spécifie la durée pendant laquelle le site ne doit être accessible qu’à l’aide du protocole HTTPS. La valeur par défaut, qui est recommandée, est de 31 536 000 secondes (un an).
- includeSubDomains. Ce paramètre est facultatif. S’il est spécifié, la règle HSTS s’applique également à tous les sous-domaines.
Personnalisation de l’en-tête HSTS
Par défaut, l’en-tête est activé et max-age
est défini sur un an. Toutefois, les administrateurs peuvent modifier max-age
(il n’est pas recommandé de réduire la valeur max-age) ou activer le mécanisme HSTS pour les sous-domaines au moyen de la cmdlet Set-AdfsResponseHeaders.
Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=<seconds>; includeSubDomains"
Exemple :
Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=31536000; includeSubDomains"
Par défaut, l’en-tête est inclus dans l’attribut ResponseHeaders. Toutefois, les administrateurs peuvent supprimer l’en-tête au moyen de la cmdlet Set-AdfsResponseHeaders
.
Set-AdfsResponseHeaders -RemoveHeaders "Strict-Transport-Security"
X-Frame-Options
Par défaut, AD FS n’autorise pas les applications externes à utiliser des iFrame lors de l’exécution d’une connexion interactive. Cette configuration empêche certains types d’attaques par hameçonnage. La connexion non interactive peut être effectuée avec iFrame, car la sécurité au niveau de la session précédente a été établie.
Dans certains cas rares toutefois, vous pouvez faire confiance à une application spécifique qui exige une page de connexion AD FS interactive compatible avec iFrame. L’en-tête X-Frame-Options
est utilisé à cet effet.
Cet en-tête de réponse de sécurité HTTP permet d’indiquer au navigateur s’il peut afficher une page dans un <cadre> ou un <iFrame>. Il peut prendre les valeurs suivantes :
- deny. La page d’un cadre ne s’affiche pas. Cette configuration est le paramètre par défaut et recommandé.
- sameorigin. La page ne s’affiche dans le cadre que si elle présente la même origine que la page web. Cette option n’est utile que si tous les ancêtres proviennent également de la même origine.
- allow-from <origine spécifiée>. La page ne s’affiche dans le cadre que si l’origine (par exemple,
https://www.".com
) correspond à l’origine spécifique dans l’en-tête. Certains navigateurs peuvent ne pas prendre en charge cette option.
Personnalisation de l’en-tête X-Frame-Options
Par défaut, l’en-tête est défini sur deny. Toutefois, les administrateurs peuvent modifier sa valeur au moyen de la cmdlet Set-AdfsResponseHeaders
.
Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "<deny/sameorigin/allow-from<specified origin>>"
Exemple :
Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "allow-from https://www.example.com"
Par défaut, l’en-tête est inclus dans l’attribut ResponseHeaders. Toutefois, les administrateurs peuvent supprimer l’en-tête au moyen de la cmdlet Set-AdfsResponseHeaders
.
Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"
X-XSS-Protection
Cet en-tête de réponse de sécurité HTTP permet d’arrêter le chargement des pages web quand des navigateurs détectent des attaques par scripts intersites (XSS). Cette approche est appelée « filtrage XSS ». Il peut prendre les valeurs suivantes :
- La valeur 0 désactive le filtrage XSS. Non recommandé.
- La valeur 1 active le filtrage XSS. Si une attaque XSS est détectée, le navigateur assainit la page.
- La valeur 1; mode=block active le filtrage XSS. Si une attaque XSS est détectée, le navigateur empêche le rendu de la page. Ce paramètre est la valeur par défaut et recommandée.
Personnalisation de l’en-tête X-XSS-Protection
Par défaut, l’en-tête est défini sur 1; mode=block;. Toutefois, les administrateurs peuvent modifier la valeur au moyen de la cmdlet Set-AdfsResponseHeaders
.
Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "<0/1/1; mode=block/1; report=<reporting-uri>>"
Exemple :
Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "1"
Par défaut, l’en-tête est inclus dans l’attribut ResponseHeaders. Toutefois, les administrateurs peuvent supprimer l’en-tête au moyen de la cmdlet Set-AdfsResponseHeaders
.
Set-AdfsResponseHeaders -RemoveHeaders "X-XSS-Protection"
En-têtes CORS (Cross-Origin Resource Sharing)
La sécurité du navigateur web empêche une page web de lancer des demandes interorigines à partir de scripts. Toutefois, il peut arriver que vous souhaitiez accéder à des ressources provenant d’autres origines (domaines). CORS (Cross Origin Resource Sharing, partage des ressources multi-origines) est une norme W3C qui permet à un serveur d’assouplir la stratégie de même origine. Grâce au mécanisme CORS, un serveur peut autoriser explicitement certaines demandes multi-origines tout en en refusant d’autres.
Pour mieux comprendre la demande CORS, le scénario suivant présente un exemple dans lequel une application monopage (SPA) doit appeler une API web avec un autre domaine. En outre, considérez que l’application SPA et l’API sont configurées sur AD FS 2019 et que CORS est activé pour AD FS. AD FS peut identifier les en-têtes CORS dans la requête HTTP, valider les valeurs d’en-tête et inclure les en-têtes CORS appropriés dans la réponse. Pour plus d’informations sur l’activation et la configuration de CORS sur AD FS 2019, consultez la section Personnalisation de l’en-tête CORS. L’exemple de flux suivant vous guide tout au long du scénario :
Un utilisateur accède à l’application monopage par le biais du navigateur client et est redirigé vers le point de terminaison d’authentification AD FS pour l’authentification. Étant donné que l’application monopage est configurée pour le flux d’octroi implicite, la demande retourne un jeton d’accès et d’ID au navigateur une fois l’authentification réussie.
Après l’authentification de l’utilisateur, le JavaScript frontend inclus dans l’application monopage effectue une demande d’accès à l’API web. La demande est redirigée vers AD FS avec les en-têtes suivants :
- Options : décrit les options de communication de la ressource cible.
- Origin : inclut l’origine de l’API web.
- Access-Control-Request-Method : identifie la méthode HTTP (par exemple, DELETE) à utiliser lors d’une demande réelle.
- Access-Control-Request-Headers : identifie les en-têtes HTTP à utiliser lors d’une demande réelle.
Notes
Une requête CORS ressemble à une requête HTTP standard. Toutefois, la présence d’un en-tête Origin indique que la demande entrante est liée au mécanisme CORS.
AD FS vérifie que l’origine de l’API web incluse dans l’en-tête figure parmi les origines approuvées configurées dans AD FS. Pour plus d’informations sur la modification des origines approuvées, consultez la section Personnalisation de l’en-tête CORS. AD FS répond ensuite avec les en-têtes suivants :
- Access-Control-Allow-Origin : valeur identique à celle de l’en-tête Origin.
- Access-Control-Allow-Method : valeur identique à celle de l’en-tête Access-Control-Request-Method.
- Access-Control-Allow-Headers : valeur identique à celle de l’en-tête Access-Control-Request-Headers.
Le navigateur envoie la demande réelle avec les en-têtes suivants :
- Méthode HTTP (par exemple, DELETE).
- Origin : inclut l’origine de l’API web.
- Tous les en-têtes inclus dans l’en-tête de réponse Access-Control-Allow-Headers.
Une fois la demande vérifiée, AD FS l’approuve en incluant le domaine d’API web (origine) dans l’en-tête de réponse Access-Control-Allow-Origin.
L’en-tête Access-Control-Allow-Origin permet au navigateur d’appeler l’API demandée.
Personnalisation de l’en-tête CORS
Par défaut, la fonctionnalité CORS n’est pas activée. Toutefois, les administrateurs peuvent l’activer au moyen de la cmdlet Set-AdfsResponseHeaders
.
Set-AdfsResponseHeaders -EnableCORS $true
Une fois cette fonctionnalité activée, les administrateurs peuvent énumérer une liste d’origines approuvées à l’aide de la même cmdlet. Par exemple, la commande suivante autorise les demandes CORS provenant des origines https://example1.com
et https://example1.com
.
Set-AdfsResponseHeaders -CORSTrustedOrigins https://example1.com,https://example2.com
Remarque
Les administrateurs peuvent autoriser les demandes CORS provenant de n’importe quelle origine en incluant « * » dans la liste des origines approuvées. Néanmoins, cette approche n’est pas recommandée en raison de failles de sécurité. Un message d’avertissement est fourni s’ils le souhaitent.
Stratégie de sécurité du contenu
Cet en-tête de réponse de sécurité HTTP permet de prévenir les attaques par scripts intersites, par détournement de clic et par injection de données en empêchant les navigateurs d’exécuter par inadvertance du contenu malveillant. Les navigateurs qui ne prennent pas en charge la stratégie de sécurité du contenu (CSP) ignorent les en-têtes de réponse CSP.
Personnalisation de l’en-tête CSP
La personnalisation de l’en-tête CSP implique de modifier la stratégie de sécurité définissant les ressources que le navigateur est autorisé à charger pour la page web. La stratégie de sécurité par défaut est la suivante :
Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:;
La directive default-src permet de modifier les directives -src sans énumérer explicitement chacune d’elles. Dans l’exemple ci-dessous, la stratégie 1 est identique à la stratégie 2.
Stratégie 1
Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'"
Stratégie 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';"
Si une directive est explicitement répertoriée, la valeur spécifiée remplace la valeur donnée pour default-src. Dans l’exemple ci-dessous, img-src prend la valeur « * » (autorise le chargement des images provenant de n’importe quelle origine), tandis que les autres directives -src ont la valeur « self » (limite le chargement des images à la même origine que la page web).
Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'; img-src *"
Les sources qui peuvent être définies pour la stratégie default-src sont les suivantes :
- « self » : la spécification de cette source limite l’origine du contenu à charger à celle de la page web.
- « unsafe-inline » : la spécification de cette source dans la stratégie autorise l’utilisation du code JavaScript et CSS inline.
- « unsafe-eval » : la spécification de cette source dans la stratégie autorise l’utilisation de texte pour les mécanismes JavaScript tels que eval.
- « none » : la spécification de cette source limite le chargement de contenu provenant de n’importe quelle origine.
- « data » : la spécification d’URI de données permet aux créateurs de contenu d’incorporer de petits fichiers inline dans des documents. Non recommandé.
Remarque
AD FS utilise JavaScript dans le processus d’authentification. Il l’active donc en incluant les sources « unsafe-inline » et « unsafe-eval » dans la stratégie par défaut.
En-têtes personnalisés
Outre les en-têtes de réponse de sécurité répertoriés ci-dessus (HSTS, CSP, X-Frame-Options, X-XSS-Protection et CORS), AD FS 2019 vous permet de définir de nouveaux en-têtes.
Par exemple, vous pouvez définir un nouvel en-tête « TestHeader » avec la valeur « TestHeaderValue ».
Set-AdfsResponseHeaders -SetHeaderName "TestHeader" -SetHeaderValue "TestHeaderValue"
Une fois qu’il est défini, le nouvel en-tête est envoyé dans la réponse AD FS, comme illustré dans l’extrait de code Fiddler suivant :
Compatibilité des navigateurs web
Appuyez-vous sur le tableau et les liens suivants pour déterminer quels navigateurs web sont compatibles avec chacun des en-têtes de réponse de sécurité.
En-têtes de réponse de sécurité HTTP | Compatibilité des navigateurs |
---|---|
HTTP Strict-Transport-Security (HSTS) | Compatibilité des navigateurs avec l’en-tête HSTS |
X-Frame-Options | Compatibilité des navigateurs avec l’en-tête X-Frame-Options |
X-XSS-Protection | Compatibilité des navigateurs avec l’en-tête X-XSS-Protection |
Partage des ressources cross-origin (CORS) | Compatibilité des navigateurs avec l’en-tête CORS |
Stratégie de sécurité du contenu | Compatibilité des navigateurs avec l’en-tête CSP |