👽Broken authentication / register

Connexion avec Google

étapes:

• Aller dans connexion avec google

• Remplir les informations

• Intercepter la requête avec Burp Suite

• Decoder la signature qui est en base64

• Changer l'email et réencoder la nouvelle signature

• Se connecter avec la nouvelle signature

• Si cette technique fonctionne vous devriez être connecté avec une fausse adresse mail

Longue chaîne de caractères pour bypass la vérification

• Interface d'administration lorsqu'on se connecte avec email interne

• Enregistrez vous avec un email très long.

Exemple:

very-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-stringvery-long-string[e-mail]

• Dans "mon compte", regardez si l'email a été coupé à un point.

• Si c'est le cas, modifiez votre email pour qu'il soit coupé exactement à la fin du préfix de l'email cible.

Pour que cela fonctionne, le site doit ne pas faire de vérification au changement d'email ce qui est rare.

Remplacement d'utilisateur existant

Le remplacement d'utilisateur existant se produit lorsqu'une application nous permet de nous inscrire avec la même adresse e-mail, nom d'utilisateur ou numéro de téléphone plusieurs fois. Cela peut avoir des conséquences critiques en fonction du type d'attaque effectuée.

étapes:

• Créez un premier compte dans l'application avec un e-mail et un mot de passe.

• Déconnectez-vous du compte et créez un autre compte avec le même e-mail et un mot de passe différent.

• Vous pouvez même essayer des variantes de l'e-mails dans certains cas, exemple: [e-mail] en [e-mail].

• Si vous arrivez à vous connecter avec le nouveau mot de passe alors la cible est vulnérable.

XSS

Charge utile pour le champ Nom d'utilisateur :

<img src=x onerror=alert(1)>

Charge utile pour le champ E-mail:

"><svg/onload=confirm(1)>" @gmail.com

Rate limit

S'il n'y a pas de limitation de débit sur la page d'inscription, des utilisateurs malveillants peuvent générer des centaines et des milliers de faux comptes qui conduisent à remplir la base de données de l'application avec de faux comptes, ce qui peut avoir un impact sur l'entreprise de plusieurs façons.

Vous pouvez facilement le tester avec Burp Intruder.

• Capturez la demande d'inscription et envoyez-la dans l'Intruder.

• Ajoutez différents e-mails en tant que charge utile.

• Lancez l'Intruder et vérifiez s'il renvoie 200 OK.

JSON bruteforce

Si la requête de connexion est en json, il est possible de tenter de bruteforce le mot de passe d'un utilisateur comme ceci:

exemple de requête:

{
    "username":"<username>",
    "password":"",
    "":""
}

attaque par dictionnaire:

En créant un tableau json contenant les mots de passe à tester on va faire en sorte que chacun d'entre eux soient traités par le serveur en une seule requête ce qui va nous permettre de contourner une éventuelle limite de requête de connexion.

{
    "username":"<username>",
    "password":[
    "1234",
    "1111",
    "0000",
    "password",
    "azerty",
    ...
    ...
    "root"
    ]
}

JSON object injection

{
    "email": {
        "email":1
        }
    "password":"valid password",
}

Authentification basic HTTP

Bien qu'assez ancienne, sa simplicité relative et sa facilité de mise en œuvre signifient que vous pouvez parfois voir l'authentification de base HTTP utilisée. Dans l'authentification de base HTTP, le client reçoit un jeton d'authentification du serveur, qui est construit en concaténant le nom d'utilisateur et le mot de passe, et en le codant en Base64. Ce jeton est stocké et géré par le navigateur, qui l'ajoute automatiquement à l' en-tête Authorization de chaque requête suivante comme suit :

Authorization: Basic base64(username:password)

Pour un certain nombre de raisons, cela n'est généralement pas considéré comme une méthode d'authentification sécurisée. Premièrement, cela implique d'envoyer à plusieurs reprises les identifiants de connexion de l'utilisateur à chaque demande. À moins que le site Web n'implémente également HSTS, les informations d'identification des utilisateurs sont susceptibles d'être capturées lors d'une attaque de type "man-in-the-middle".

De plus, les implémentations de l'authentification de base HTTP ne prennent souvent pas en charge la protection contre la force brute. Comme le jeton se compose exclusivement de valeurs statiques, cela peut le rendre vulnérable à la force brute.

L'authentification de base HTTP est également particulièrement vulnérable aux exploits liés à la session, notamment CSRF , contre lesquels elle n'offre aucune protection par elle-même.

Dans certains cas, l'exploitation d'une authentification de base HTTP vulnérable ne peut accorder à un attaquant qu'un accès à une page apparemment inintéressante. Cependant, en plus de fournir une surface d'attaque supplémentaire, les informations d'identification ainsi exposées peuvent être réutilisées dans d'autres contextes plus confidentiels.

Utiliser le lien de vérification comme lien de réinitialisation de mot de passe

Si le site utilise la même méthode pour générer des tokens de vérification de mot de passe et de réinitialisation de mot de passe il est possible d'utiliser un token de vérification pour prendre le contrôle d'un compte et inversement.

Exemple d'un rapport:

https://target.com/user/validate_link?step=account&verify_link=XXXXXX => account verified

supprimer l'étape "step=account".

httsp://target.com/user/validate_link?verify_link=XXXXXXX => password reset

Account takeover via lien de confirmation

• Créer deux utilisateurs ([e-mail] et [e-mail])

• Remplacer l'email de [e-mail] par [e-mail]

• Un email de confirmation est envoyé à [e-mail]

• Ouvrir le lien avec le navigateur de la victime

• Vérifier si l'email de la victime a été remplacé par [e-mail]

Mindmap