PC & Mobile

Attaque de sites à l'aide de CSRF – Le démarrage

Attaque de sites à l'aide de CSRF - Le démarrage


De CSRF à la fuite d'informations utilisateur, XSS et prise de contrôle de compte complète.

CSRF et gazon. (Photo de Chensiyuan sur Wikimedia Commons.)

La criticité d'une vulnérabilité CSRF dépend fortement de l'emplacement de la vulnérabilité. Parfois, des mécanismes de protection CSRF défectueux entraînent des problèmes sans conséquence, tels que des modifications de paramètres non autorisées ou le vidage du panier de l'utilisateur. D'autres fois, ils génèrent des problèmes bien plus importants: fuite d'informations utilisateur, XSS et même prises de compte en un clic.

Voici quelques cas que j'ai rencontrés dans la nature des CSRF entraînant de graves problèmes de sécurité. Souvent, il s’agit d’une combinaison de CSRF et d’autres défauts de conception mineurs.

CSRF critique n ° 1: Fuite d'informations d'utilisateur à l'aide de CSRF

CSRF provoque parfois des fuites d'informations en tant qu'effet secondaire. Les applications envoient ou divulguent souvent des informations en fonction des préférences de l'utilisateur. Si ces points de terminaison de paramétrage ne sont pas protégés contre les CSRF, ils peuvent ouvrir la voie à la divulgation d'informations sensibles. Un moyen de résoudre les fuites d’informations basées sur CSRF consiste à jouer avec ces demandes.

Par exemple, un service payant sur une application Web sur laquelle j'ai travaillé envoie des courriels de facturation mensuels à une adresse électronique désignée par l'utilisateur. Ces e-mails incluent les adresses, les numéros de téléphone et les informations de carte de crédit limitées de l'utilisateur. L'adresse e-mail à laquelle ces e-mails de facturation sont envoyés peut être modifiée via la requête suivante:

POST / change_billing_emailCORPS DE DEMANDE:email = NEW_EMAIL & csrftok = 12345

La validation de CSRF sur ce noeud final était cassée. Le serveur accepte un jeton vide et la demande aboutira même si le csrftok le champ est laissé vide. Une fois que la victime a envoyé la demande suivante, tous les e-mails de facturation ultérieurs seraient ensuite envoyés à ATTACKER_EMAIL (jusqu'à ce que la victime remarque le changement non autorisé), laissant ainsi l'adresse et les numéros de téléphone associés au compte associés à l'attaquant.

POST / change_billing_emailCORPS DE DEMANDE:email = ATTACKER_EMAIL & csrftok =

CSRF critique n ° 2: auto-XSS stocké à l'aide de CSRF

Self-XSS est presque toujours considéré par les équipes de sécurité comme un problème mineur, car il est difficile à exploiter. Cependant, lorsqu'il est associé à une CSRF, l'auto-XSS peut souvent être transformé en un XSS stocké.

Par exemple, sur un site financier que j'ai rencontré, les utilisateurs ont la possibilité de créer des pseudonymes pour chacun de leurs comptes bancaires liés. Le champ pseudo du compte est vulnérable à l'auto-XSS: il n'y a pas de nettoyage, de validation ni d'échappement pour l'entrée de l'utilisateur sur le champ. Cependant, il s'agit d'un champ que seul l'utilisateur autorisé peut éditer et voir, il n'y a donc aucun moyen pour un attaquant de déclencher directement le XSS.

Malheureusement, il existe également un bogue CSRF sur le système d'extrémité utilisé pour modifier les pseudonymes du compte. L'application ne valide pas correctement l'existence du jeton CSRF. Par conséquent, le fait d'omettre le paramètre de jeton dans la demande contournera la protection CSRF. Par exemple:

POST / change_account_nicknameCORPS DE DEMANDE:pseudo = & csrftok = WRONG_TOKEN

Cette demande échouerait.

POST / change_account_nicknameCORPS DE DEMANDE:pseudo =

Bien que cette demande permette de modifier le pseudonyme du compte de l’utilisateur et de stocker la charge XSS. La prochaine fois qu'un utilisateur se connectera au compte et consultera son tableau de bord, le système XSS sera déclenché.

Critique CSRF # 3: Reprise des comptes d'utilisateurs à l'aide de CSRF

Voici quelques-unes des reprises de compte les plus faciles que j'ai découvertes. Et ces situations ne sont pas rares non plus. Des problèmes de prise de contrôle de compte se produisent lorsqu'un problème de CSRF survient dans la validation d'un compte, comme la création d'un mot de passe, la modification du mot de passe, la modification de l'adresse de messagerie ou la réinitialisation du mot de passe.

Par exemple, voici un bogue que j’ai découvert dans l’application Web d’un client.

L'application Web permet les inscriptions sur les réseaux sociaux. Et après s'être inscrit via les médias sociaux, l'utilisateur peut définir un mot de passe via la requête suivante:

POST / password_changeCORPS DE DEMANDE:oldpassword = & newpassword = XXXXX & csrftok = 12345

Étant donné que l'utilisateur s'est inscrit via son compte de réseau social, aucun ancien mot de passe n'est nécessaire pour définir le nouveau mot de passe. Ainsi, si la protection CSRF échoue sur ce noeud final, un attaquant aurait la possibilité de définir un mot de passe pour toute personne qui se serait inscrite via son compte de média social sans mot de passe.

Et malheureusement, c’est exactement ce qui s’est passé sur ce terminal. L’application ne valide pas correctement le jeton CSRF et accepte une valeur vide en tant que csrftok paramètre. Donc, essentiellement, la requête suivante définira le mot de passe de quiconque (pour lequel aucun mot de passe n’a déjà été défini) sur ATTACKER_PASS.

POST / password_changeCORPS DE DEMANDE:oldpassword = & newpassword = ATTACKER_PASS & csrftok =

Il ne reste plus maintenant qu’à un attaquant d’intégrer cette requête aux pages fréquentées par les utilisateurs du site. Ce dernier peut alors attribuer automatiquement le mot de passe de tout utilisateur visitant ces pages à ATTACKER_PASS. Ensuite, l’attaquant est libre de se connecter en tant que victime avec son nouveau mot de passe.

Conclusion

Les CSRF sont super communs et très faciles à exploiter. Bien que la majorité des CSRF que j'ai rencontrés se soient révélés être des problèmes de faible gravité, une surveillance des paramètres critiques peut parfois avoir des conséquences graves.

Si vous êtes développeur, accordez une attention particulière aux mécanismes de protection CSRF déployés sur les ordinateurs d'extrémité critiques.

Si vous êtes un pirate informatique, réfléchissez au rôle que joue la fonctionnalité dans le contexte de toute l'application lorsque vous rencontrez un fichier CSRF. Comment le point final affecte-t-il le reste de l'application? Comment pourriez-vous augmenter la vulnérabilité sur la base de cette connaissance?

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close