« Faille CSRF » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 58 : | Ligne 58 : | ||
La façon la plus répandue étant l'utilisation d'un jeton unique qui sera vérifié à chaque modification. |
La façon la plus répandue étant l'utilisation d'un jeton unique qui sera vérifié à chaque modification. |
||
= Conclusion = |
|||
=Sources= |
=Sources= |
Version du 25 novembre 2018 à 14:12
Auteurs : Victor BASSET et Vincent PEILLEX
Introduction
Session
- Stocke l’état d’un client sur un site web
- Identification de la session avec des cookies
- Sessions sauvegardées côté serveur
- Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
- Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
- Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage
Faille CSRF
Attaque
La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu. Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.
Attaquer la victime en mettant la requête illégitime dans un mail :
Attaquer la victime en mettant lançant la requête depuis un site malveillant :
Optimisation
Risque
Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.
Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :
- opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;
- changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;
- changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).
Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.
Exemple
- The Netflix website in 2006 had numerous vulnerabilities to CSRF, which could have allowed an attacker to perform actions such as adding a DVD to the victim's rental queue, changing the shipping address on the account, or altering the victim's login credentials to fully compromise the account.
- The online banking web application of ING Direct was vulnerable to a CSRF attack that allowed illicit money transfers.
- Popular video website YouTube was also vulnerable to CSRF in 2008 and this allowed any attacker to perform nearly all actions of any user.
- McAfee was also vulnerable to CSRF and it allowed attackers to change their company system.
Protection
Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même.
Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.
La façon la plus répandue étant l'utilisation d'un jeton unique qui sera vérifié à chaque modification.
Conclusion
Sources
https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/
https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo
https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics