Account Takeover
Problème d'autorisation
L'email d'un compte doit être tenté d'être modifié, et le processus de confirmation doit être examiné. Si celui-ci est jugé faible, l'email doit être changé pour celui de la victime prévue, puis confirmé.
Problème de normalisation Unicode
Le compte de la victime prévue
victim@gmail.comUn compte devrait être créé en utilisant Unicode par exemple :
vićtim@gmail.com
Pour plus de détails, consultez le document sur la normalisation Unicode :
Réutilisation du jeton de réinitialisation
Si le système cible permet le réutilisation du lien de réinitialisation, des efforts doivent être déployés pour trouver plus de liens de réinitialisation en utilisant des outils tels que gau, wayback, ou scan.io.
Pré-prise de contrôle de compte
L'email de la victime doit être utilisé pour s'inscrire sur la plateforme, et un mot de passe doit être défini (une tentative de confirmation devrait être faite, bien que l'absence d'accès aux emails de la victime puisse rendre cela impossible).
Il faut attendre que la victime s'inscrive en utilisant OAuth et confirme le compte.
On espère que l'inscription régulière sera confirmée, permettant l'accès au compte de la victime.
Mauvaise configuration CORS pour la prise de contrôle de compte
Si la page contient des mauvaises configurations CORS, vous pourriez être en mesure de voler des informations sensibles de l'utilisateur pour prendre le contrôle de son compte ou le faire changer d'informations d'authentification à cette fin :
pageCORS - Misconfigurations & BypassCSRF pour la prise de contrôle de compte
Si la page est vulnérable au CSRF, vous pourriez être en mesure de faire modifier le mot de passe de l'utilisateur, l'email ou l'authentification pour y accéder ensuite :
pageCSRF (Cross Site Request Forgery)XSS pour la prise de contrôle de compte
Si vous trouvez un XSS dans l'application, vous pourriez être en mesure de voler des cookies, du stockage local, ou des informations de la page web qui pourraient vous permettre de prendre le contrôle du compte :
pageXSS (Cross Site Scripting)Même origine + Cookies
Si vous trouvez un XSS limité ou une prise de contrôle de sous-domaine, vous pourriez jouer avec les cookies (les fixer par exemple) pour essayer de compromettre le compte de la victime :
pageCookies HackingAttaque du mécanisme de réinitialisation de mot de passe
pageReset/Forgotten Password BypassManipulation de la réponse
Si la réponse d'authentification peut être réduite à un simple booléen, essayez de changer false en true et voyez si vous obtenez un accès quelconque.
OAuth pour la prise de contrôle de compte
pageOAuth to Account takeoverInjection d'en-tête Host
L'en-tête Host est modifié suite à une demande de réinitialisation de mot de passe.
L'en-tête proxy
X-Forwarded-Forest modifié enattacker.com.Les en-têtes Host, Referrer et Origin sont simultanément changés en
attacker.com.Après avoir initié une réinitialisation de mot de passe et ensuite opté pour renvoyer le mail, les trois méthodes mentionnées ci-dessus sont employées.
Manipulation de la réponse
Manipulation du code : Le code d'état est modifié en
200 OK.Manipulation du code et du corps :
Le code d'état est changé en
200 OK.Le corps de la réponse est modifié en
{"success":true}ou un objet vide{}.
Ces techniques de manipulation sont efficaces dans les scénarios où JSON est utilisé pour la transmission et la réception de données.
Références
Dernière mise à jour