Skip to main content
Les problèmes d’authentification permettent aux attaquants de se connecter sous l’identité d’autres utilisateurs, de forcer des comptes par force brute ou de contourner entièrement la connexion. Ces vulnérabilités sont souvent triviales à exploiter et ont des conséquences graves.

​
default-accounts-present

Critique

​
Description

L’application accepte des identifiants par défaut bien connus qui n’ont jamais été changés après le déploiement. Les valeurs par défaut courantes incluent admin/admin, admin/password, root/root et admin/1234.

​
Importance

Les attaquants essaient systématiquement les identifiants par défaut comme première étape de la reconnaissance. Une seule connexion réussie accorde un accès administratif complet sans aucune attaque sophistiquée.

​
Comment QAOS le détecte

Lorsque l’agent rencontre un formulaire de connexion, il tente une authentification avec un ensemble de paires d’identifiants par défaut courants : admin/admin, admin/password, root/root, admin/1234.

​
Comment corriger

Forcez le changement d’identifiants à la première connexion pour tout compte créé avec des identifiants par défaut. Supprimez ou désactivez complètement les comptes par défaut en production. Effectuez des audits réguliers pour s’assurer qu’aucun compte avec des identifiants par défaut n’existe.

​
default-credentials-in-dom

Critique

​
Description

La page elle-même révèle des identifiants par défaut ou d’usine — via du texte d’espace réservé, des champs de formulaire pré-remplis, des commentaires HTML inline, du texte visible ou des sections d’aide sur la page.

​
Importance

Révéler des identifiants dans le DOM signifie que tout utilisateur qui ouvre les DevTools ou consulte le code source de la page peut les voir. Aucune attaque technique n’est requise.

​
Comment QAOS le détecte

L’agent inspecte le DOM pour les indices d’identifiants visibles : attributs placeholder, attributs value pré-remplis sur les champs de connexion, commentaires HTML et texte visible contenant des motifs comme « connexion par défaut », « mot de passe d’usine » ou « utiliser admin/ ».

​
Exemples

<!-- Identifiants divulgués dans le placeholder -->
<input type="text" placeholder="admin" name="username">
<input type="password" placeholder="admin" name="password">

<!-- Identifiants dans un commentaire HTML -->
<!-- connexion par défaut : root/root -->

<!-- Identifiants dans du texte visible -->
<p>Première connexion : utiliser admin / admin123</p>

​
Comment corriger

Supprimez tous les indices d’identifiants du DOM. Utilisez du texte d’espace réservé générique comme « Nom d’utilisateur » et « Mot de passe ». N’incluez jamais d’identifiants dans les commentaires, le texte d’aide ou les valeurs pré-remplies sur les pages en production.
Critique

​
Description

Les cookies de session encodent l’identité utilisateur d’une façon qui peut être prédite, décodée ou modifiée pour usurper l’identité d’autres utilisateurs. Cela inclut les IDs utilisateur encodés en base64, les motifs prévisibles ou les simples hachages du nom d’utilisateur.

​
Importance

Si un attaquant peut construire un cookie de session valide pour un autre utilisateur sans connaître son mot de passe, il peut prendre le contrôle de n’importe quel compte sur la plateforme.

​
Comment QAOS le détecte

L’agent analyse les cookies de session et d’authentification pour détecter les valeurs à faible entropie, le contenu encodé en base64, les horodatages, les valeurs purement numériques ou les motifs corrélés avec des identifiants utilisateur connus.

​
Exemples

session=dXNlcjEyMw==      ← décodage base64 : "user123" — trivialement falsifiable
auth_token=1708473600123  ← horodatage Unix — prévisible
session_id=00001042        ← numérique séquentiel — énumérable

​
Comment corriger

Générez des jetons de session en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé avec au moins 128 bits d’entropie. N’encodez jamais l’identité utilisateur directement dans les jetons de session. Utilisez un magasin de sessions côté serveur qui mappe des jetons opaques vers des sessions utilisateur. 
import secrets
session_token = secrets.token_urlsafe(32)  # 256 bits d'entropie

​
no-password-spraying-protection

Élevé

​
Description

Le formulaire de connexion ne protège pas contre les attaques par pulvérisation de mots de passe — où un attaquant essaie un seul mot de passe courant sur de nombreux comptes différents, évitant les verrouillages par compte.

​
Importance

La pulvérisation de mots de passe est l’une des techniques d’attaque par identifiants les plus efficaces car elle reste sous les seuils de verrouillage par compte. Un seul mot de passe courant comme « Été2024! » peut correspondre à un pourcentage significatif des comptes utilisateurs.

​
Comment QAOS le détecte

L’agent teste les formulaires de connexion en essayant le même mot de passe sur plusieurs noms d’utilisateur différents en succession rapide, observant si l’application détecte ou ralentit ce motif.

​
Comment corriger

Implémentez une limitation de débit basée sur l’IP source et la valeur du mot de passe, pas seulement le nom d’utilisateur. Surveillez le même mot de passe essayé sur plusieurs comptes. Envisagez un CAPTCHA après un seuil d’échecs depuis une seule IP, quel que soit le nom d’utilisateur ciblé.

​
no-login-rate-limiting

Élevé

​
Description

Le formulaire de connexion permet des tentatives d’authentification échouées illimitées sans verrouillage, délais progressifs ou défis CAPTCHA.

​
Importance

Sans limitation de débit, les attaquants peuvent effectuer des attaques par force brute ou par bourrage d’identifiants à haute vitesse, devinant éventuellement des identifiants valides.

​
Comment QAOS le détecte

L’agent soumet des tentatives de connexion invalides répétées et observe si l’application répond avec une limitation de débit (HTTP 429, message de verrouillage, délai progressif ou CAPTCHA).

​
Comment corriger

Implémentez un verrouillage par compte après 5 à 10 tentatives échouées. Ajoutez des délais de recul exponentiel pour les échecs répétés. Envisagez un CAPTCHA après 3+ échecs. Journalisez et alertez sur les motifs inhabituels de tentatives de connexion.

​
compromised-credentials-accepted

Élevé

​
Description

Le formulaire d’inscription ou de changement de mot de passe accepte des identifiants connus pour être compromis dans des violations de données publiques.

​
Importance

Les attaques par bourrage d’identifiants réutilisent des combinaisons nom d’utilisateur/mot de passe divulguées sur plusieurs services. Si votre application ne vérifie pas les mots de passe connus comme compromis, elle est vulnérable aux attaques automatisées utilisant des bases de données de violations.

​
Comment QAOS le détecte

L’agent tente de s’inscrire ou de changer des mots de passe en utilisant des paires d’identifiants compromis bien connus provenant de jeux de données de violations publiques.

​
Comment corriger

Intégrez avec l’API Have I Been Pwned (modèle k-anonymat) pour vérifier les mots de passe par rapport aux bases de données de violations connues lors de l’inscription et du changement de mot de passe. Rejetez les mots de passe compromis et invitez l’utilisateur à en choisir un différent.

​
weak-password-accepted

Moyen

​
Description

Le système d’authentification accepte des mots de passe faibles — moins de 8 caractères, ou des mots de passe courants comme 123456, password ou abc.

​
Importance

Les mots de passe faibles sont trivialement devinables par les attaquants humains et les outils automatisés. Les accepter crée des comptes facilement compromis.

​
Comment QAOS le détecte

L’agent tente de s’inscrire ou de changer des mots de passe en utilisant des valeurs de test faibles : 123456, password, abc et d’autres motifs courants.

​
Comment corriger

Imposez une longueur minimale de mot de passe de 8 caractères (12+ recommandé). Rejetez les mots de passe courants. Envisagez d’utiliser zxcvbn pour l’estimation de la robustesse plutôt que de simples règles de longueur.

​
knowledge-based-password-recovery

Élevé

​
Description

Le flux de récupération de mot de passe repose sur des questions de connaissance personnelle — telles que « le nom de jeune fille de la mère », « le nom du premier animal de compagnie » ou « la ville de naissance » — pour vérifier l’identité avant de permettre une réinitialisation de mot de passe.

​
Importance

Les réponses aux questions de sécurité sont souvent disponibles publiquement via les réseaux sociaux, les violations de données ou l’ingénierie sociale. Elles offrent une garantie d’authentification beaucoup plus faible que la vérification par email ou SMS, et ne peuvent pas être changées une fois compromises.

​
Comment QAOS le détecte

L’agent navigue vers le flux de mot de passe oublié ou de récupération de compte et vérifie s’il demande des questions de connaissance personnelle avant d’accorder l’accès ou d’initier une réinitialisation.

​
Comment corriger

Remplacez la récupération basée sur la connaissance par un jeton à durée limitée et à usage unique envoyé à un email ou numéro de téléphone vérifié. Pour les applications à haute assurance, exigez que l’utilisateur confirme son identité via MFA avant de réinitialiser les identifiants.

​
insecure-password-reset-process

Élevé

​
Description

Le processus de réinitialisation de mot de passe est vulnérable — le jeton de réinitialisation est prévisible, n’expire pas ou peut être rejoué. Un attaquant qui intercepte ou devine un jeton de réinitialisation peut prendre le contrôle du compte sans connaître le mot de passe original.

​
Importance

Les flux de réinitialisation de mot de passe sont des cibles de haute valeur car ils contournent l’identifiant principal. Un processus de réinitialisation faible supprime effectivement la sécurité du mot de passe entièrement.

​
Comment QAOS le détecte

L’agent déclenche le flux de réinitialisation de mot de passe et inspecte le jeton de réinitialisation pour sa prévisibilité (séquentiel, court, basé sur un horodatage). Il teste également si le jeton peut être réutilisé après la réinitialisation.

​
Comment corriger

Générez des jetons de réinitialisation en utilisant un générateur aléatoire cryptographiquement sécurisé avec au moins 128 bits d’entropie. Expirez les jetons après 15 à 60 minutes. Invalidez le jeton immédiatement après sa première utilisation. Assurez-vous que les jetons sont limités à un utilisateur spécifique et ne peuvent pas être transférés. 
import secrets
token = secrets.token_urlsafe(32)  # jeton 256 bits, compatible URL

​
missing-mfa-sensitive-actions

Élevé

​
Description

Les actions sensibles — telles que le changement de mot de passe, la mise à jour des détails de paiement, le transfert de fonds ou la modification des paramètres de récupération de compte — se complètent après une authentification par mot de passe uniquement, sans deuxième facteur requis.

​
Importance

Si un attaquant accède à la session d’un utilisateur (via XSS, détournement de session ou un appareil compromis), il peut effectuer des actions à fort impact sans aucune barrière supplémentaire. Le MFA sur les actions sensibles limite les dommages d’une session compromise.

​
Comment QAOS le détecte

L’agent identifie les flux pour les opérations sensibles (changements d’identifiants, modifications de paiement, paramètres de récupération de compte) et tente de les compléter sans second facteur d’authentification.

​
Comment corriger

Exigez une authentification renforcée (ré-authentification ou défi MFA) avant de compléter les actions à fort impact, même au sein d’une session déjà authentifiée. Les motifs courants incluent :
  • Ressaisir le mot de passe actuel avant de le changer
  • Exiger un OTP d’une application d’authentification ou SMS avant les changements de paiement
  • Envoyer un lien de confirmation par email pour les modifications des coordonnées de récupération

​
weak-mfa-fallback-mechanism

Élevé

​
Description

Quand le MFA est indisponible (appareil perdu, code de secours expiré), le mécanisme de récupération de secours est faible — il repose sur des questions de connaissance personnelle, un court code statique ou un canal avec une assurance insuffisante — permettant aux attaquants de contourner le MFA entièrement.

​
Importance

Le MFA est seulement aussi fort que son mécanisme de secours le plus faible. Si un attaquant peut contourner le MFA en répondant à une question de sécurité, l’ensemble du second facteur est annulé. Les mécanismes de secours sont fréquemment la vraie cible des attaques de prise de contrôle de compte.

​
Comment QAOS le détecte

L’agent navigue vers la page de défi MFA et explore les options de récupération/secours, vérifiant si elles offrent une assurance équivalente au second facteur principal.

​
Comment corriger

Les mécanismes de secours doivent être au moins aussi forts que la méthode MFA principale :
  • Codes de secours : codes à usage unique et à haute entropie générés lors de la configuration MFA
  • Récupération de compte : exiger une vérification d’identité via un canal de confiance (lien email + preuve de propriété du compte)
  • Récupération assistée par le support : exiger une vérification humaine avec pièce d’identité avec photo ou similaire
Ne jamais permettre le contournement du MFA via des questions de sécurité, de courts PINs statiques ou des flux de récupération non authentifiés.