4. Considérations de sécurité

Les applications qui créent de nouveaux URI bien connus, ainsi que les administrateurs qui les déploient, devront examiner plusieurs questions liées à la sécurité, notamment (sans s’y limiter) l’exposition de données sensibles, les attaques par déni de service (en plus des problèmes de charge habituels), l’authentification des serveurs et des clients, la vulnérabilité aux attaques par rebinding DNS, et les attaques où un accès limité à un serveur permet d’influencer la façon dont les URI bien connus sont servis.

[RFC3552] contient des exemples de considérations de sécurité potentiellement pertinentes pour les protocoles d’application et les administrateurs qui les déploient.

4.1. Protéger les ressources bien connues

Comme les emplacements bien connus représentent en pratique l’origine entière, les opérateurs de serveurs devraient contrôler de façon appropriée la possibilité d’y écrire. Cela vaut surtout lorsque plusieurs entités sont hébergées sur la même origine. Même pour des origines contrôlées par une seule entité, il convient de veiller à ce que l’accès en écriture aux emplacements bien connus ne soit pas accordé par inadvertance, que ce soit via la configuration du serveur ou via les droits d’implémentation (par ex. sur un système de fichiers).

4.2. Interaction avec la navigation Web

Les applications qui utilisent des URI bien connus dans des URL http ou https doivent savoir que les ressources bien connues seront accessibles aux navigateurs Web et donc manipulables par du contenu provenant d’autres parties de cette origine. Si un attaquant peut injecter du contenu (par ex. via une vulnérabilité de type Cross-Site Scripting), il pourra émettre des requêtes potentiellement arbitraires vers la ressource bien connue.

HTTP et HTTPS utilisent aussi les origines comme frontière de sécurité pour de nombreux autres mécanismes, notamment (sans s’y limiter) les cookies [RFC6265], Web Storage [WEBSTORAGE] et diverses capacités.

Une application qui définit des emplacements bien connus ne doit pas supposer qu’elle a l’usage exclusif de ces mécanismes ni qu’elle est la seule application sur l’origine. Selon la nature de l’application, des mesures d’atténuation peuvent inclure :

Chiffrer les informations sensibles
Permettre de la souplesse dans l’usage des identifiants (par ex. noms de cookies) pour éviter les collisions avec d’autres applications
Utiliser l’attribut HttpOnly sur les cookies afin qu’ils ne soient pas exposés aux langages de script du navigateur [RFC6265]
Utiliser le paramètre Path sur les cookies pour qu’ils ne soient pas disponibles pour d’autres parties de l’origine [RFC6265]
Utiliser X-Content-Type-Options: nosniff [FETCH] pour qu’un contenu sous contrôle de l’attaquant ne puisse pas être amené sous une forme interprétée comme contenu actif par un navigateur Web

D’autres bonnes pratiques :

Utiliser un type de média propre à l’application dans le champ d’en-tête Content-Type et exiger que les clients échouent s’il n’est pas utilisé
Utiliser Content-Security-Policy [CSP] pour limiter les capacités du contenu actif (tel que HTML [HTML5]), atténuant ainsi les attaques Cross-Site Scripting
Utiliser Referrer-Policy [REFERRER-POLICY] pour empêcher la fuite de données sensibles dans les URL via le champ d’en-tête de requête Referer
Éviter la compression sur toute information sensible (jetons d’authentification, mots de passe, etc.), car l’environnement de script des navigateurs Web permet à un attaquant de sonder à répétition l’espace de compression ; s’il a accès au chemin de la communication, il peut exploiter cette capacité pour récupérer ces informations.

4.3. Délimiter les applications

Le présent mémo ne précise ni la portée d’application des informations obtenues à partir d’un URI bien connu, ni la manière de découvrir l’URI bien connu d’une application donnée.

Chaque application qui utilise ce mécanisme doit définir ces deux aspects ; à défaut, des problèmes de sécurité peuvent survenir à cause d’écarts d’implémentation et de confusion sur les frontières entre applications.

Appliquer les métadonnées découvertes dans un URI bien connu à des ressources autres que celles co-localisées sur la même origine comporte des risques administratifs et de sécurité. Par exemple, permettre que https://example.com/.well-known/example applique une politique à https://department.example.com, https://www.example.com, ou même https://www.example.com:8000 suppose une relation entre hôtes qui peut ne pas exister, donnant ainsi le contrôle à un attaquant potentiel.

De même, spécifier qu’un URI bien connu sur un nom d’hôte particulier sert à amorcer un protocole peut provoquer un grand nombre de requêtes indésirables. Par exemple, si un URI HTTPS bien connu sert à trouver une politique concernant un service distinct tel que le courrier électronique, cela peut entraîner un flot de requêtes vers des serveurs Web, même s’ils n’implémentent pas l’URI bien connu. De telles requêtes indésirables peuvent ressembler à une attaque par déni de service.

4.4. Capacités occultes

Les applications qui utilisent des emplacements bien connus devraient tenir compte du fait que certains administrateurs de serveurs peuvent ignorer leur existence (notamment sur les systèmes d’exploitation qui masquent les répertoires dont le nom commence par .). Cela signifie que si un attaquant a un accès en écriture au répertoire .well-known, il pourrait en contrôler le contenu sans que l’administrateur s’en rende compte.