Faiblesses des authentifications HTTP
Date : 07 Avril 2010
Parmi les techniques de gestion de sessions avec le protocole HTTP il s'avère que la gestion de sessions via des cookies est davantage utilisée.
Si le peu de garantie de sécurité de l'authentification "HTTP Basic" explique son faible taux d'utilisation, l'explication est moins évidente pour l'authentification "HTTP Digest".
Il est possible que les développeurs d'applications et les administrateurs hésitent à utiliser cette méthode davantage à cause d'un manque de flexibilité des interfaces utilisateur correspondantes plutôt qu'à cause d'une faiblesse dans la sécurité du protocole.
Authentifications basées sur un formulaire applicatif
Au fil des ans, les développeurs web ont publié diverses méthodes qui tentent de fournir des formulaires HTML personnalisables permettant d'utiliser les authentifications HTTP Basic et HTTP Digest.
Une approche intéressante est l'utilisation des fonctionnalités AJAX pour prendre le contrôle du processus d'authentification.
Les identifiants sont saisis via une page HTML, puis utilisés via la méthode open d'un objet de la classe XMLHttpRequest.
Si la connexion réussit, la demande AJAX reçoit en retour un code HTTP 200 et le navigateur affiche une page d'accueil.
Si la connexion échoue, le script affiche un message d'erreur personnalisé.
Cette approche n'est malheureusement pas tout à fait opérationnelle sans un petit ajustement.
En effet, lorsqu'ils reçoivent un code d'erreur 401 (échec d'authentification) depuis le serveur, même en réponse à une requête AJAX, la plupart des navigateurs affichent leur propre formulaire de saisie d'identifiants. Ce comportement a pour conséquence que le processus d'authentification échappe à l'application web suite à une erreur de l'utilisateur lors de sa première tentative d'authentification.
Pour contourner ce problème, les développeurs de sites pourraient personnaliser le script " /private/login-check.cgi " afin qu'il renvoie un autre code d'erreur qui serait ignoré par le navigateur et pourrait permettre la poursuite du traitement en JavaScript.
Ce contournement de la spécification HTTP peut sembler lourd et artificiel, mais le W3C travaille sur un projet de normalisation de la classe d'objet XMLHttpRequest qui améliorerait cet aspect relatif à un échec d'authentification.
Amélioration du processus de déconnexion
L'absence d'application exécutée lors de la déconnexion semble être une limitation plus importante de l'utilisation des authentifications HTTP avec les navigateurs.
Un certain nombre d'applications JavaScript spécifiques aux différents navigateurs ont été développées afin de prendre en charge cet aspect mais ces approches sont hétérogènes. Il serait intéressant d'ajouter dans le protocole HTTP un code d'erreur ou un champ permettant un traitement des déconnexions.
Manque de maturité des implémentations
Bien que le manque de flexibilité des connexions et déconnexions soit un obstacle majeur pour l'adoption de l'authentification "HTTP Digest", il faut également noter un certain manque de maturité de plusieurs éditeurs de navigateurs et serveurs web qui proposent effectivement une implémentation incomplète de ce protocole d'authentification.
Faible niveau de sécurité des interfaces utilisateurs pour les authentifications HTTP
Les interfaces utilisateurs des principaux navigateurs web présentent en effet plusieurs faiblesses de sécurité. En effet certains navigateurs
Conclusion
Le protocole HTTP étant un protocole non connecté (ou " sans état " pour " stateless protocol ") les solutions utilisées pour gérer des sessions via HTTP reposent sur des méthodes venues s'ajouter à la spécification initiale du protocole.
Parmi les différentes méthodes, la plus utilisée est celle utilisant les cookies.
Les méthodes d'authentification HTTP utilisées conjointement avec le protocole SSL offrent cependant un niveau de sécurité correct qui pourrait être amélioré selon quelques aménagements du protocole HTTP (gestion des déconnexions) et des navigateurs web (plus grande flexibilité et meilleur niveau de sécurité des IHM utilisées lors des phases d'authentification).
Pour en savoir plus :
Si le peu de garantie de sécurité de l'authentification "HTTP Basic" explique son faible taux d'utilisation, l'explication est moins évidente pour l'authentification "HTTP Digest".
Il est possible que les développeurs d'applications et les administrateurs hésitent à utiliser cette méthode davantage à cause d'un manque de flexibilité des interfaces utilisateur correspondantes plutôt qu'à cause d'une faiblesse dans la sécurité du protocole.
Authentifications basées sur un formulaire applicatif
Au fil des ans, les développeurs web ont publié diverses méthodes qui tentent de fournir des formulaires HTML personnalisables permettant d'utiliser les authentifications HTTP Basic et HTTP Digest.
Une approche intéressante est l'utilisation des fonctionnalités AJAX pour prendre le contrôle du processus d'authentification.
Les identifiants sont saisis via une page HTML, puis utilisés via la méthode open d'un objet de la classe XMLHttpRequest.
Si la connexion réussit, la demande AJAX reçoit en retour un code HTTP 200 et le navigateur affiche une page d'accueil.
Si la connexion échoue, le script affiche un message d'erreur personnalisé.
Cette approche n'est malheureusement pas tout à fait opérationnelle sans un petit ajustement.
En effet, lorsqu'ils reçoivent un code d'erreur 401 (échec d'authentification) depuis le serveur, même en réponse à une requête AJAX, la plupart des navigateurs affichent leur propre formulaire de saisie d'identifiants. Ce comportement a pour conséquence que le processus d'authentification échappe à l'application web suite à une erreur de l'utilisateur lors de sa première tentative d'authentification.
Pour contourner ce problème, les développeurs de sites pourraient personnaliser le script " /private/login-check.cgi " afin qu'il renvoie un autre code d'erreur qui serait ignoré par le navigateur et pourrait permettre la poursuite du traitement en JavaScript.
Ce contournement de la spécification HTTP peut sembler lourd et artificiel, mais le W3C travaille sur un projet de normalisation de la classe d'objet XMLHttpRequest qui améliorerait cet aspect relatif à un échec d'authentification.
Amélioration du processus de déconnexion
L'absence d'application exécutée lors de la déconnexion semble être une limitation plus importante de l'utilisation des authentifications HTTP avec les navigateurs.
Un certain nombre d'applications JavaScript spécifiques aux différents navigateurs ont été développées afin de prendre en charge cet aspect mais ces approches sont hétérogènes. Il serait intéressant d'ajouter dans le protocole HTTP un code d'erreur ou un champ permettant un traitement des déconnexions.
Manque de maturité des implémentations
Bien que le manque de flexibilité des connexions et déconnexions soit un obstacle majeur pour l'adoption de l'authentification "HTTP Digest", il faut également noter un certain manque de maturité de plusieurs éditeurs de navigateurs et serveurs web qui proposent effectivement une implémentation incomplète de ce protocole d'authentification.
Faible niveau de sécurité des interfaces utilisateurs pour les authentifications HTTP
Les interfaces utilisateurs des principaux navigateurs web présentent en effet plusieurs faiblesses de sécurité. En effet certains navigateurs
- ne précisent pas le type d'authentifications qu'ils utilisent (" Basic " ou " Digest ") ce qui permet de leurrer les utilisateurs quant au niveau de sécurité de leurs sessions HTTP,
- utilisent un gestionnaire de mots de passe qui ne fait pas la différence entre les différents types d'authentifications et utilise des identifiants mis en cache lors d'une authentification d'un certain type pour une authentification d'un autre type,
- ne différencient pas clairement le nom de domaine et le paramètre " realm " utilisé par l'authentification HTTP.
Conclusion
Le protocole HTTP étant un protocole non connecté (ou " sans état " pour " stateless protocol ") les solutions utilisées pour gérer des sessions via HTTP reposent sur des méthodes venues s'ajouter à la spécification initiale du protocole.
Parmi les différentes méthodes, la plus utilisée est celle utilisant les cookies.
Les méthodes d'authentification HTTP utilisées conjointement avec le protocole SSL offrent cependant un niveau de sécurité correct qui pourrait être amélioré selon quelques aménagements du protocole HTTP (gestion des déconnexions) et des navigateurs web (plus grande flexibilité et meilleur niveau de sécurité des IHM utilisées lors des phases d'authentification).
Pour en savoir plus :
- Etude de "Virtuals Security Research" : http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
- RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1) : http://www.ietf.org/rfc/rfc2616.txt
- RFC2617 (HTTP Authentication: Basic and Digest Access Authentication) : http://www.ietf.org/rfc/rfc2617.txt
- RFC2965 (HTTP State Management Mechanism) : http://www.ietf.org/rfc/rfc2965.txt
