This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

4.5.8 Test de Questions-Reponses Faibles (OTG-AUTHN-008)

From OWASP
Revision as of 13:34, 7 October 2015 by Vall (talk | contribs) (Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Souvent appelée "question secrète", les questions et les réponses de sécurité sont souvent utilisées pour la récup...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


Sommaire

Souvent appelée "question secrète", les questions et les réponses de sécurité sont souvent utilisées pour la récupération de mots de passe oubliés ou comme un complément de sécurité en plus du mot de passe. (Voir Testing for weak password change or reset functionalities (OTG-AUTHN-009)).

Elles sont habituellement générées à la création du compte et nécessitent que l'utilisateur choisisse l'une des questions prédéfinies et renseigne la réponse correspondante. Parfois, il est possible que l'utilisateur puisse proposer sa propre question et sa réponse. Les deux méthodes sont sujettes à des risques de sécurité.

Dans l'idéal, ces questions secrètes devraient correspondre à des réponses connues seulement de l'utilisateur et ne pas pouvoir être découvertes ou devinées par n'importe qui. C'est plus difficile que ça en a l'air.

Les questions et réponses de sécurité reposent sur le secret de la réponse. Les questions et réponses devraient être choisies afin que seul le titulaire du compte sache y répondre. Cependant, bien que beaucoup de réponses puissent ne pas être publiquement connues, la plupart des questions, que les sites web implémentent et mettent en avant, sont des réponses pseudo-privées.

Questions prédéfinies :
La majorité des questions prédéfinies sont passablement simples par nature et peuvent conduire à des réponses sans sécurité.

Par exemple:

  • Les réponses peuvent être connues par les membres de la famille ou des amis proches de l'utilisateur, ex. "Quel le nom de jeune fille de votre mère?", "Quelle est votre date de naissance?"
  • Les réponses peuvent être facilement imaginées, ex. "Quelle est votre couleur préférée?", "Quelle est votre équipe de base-ball favorite?"
  • Les réponses peuvent être trouvées par force brute, ex. "Quel est le prénom de votre enseignant préféré dans le secondaire?" - La réponse est probablement dans une liste de prénoms courants,

facilement téléchargeable, et peut permettre de réaliser une simple attaque par brute force avec un script.

  • Les réponses peuvent être publiques, ex. "Quel est votre film préféré?" - la réponse peut être trouvée facilement sur la page de profil des réseaux sociaux de l'utilisateur.


Questions auto-générées:
La difficulté de permettre aux utilisateurs de générer leur propre question est que cela leur laisse la possibilité de générer des questions absolument pas sûres, ou même de contourner complètement la procédure concernant la question de sécurité.

Voici quelques exemples du monde réel qui illustrent ce point:

  • "Combien font 1+1?"
  • "Quel est votre username?"
  • "Mon mot de passe est M3@t$p1N"


Comment Tester

Test des questions prédéfinies faibles :
Essayer d'obtenir la liste des questions de sécurité en créant un nouveau compte ou en suivant le lien de type “J'ai oublié mon mot de passe”.

Essayer de générer le plus de questions possibles pour avoir une idée du type de questions posées. Si l'une des questions de sécurité se retrouve dans l'une des catégories citées plus haut, alors elles sont vulnérables à une attaque (conjecture, force brute, disponible sur les réseaux sociaux, etc.).

Test des questions auto-générées faibles:
Essayer de créer des questions de sécurité en créant un nouveau compte ou, en reconfigurant les propriétés de récupération du mot de passe de votre compte existant. Si le système permet à l'utilisateur de générer ses propres questions de sécurité alors il est vulnérable au fait de pouvoir créer des questions non sûres. Si le système utilise les questions de sécurité auto-générées pendant la procédure de récupération du mot de passe et si les comptes utilisateur peuvent être énumérés alors il sera facile pour le testeur de lister quelques questions auto-générées. (voir Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)) On devrait ainsi trouver plusieurs questions auto-générées faibles avec cette méthode.

Test des réponses par force brute:
Utiliser les méthodes décrites dans Testing for Weak lock out mechanism (OTG-AUTHN-003) pour déterminer si plusieurs réponses incorrectes à la question générent un blocage du compte.

La première chose à prendre en compte, lorsqu'on essaie d'exploiter les questions de sécurité, est le nombre de questions auxquelles il faut répondre. La plupart des applications ne demandent à l'utilisateur qu'une réponse à une seule question tandis que quelques applications critiques peuvent nécessiter que l'utilisateur réponde à deux questions, voire plusieurs.

L'étape suivante consiste à évaluer la robustesse des questions de sécurité. Est-ce que les réponses peuvent être obtenues par une simple recherche Google ou par une attaque d'ingénierie sociale?

Pour faire un test d'intrusion, voilà ce qu'il faut réaliser, étape par étape, pour exploiter la procédure de la question secrète:


  • L'application permet-elle à l'utilisateur final de choisir la question à laquelle il devra répondre? Si oui, se concentrer sur les questions dont la réponse est de type :


    • Une réponse “publique”; par exemple, quelque-chose qu'on peut trouver avec une simple requête à un moteur de recherche.
    • Une réponse factuelle telle que la "première école" ou autres faits qui peuvent faire l'objet d'une recherche.
    • Un petit éventail de réponses possibles, comme pour “quel était le modèle de votre première voiture”.


Ce type de questions donnera au testeur une courte liste de réponses possibles et, sur la base de statistiques, l'attaquant pourra les classer de la plus probable à la moins probable.

  • Determiner si possible combien d'essais sont autorisés.


    • La procédure de récupération du mot de passe permet-elle des essais illimités?
    • Y-a-t-il une période de blocage après X réponses incorrectes?

Garder à l'esprit que le système de blocage peut présenter un problème de sécurité par lui-même puisqu'il peut être exploité par un attaquant pour effectuer un Déni de Service contre des utilisateurs légitimes.

  • Prendre la question appropriée, basée sur l'analyse des points précédents, et faire une recherche pour déterminer la réponse la plus probable.


La clef du succès pour exploiter et contourner la procédure des questions secrètes faibles est de trouver une question, ou un jeu de questions, qui donne(nt) la possibilité de trouver facilement les réponses Rechercher toujours les questions qui vous donneront la plus grance chance statistique d'en deviner la réponse, si vous n'avez aucune idée des réponses. Au final, la procédure des questions de sécurité est aussi forte que sa question la plus faible.

Références

The Curse of the Secret Question