RSS
email
0

La faille CSRF

Voilà quelques temps que je n’ai pas posté d’article, j’ai donc décidé de revenir en force avec un lot d’article, expliquant diverses failles Web.

Qu’est ce que le CSRF ?
Commençons donc avec la faille CSRF, qui veut dire "Cross Site Request Forgery" est une classe d'attaques propre aux applications Web. Elle n’est pas fortement utilisée malgré les effets qu’elle peut avoir !

Cette faille résulte de la confiance qu’une application ou site web montre à l’égard de ses utilisateurs. En effet le but de cette faille est de faire envoyer une requête provenant d’un utilisateur authentifié, vers un site ou application.

Bon je m’explique car je me rends compte qu’avec un scénario, cela sera plus parlant…

Prenons Madame MICHU…enfin, vous m’avez compris quoi…
Madame MICHU consulte ses comptes en ligne sur le site de sa banque. Elle est donc authentifiée sur ce site, avec son ordinateur personnel, quasiment constamment. Utilisateur lambda oblige, Madame MICHU a enregistré son mot de passe au sein de son navigateur.

Grâce à un peu de social engeenering, un hacker X a appris que Madame MICHU consultait ses comptes en ligne sur le site de sa banque. Le Hacker étudie donc le fonctionnement des requêtes sur le site de sa banque, notamment les requêtes de virement d’un compte à un autre…

Une fois les requêtes bien cernées, il envoie un mail à Madame MICHU, avec un lien la renvoyant sur le site du Hacker. Celui-ci l’a bien entendu préparé au préalable !

Le Web Browser de Madame MICHU, une fois sur ce site va venir, comme tout bon Web Browser, interprété la page, les balises etc… C’est la que se trouve la faille…

En effet le hacker a placé une balise :

Le Web Browser cherchant l’image, va faire un GET de cette adresse, et comme Madame MICHU est authentifié sur le site de sa banque en ligne, va venir exécuter cette opération en temps que Madame MICHU, et cela silencieusement…

Le Hacker se retrouve donc avec une coquette sommes viré par Madame MICHU, sur son compte personnel, et cela sans que notre chère Madame MICHU s’en soit rendue compte…

Les solutions pour éviter cela, côté utilisateur :

La solution réside dans le fait d’empêcher le navigateur d’effectuer des requêtes sans votre autorisation préalable. Voici donc quelques petit conseil afin d’éviter les désagrément de cette attaque :

Ne pas sauvegarder ses identifiants et mot de passe dans les navigateurs !
En complément du conseil ci-dessus, il est déconseillé d’utiliser la fonction « remember me » proposée par de nombreux sites web.
Il est fortement déconseillé de cliquer sur les liens suspects ! Par liens suspects j’entends :
-un lien sur un site qui n’est pas digne de confiance
-un lien que vous recevez par mail, dont vous ne connaissez pas l’expéditeur, dont vous ne pouvez pas l’identifier formellement, qui n’était pas sensé vous envoyer de mail.
Je vous conseil de vous déconnecter dès que vous en avez terminé sur un site sensibles. Par site sensible, j’entends tout site ou vous disposez d’accès privilégié. Je rappel que tout est n’importe quoi peut attirer la convoitise d’un Hacker.
En dernier point, il est préférable d’utiliser un client mail qui n’interprète pas le code HTML.

Les solutions pour éviter cela, côté application :

Le referer
Ceux qui connaissent le protocole http, ou ceux qui utilisent Temper Data, auront sans doute pensé au referer, option qui permet d’identifier la provenance de la requête. Dans l’utilisation du referer, la requête doit provenir de la page précédente à la validation de la requête, et non du site du hacker, ou du client mail de Madame MICHU.

Le token secret
Une des méthode efficace consiste à utiliser des tokens aléatoires (d’où le fait qu’ils soient secret !) sur les pages sensibles. Le token doit être envoyé au serveur dans un champ caché (sinon il n’est plus secret…) lors de la soumission d’une requête sensible (envoie d’un formulaire, modification de mot de passe, commande, validation diverses…). De ce fait, si le serveur reçoit une requête ne contenant pas ce token (qui ne peut pas être prédit par l’attaquant !), il ne la traitera pas.

Double validation
Une autre possibilité consiste à obliger l’utilisateur à valider chacune de ses requêtes critiques par la soumission de son mot de passe. Celui-ci doit être impérativement saisie et ne peut être pré remplis par le navigateur. Le Hacker ne possédant pas le mot de passe de l’utilisateur, les actions critiques ne peuvent donc pas être exploitées (changement de mot de passe, suppression de compte, achat, transfert bancaire etc…).

Conclusion

Au premier abord, cette attaque peut sembler difficile à mettre en place. Détrompez-vous! Elle peut être mené de manière très simple, et ne nécessite pas de grande compétence technique.


Read more
 

Tags

Modules

over-blog.com

Wikio - Top des blogs - High-tech

VOTEZ POUR MON BLOG

News référencées par WebPlanete.net

Twitter