💭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é.

Faire la même chose si connexion avec email.

Cas 4: Normalisation unicode

Créer un compte: [e-mail]

Créer un deuxième compte avec un caractère unicode normalisant le mail en le premier créé

Exemple: vić[e-mail]

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 ([e-mail])

• Ne pas cliquer sur l'email de vérification.

• Changer l'email vers un email victime ([e-mail])

• 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é.

Afin de confirmer l'impact, essayer d'ajouter du contenu avec le nouveau compte et de rafraichir la page du premier pour voir si le contenu est visible par celui-ci.

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

🛒Fonctions d'achat et de facturation

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 > JSON

• XXXX > 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.

🪞Race conditions

Ressources

• https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-authentication-bypass-via-encryption-oracle

• https://hackerone.com/reports/867513

• https://bugreader.com/marcos@change-the-username-for-any-facebook-page-219

• https://hackerone.com/reports/910300

• https://hackerone.com/reports/790786