6. Considérations sur la sécurité
Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des problèmes de sécurité connus propres à l'authentification HTTP. Les considérations de sécurité plus générales sont traitées dans la messagerie HTTP [RFC7230] et la sémantique HTTP [RFC7231].
Tout ce qui touche à l'authentification HTTP relève des considérations de sécurité, de sorte que la liste ci-dessous n'est pas exhaustive. En outre, elle se limite aux considérations de sécurité concernant le cadre d'authentification en général, plutôt que de discuter de toutes les considérations potentielles pour des schémas d'authentification particuliers (qui devraient être documentées dans les spécifications définissant ces schémas). Diverses organisations maintiennent des informations thématiques et des liens vers la recherche actuelle sur la sécurité des applications Web (par exemple [OWASP]), y compris les pièges courants liés à la mise en œuvre et à l'utilisation des schémas d'authentification rencontrés en pratique.
6.1 Confidentialité des informations d'authentification
Le cadre d'authentification HTTP ne définit pas de mécanisme unique pour préserver la confidentialité des informations d'authentification ; à la place, chaque schéma d'authentification définit la manière dont les informations d'authentification sont encodées avant transmission. Si cela offre une flexibilité pour le développement de futurs schémas d'authentification, c'est insuffisant pour la protection des schémas existants qui n'assurent par eux-mêmes aucune confidentialité, ou qui ne protègent pas suffisamment contre les attaques par rejeu. En outre, si le serveur attend des informations d'authentification propres à chaque utilisateur, l'échange de ces informations aura pour effet d'identifier cet utilisateur, même si le contenu des informations d'authentification reste confidentiel.
HTTP dépend des propriétés de sécurité de la connexion sous-jacente au niveau du transport ou de la session pour assurer une transmission confidentielle des champs d'en-tête. Autrement dit, si un serveur limite l'accès aux utilisateurs authentifiés à l'aide de ce cadre, il doit veiller à ce que la connexion soit correctement sécurisée conformément à la nature du schéma d'authentification utilisé. Par exemple, les services qui dépendent de l'authentification individuelle des utilisateurs exigent souvent que la connexion soit sécurisée par TLS ("Transport Layer Security", [RFC5246]) avant tout échange d'informations d'authentification.
6.2 Informations d'authentification et clients inactifs
Les clients HTTP et les agents utilisateurs existants conservent généralement les informations d'authentification indéfiniment. HTTP ne fournit pas de mécanisme permettant au serveur d'origine de demander aux clients de supprimer ces informations d'authentification mises en cache, car le protocole n'a aucune connaissance de la manière dont les informations d'authentification sont obtenues ou gérées par l'agent utilisateur. Les mécanismes d'expiration ou de révocation des informations d'authentification peuvent être spécifiés dans le cadre de la définition d'un schéma d'authentification.
Les circonstances dans lesquelles la mise en cache des informations d'authentification peut interférer avec le modèle de sécurité de l'application comprennent, sans s'y limiter :
-
Les clients qui sont restés inactifs pendant une période prolongée, après laquelle le serveur peut souhaiter que le client demande à nouveau à l'utilisateur de saisir ses informations d'authentification.
-
Les applications qui comportent une indication de fin de session (comme un bouton "logout" ou "commit" sur une page), après laquelle le côté serveur de l'application "sait" qu'il n'y a plus de raison pour le client de conserver les informations d'authentification.
Les agents utilisateurs qui mettent en cache les informations d'authentification sont encouragés à fournir un mécanisme facilement accessible permettant de supprimer les informations d'authentification mises en cache sous le contrôle de l'utilisateur.
6.3 Espaces de protection
Les schémas d'authentification qui s'appuient uniquement sur le mécanisme "realm" pour établir un espace de protection exposent les informations d'authentification à toutes les ressources d'un serveur d'origine. Les clients qui ont effectué avec succès des requêtes authentifiées auprès d'une ressource peuvent utiliser les mêmes informations d'authentification pour d'autres ressources du même serveur d'origine. Cela permet à une ressource différente de collecter les informations d'authentification destinées à d'autres ressources.
Cela est particulièrement préoccupant lorsqu'un serveur d'origine héberge les ressources de plusieurs parties sous la même URI racine canonique (section 2.2). Les stratégies d'atténuation possibles consistent notamment à restreindre l'accès direct aux informations d'authentification (c'est-à-dire à ne pas rendre disponible le contenu du champ d'en-tête de requête Authorization) et à séparer les espaces de protection en utilisant un nom d'hôte (ou un numéro de port) différent pour chaque partie.