Le champ d'application de ce test est de vérifier s'il est possible de recueillir un ensemble de noms d'utilisateurs valides en interagissant avec le mécanisme d'authentification de l'application. Ce test sera utile pour tester le « brute force », dans lequel on vérifie si, étant donné un mot de passe valide, il est possible de trouver le mot de passe correspondant. Souvent, les applications Web révélent quand un nom d'utilisateur existe sur le système, que ce soit à la suite d'une mauvaise configuration ou d'une décision de conception. Par exemple, parfois, lorsque nous soumettons des références erronées, nous recevons un message indiquant que soit le nom d'utilisateur est présent sur le système soit le mot de passe fourni est incorrect. Les informations obtenues peuvent être utilisées par un attaquant afin d'obtenir une liste d'utilisateurs sur le système. Cette information peut être utilisée pour attaquer l'application web, par exemple, par « brute force » ou d'attaque par nom d'utilisateur / mot de passe par défaut.

Le testeur doit interagir avec le mécanisme d'authentification de l'application pour déterminer si l'envoi de demandes particulières fait que l'application réponde de différentes manières. Ce problème existe parce que l'information retournée par l'application Web ou lu serveur Web lorsque nous fournissons un nom d'utilisateur valide est différente de celle retournée lorsque nous utilisons un non valide.

Dans certains cas, nous recevons un message qui révèle si les informations d'identification fournies sont fausses, car un nom d'utilisateur incorrect ou un mot de passe non valide a été utilisé. Parfois, nous pouvons énumérer les utilisateurs existants par l'envoi d'un nom d'utilisateur et un mot de passe vide.

Dans un test boîte noire, nous ne savons rien à propos de l'application spécifique, les noms d'utilisateurs, la logique d'application, les messages d'erreur sur la page de connexion, ou la procédure de récupération de mot de passe. Si l'application est vulnérable, nous recevons un message de réponse qui révèle, directement ou indirectement, des informations utiles pour le dénombrement des utilisateurs.

Notez la réponse du serveur lorsque vous soumettez un nom d'utilisateur valide et mot de passe valide.

Résultat attendu:

Avec WebScarab, notez les informations extraites de cette authentification réussie ( Réponse HTTP 200, longueur de la réponse).

Maintenant, le testeur doit essayer d'insérer un nom d'utilisateur valide et un mot de passe erroné et enregistrer le message d'erreur généré par l'application.

Résultat attendu:

Dans le navigateur, nous attendons un message similaire à celui ci-dessous:

Authentication failed.
Return to Login page

ou quelque chose comme:

No configuration found
Contact your system administrator
Return to login page

mais aucun message qui révèle l'existence d'utilisateur, par exemple, un message similaire à:

Login for User foo: invalid password

Avec WebScarab, notez les informations extraites de cette tentative d'authentification échouée ( Réponse HTTP 200, longueur de la réponse).

Maintenant, le testeur doit essayer un code utilisateur invalide et un mot de passe erroné et enregistrer la réponse du serveur (vous devez être sûr que le nom d'utilisateur n'est pas valide dans l'application). Notez le message d'erreur et la réponse du serveur.

Résultat attendu:

Si nous entrons un nom d'utilisateur inexistant, nous pouvons recevoir un message similaire à:

The user is not active
Contact your system administrator
Return to login page

ou un message comme celui ci-dessous:

Login failed for User foo: invalid Account

En général, la demande doit répondre avec le même message d'erreur et la longueur des différentes demandes erronées. Si vous remarquez que les réponses ne sont pas les mêmes, vous devriez enquêter et trouver la clé qui crée une différence entre les deux réponses. Par exemple:

• Demande du client: utilisateur valide / mot de passe incorrect - réponse du serveur>: 'Le mot de passe n'est pas correct “
• Demande du client: Mauvais utilisateur / mot de passe incorrect - réponse du serveur>: 'Utilisateur non reconnu ”

Les réponses ci-dessus permettent au client de comprendre que pour la première demande, nous avons un nom d'utilisateur valide. Ainsi, nous pouvons interagir avec l'application avec un ensemble demandes utilisant des noms d'utilisateurs possibles et en observant la réponse.

En regardant la seconde réponse du serveur, nous comprenons la même manière dont nous nous pouvons déterminer un identifiant est valide. Donc, nous pouvons interagir de la même manière et créer une liste de nom d'utilisateur valide en regardant les réponses du serveur.

On peut énumérer les utilisateurs de plusieurs façons, par exemple:

Certaines applications Web lretournent un code d'erreur spécifique ou un message que nous pouvons analyser.

Par exemple:

http://www.foo.com/err.jsp?User=baduser&Error=0

http://www.foo.com/err.jsp?User=gooduser&Error=2

Comme on peut le voir ci-dessus, lorsque nous fournissons un code utilisateur et un mot de passe pour l'application Web, nous voyons une indication dans le message qu'une erreur s'est produite dans l'URL. Dans le premier cas, nous avons fourni un mauvais. nom d'utilisateur et mot de passe incorrect Dans le second, un bon utilisateur et mot de passe incorrect, afin que nous puissions identifier un nom d'utilisateur valide.

Parfois, un serveur Web répond différemment s'il reçoit une demande d'un répertoire existant ou non. Par exemple, dans certains portails chaque utilisateur est associé à un répertoire. Si nous essayons d'accéder à un répertoire inexistant que nous pouvons recevoir une erreur du serveur Web. Une erreur très commune que nous pouvons recevoir à partir du serveur Web est:

403 Forbidden error code 

et

404 Not found error code

Exemple

http://www.foo.com/account1 - nous recevons du serveur web: 403 Forbidden
http://www.foo.com/account2 - nous recevons du serveur web: 404 File Not Found

Dans le premier cas l'utilisateur existe, mais nous ne pouvons pas afficher la page Web, dans le second cas l'utilisateur “compte2” n'existe pas. Par la collecte de cette information, nous pouvons énumérer les utilisateurs.

Nous pouvons recevoir des informations utiles sur le titre de la page web, où l'on peut obtenir un code d'erreur spécifique ou les messages qui révèlent si les problèmes sont le nom d'utilisateur ou mot de passe. Par exemple, si on ne peut pas s'authentifier auprès d'une demande et aue l'on reçoive une page Web dont le titre est similaire à:

Invalid user
Invalid authentication

Lorsque nous utilisons une fonction de récupération (c'est à dire une fonction permettant de récupérer les mots de passe oubliés) une application vulnérable peut renvoyer un message qui révèle si un nom d'utilisateur existe ou non.

Par exemple, un message semblable au suivant:

Invalid username: e-mail address is not valid or the specified user was not found.
Valid username: Your password has been successfully sent to the email address you registered with.

Lorsque nous demandons à un utilisateur dont le répertoire n'existe pas, nous ne recevons pas toujours code d'erreur 404. Au lieu de cela, nous pouvons recevoir “200 ok” avec une image, dans ce cas, on peut supposer que lorsque nous recevons l'image spécifique l'utilisateur n'existe pas. Cette logique peut être appliquée à d'autres réponses du serveur Web, l'astuce est une bonne analyse du serveur web et des messages d'applications Web.

Dans certains cas, les noms d'utilisateurs sont créés avec les politiques spécifiques de l'administrateur ou de la société. Par exemple, nous pouvons avoir un utilisateur avec un ID créé dans un ordre séquentiel :

CN000100
CN000101
....

Parfois, les noms d'utilisateurs sont créés avec un alias REALM et puis un numéro séquentiel:

R1001 - utilisateur 001 pour REALM1
R2001 - utilisateur 001 pour REALM2

Dans l'échantillon ci-dessus, nous pouvons créer des scripts shell simples qui confectionnent les UserIds et soumettre la demande avec un outil comme wget pour automatiser les requêtes Web pour discerner les noms d'utilisateurs valides. Pour créer un script, nous pouvons également utiliser Perl et CURL.

D'autres possibilités sont les suivantes: - noms d'utilisateurs associés à des numéros de cartes de crédit, ou a nombre général avec un motif. - Noms d'utilisateurs associés à des noms réels, par exemple si Freddie Mercury a un ID utilisateur de “fmercury”, alors vous pouvez deviner l'ID de Roger Taylor = “rtaylor”.

Encore une fois, on peut deviner un nom d'utilisateur à partir des informations reçues d'une requête LDAP ou de collectes d'informations sur Google, par exemple, à partir d'un domaine spécifique. Google peut vous aider à trouver les utilisateurs du domaine à travers des requêtes spécifiques, soit par un simple script shell ou à l'aide d'un outil.

Attention: en énumérant les comptes d'utilisateurs, vous risquez de verrouiller les comptes après qu'un nombre prédéfini de sondage ont échoué (basée sur la politique de l'application). Aussi, parfois, votre adresse IP peut être interdite par les règles dynamiques sur le pare-feu applicatif ou système de prévention des intrusions.

Vérifier que l'application réponde de la même manière pour chaque requête client qui produit un échec d'authentification. Pour cette étude, les tests Boîte noire et Boîte grise utilisent le même concept basé sur l'analyse des messages reçus ou des codes d'erreur de l'application Web.

Résultat attendu:

L'application doit répondre de la même manière pour chaque échec de l'authentification.

Par exemple:

Credentials submitted are not valid

• Marco Mella, Sun Java Access & Identity Manager Users enumeration: http://www.aboutsecurity.net
• Username Enumeration Vulnerabilities: http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities

• WebScarab: OWASPWebScarabProject

  • CURL: http://curl.haxx.se/
  • PERL: http://www.perl.org
  • Sun Java Access & Identity Manager users enumeration tool: http://www.aboutsecurity.net