Violation de gestion d'authentification et de session

1. Principe

Cette faille de sécurité regroupe toutes les vulnérabilités pouvant mener à une usurpation d'identité. Ces points de faiblesse dans les applications Web peuvent ouvrir à des attaquants des accès à des fonctionnalités des applications Web auxquelles ils n'ont pas le droit normalement. Cela peut donc leur permettre de voler des informations ou d'endommager le bon fonctionnement de l'application. La protection des accès à l'application repose généralement sur un système d'authentification. La plupart du temps, le système d'authentification est redéveloppé pour chaque application, ce qui implique que ces systèmes ne bénéficient pas de l'expérience acquise sur le développement d'autres applications.

Pour comprendre comment les attaques peuvent être menées, il faut comprendre le mécanisme d'authentification le plus commun des applications Web :

1. L'utilisateur non authentifié demande l'accès à une page Web ;
2. Le serveur renvoie une page d'authentification ;
3. L'utilisateur remplit le formulaire en fournissant un identifiant et un mot de passe et revoie ces informations au serveur Web ;
4. Le serveur Web fait appel à un service pour vérifier la validité du couple identifiant/mot de passe ;
5. Si la validité est avérée, le serveur Web fournit un identifiant de session à l'utilisateur. Comme expliqué précédemment HTTP est un protocole déconnecté, donc entre deux requêtes HTTP la connexion entre le navigateur et le serveur HTTP est coupée. Donc le serveur HTTP ne peut pas reconnaître un utilisateur qui s'est déjà authentifié et qui a ouvert une session de travail dans l'application Web. Pour remédier à cela, la plupart des systèmes d'authentification reposent sur un identifiant de session. Celui-ci est envoyé à chaque page entre le client et le serveur par le biais d'un cookie, d'un paramètre d'adresse ou d'un champ de formulaire invisible pour l'utilisateur ;
6. L'utilisateur peut utiliser l'application Web tant que la session est ouverte.

Les attaques pour usurper une identité peuvent être regroupées en deux catégories :

• les attaques contre le système d'authentification qui cherchent à obtenir un droit d'accès ;
• les usurpations de session qui permettent de s'affranchir de l'étape d'authentification.

2. Exemples d'attaque

Parmi les attaques contre les systèmes d'authentification, la plus répandue est l'utilisation de la force brute. Pour cela l'attaquant va bombarder la page d'authentification avec des valeurs d'identifiant et de mots de passe jusqu'à ce qu'il se fasse accepter [7]. L'attaque est facilitée si le message d'erreur de l'échec de l'authentification donne l'origine de l'erreur. Ainsi « l'utilisateur n'existe pas » permet à l'attaquant de ne pas tenter d'entrer des mots de passe pour cet utilisateur absent de la base de compte. « Mot de passe incorrect » permet à l'attaquant de se concentrer sur cet utilisateur, ce qui lui fait gagner beaucoup de temps. De même si l'application Web offre un service pour créer un compte par lui-même et qu'au moment de la saisie de l'identifiant ce système indique si le compte existe déjà ou non, l'attaquant dispose d'un moyen pour trouver des comptes attaquables. L'impact de ce type d'attaque n'est pas seulement limité à une usurpation d'identité pour l'application Web. Un internaute utilise souvent les mêmes valeurs d'identifiant et de mot de passe pour de nombreuses applications présentes sur le Web. L'attaquant peut donc tenter d'utiliser ces valeurs sur différentes applications Web.

Il est possible pour l'attaquant de chercher des couples identifiant/mot de passe sans faire appel à la force brute. L'attaquant va simplement tenter d'utiliser des comptes généralement présents dans les applications Web, comme ceux d'administration. Ceci est surtout possible lorsque les applications sont basées sur des outils Open Source qui ont des comptes créés automatiquement avec des mots de passe par défaut connus du domaine public. L'attaquant n'a plus qu'à consulter le code source pour trouver une liste restreinte d'identifiants/mots de passe valides.

Les pages Web qui permettent de réinitialiser les mots de passe sont une faille importante pour l'usurpation d'identité. En effet, pour s'assurer de l'identité du demandeur, la plupart d'entre elles demandent une information que seule la personne est censée connaître. Or avec les réseaux sociaux, les internautes partagent leur vie privée. Ces informations personnelles visibles de tous peuvent être les mêmes que celles demandées dans les pages de réinitialisation de mot de passe. Dans ce cas l'attaquant peut définir un nouveau mot de passe qu'il pourra utiliser pour se connecter à l'application.

Pour voler un identifiant de session, l'attaque par la force brute est également possible. Dans ce cas l'attaquant va générer des valeurs et tenter de les utiliser comme identifiant de session. S'il réussit à trouver une valeur valide, il pourra utiliser l'application Web sans s'être authentifié. Par ailleurs, une attaque XSS peut permettre de récupérer un identifiant de session présent dans le cookie de l'internaute. L'identifiant de session peut également être découvert par un attaquant en écoutant la transmission de données sur le réseau, en consultant les fichiers de journalisation sur le serveur par injection de commandes systèmes par exemple.

Une autre technique consiste à fournir un identifiant de session à la victime, par hameçonnage par exemple. L'utilisateur se connecte à l'application Web et s'authentifie. La session est créée en utilisant l'identifiant fourni. L'attaquant peut alors accéder au site en fournissant l'identifiant fixé. L'identifiant peut être généré ou obtenu en émettant une requête vers l'application cible de l'attaque si l'application retourne un identifiant de session pour toute requête avant même l'authentification de l'utilisateur.

Si l'identifiant de session n'est pas généré aléatoirement mais est un nombre incrémenté à chaque ouverture de session, par exemple, l'attaquant peut arriver à deviner un identifiant valide.

3. Parade et bonnes pratiques

Concernant les systèmes d'authentification, l'application ne doit accepter que des mots de passe suffisamment forts pour éviter d'être devinés rapidement par la force brute. Une longueur minimale de huit caractères est ce qui recommandé par l'OWASP pour les applications critiques. De plus il doit comporter au moins un chiffre, une lettre en minuscule et une lettre en majuscule.

Le message affiché lors d'un problème de validité de l'identifiant ou du mot de passe doit être générique et ne doit pas donner d'indice quant à l'origine de l'erreur.

Pour contrer les attaques de force brute, le compte ciblé par l'attaque doit être verrouillé après cinq tentatives consécutives infructueuses de connexion. La procédure de déverrouillage peut être automatique après un laps de temps prédéfini ou manuelle par un administrateur de l'application.

Dans la mesure du possible il est conseillé de ne pas développer son propre mécanisme d'authentification. Il est préférable d'utiliser un système existant éprouvé.

Concernant les identifiants de session, les applications Web doivent limiter la durée de vie d'une session. Une période d'inactivité maximale doit être définie. Si l'utilisateur n'utilise pas l'application pendant ce laps de temps, la session devient inutilisable et l'utilisateur doit se reconnecter. Une session doit également avoir une durée de vie maximale au-delà de laquelle la session expire, même si la période d'inactivité autorisée n'était pas dépassée. Ces précautions permettent de limiter le temps d'action d'un attaquant.

Du côté client, du code JavaScript doit fermer la session lorsque l'utilisateur ferme le navigateur. Cela permet de simuler une action de l'utilisateur pour se déconnecter de l'application. Pour que l'utilisateur évite de perdre des saisies non sauvegardées, du code JavaScript peut prévenir l'utilisateur que sa session va bientôt expirer.

L'identifiant de session doit être généré automatiquement et être suffisamment long pour se prémunir des vols par prédiction.

Pour détecter des attaques de force brute, il faut régulièrement consulter les journaux d'activité à la recherche d'événements inhabituels, comme un nombre important de requêtes utilisant des identifiants de sessions invalides.