Business logic
Les vulnérabilités de logique business sont très diverses et variées étant donné qu'elle dépendent de chaque cible et de chaque secteur professionnel.
Les exemples ci-dessous font partie d'un infime échantillon de ce qui peut être retrouvé.
Account takeover
Cas 1: Session active après suppression du compte
Connexion en tant qu'attaquant avec un compte random.
Demande de suppression du compte au staff.
Rafraichir la page.
Si toujours connecté après rafraichissement:
Aller dans le profil pour vérifier qu'il est bien supprimé.
Créer un deuxième compte avec un autre nom d'utilisateur.
Changer son username en celui qui a été supprimé.
Rafraichir la page du navigateur attaquant.
Retourner dans le profil.
Si le profil correspond maintenant au deuxième compte alors la manipulation a fonctionné.
Cas 2: Absence de suppression définitive du compte
Créer un compte
Faire des modifications
Supprimer le compte
Recréer un compte avec les mêmes informations
Si on retrouve les données enregistrés sur le compte supprimé alors la manipulation a fonctionné.
Cas 3: Majuscules et minuscules
Créer un compte (exp: RandomAccount)
Faire des modifications
Créer un deuxème compte avec les même lettres mais dans lequel les minuscules et majuscules sont placées différemment (exp: rAndOmAccOnT)
Si le deuxième compte contient les modifications du premier alors la manipulation a fonctionné.
Cas 4: Normalisation unicode
Créer un compte: victim@mail.xyz
Créer un deuxième compte avec un caractère unicode normalisant le mail en le premier créé
Exemple: vićtim@mail.xyz
Cas 5: Lien d'invitation non vérifié
Si une fonction d'invitation existe, intercepter la requête d'invitation et si le lien est leaké dans la réponse, essayer de la suivre afin de potentiellement accepter l'invitation au nom de l'utilisateur invité.
Cas 6: Reset link n'expire pas après modification de l'email
Étapes à suivre:
Générer un lien de reset de mot de passe.
Se connecter.
Changer d'email.
Se déconnecter.
Suivre le lien de reset de mot de passe.
Si il est possible de changer de mot de passe depuis l'ancien email, il y a un risque d'account takeover.
Cas 7: Email verification bypass
Changer d'email vers un email contrôlé par l'attaquant (attacker@mail.xyz)
Ne pas cliquer sur l'email de vérification.
Changer l'email vers un email victime (victim@mail.xyz)
Cliquer sur le lien précédemment reçu sur l'email attaquant.
Si l'email de la victime est validée à la place de l'email attaquant il y a alors un risque d'account takeover.
Mauvaise gestion des sessions
Cas 1: Session active après renommage du compte
Se connecter avec un compte
Se renommer
Rafraichir la page
Si l'ancien nom d'utilisateur est encore actif:
Créer un nouveau compte avec l'ancien nom d'utilisateur
Si il y a maintenant deux sessions actives sur le même nom d'utilisateur, alors la manipulation a fonctionné.
Bypass de politique de mot de passe
Cas 1: Changment de mot de passe
Essayer de créer un mot de passe faible (bloqué par politique de mot de passe)
Créer un mot de passe en respect avec la politique de mot de passe.
Sur le compte, vérifier si la fonction de changement de mot de passe posséde la même restriction.
E-commerce
Confiance excessive dans les contrôles côté client
Arrive lorsqu'une restriction côté client n'est pas mise en place côté serveur.
Incapacité à traiter les entrées non attendues
Arrive lorsqu'une entrée utilisateur n'est pas celle qui est attendu par le serveur:
String > Integer
Integer > String
JSON >
JSONXXXX > 9999999999999999999999999999
...
Bruteforce de mot de passe via fonction de password reset
Si la fonction de changement de mot de passe prend un paramètre username, email ou id, vérifier le rate limit sur la requête pour vérifier si il y a possibilité de bruteforce le mot de passe d'un autre utilisateur.
Sinon, créer un deuxième compte et essayer de changer le mot de passe de ce compte avec sur la session du premier.
Cryptographic flaw example
Rechercher les emplacement où du chiffrement (et non pas du hashage) est utilisé dans l'application.
Déterminer les emplacement ou l'application chiffre ou déchiffre des valeurs entrées par l'utilisateur.
Essayer de provoquer une erreur dans l'application qui révéle la valeur déchiffré ou l'emplacement dans lequelle on pourrait retrouver cette valeur.
Tenter de d'afficher via cette possibilité en texte clair des secrets chiffrés tels que des cookies de session, mot de passe ou encore un numéro de carte de crédit.
Inversement, tenter d'injecter des payload en texte clair aux emplacements ou le chiffrement est effectué.
Race condition on login form lead to information disclosure
Essayer de connecter deux utilisateurs exactement au même moment et vérifier si ces deux utilisateurs ont momentanément accès aux données le l'autre.
Ressources
Dernière mise à jour
Cet article vous a-t-il été utile ?