Chapitre 23. Se défendre contre les attaques CSRF
Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : translation-feedback@oreilly.com
Dans la deuxième partie, nous avons construit des attaques de type Cross-Site Request Forgery (CSRF) qui profitent de la session authentifiée d'un utilisateur pour effectuer des requêtes en son nom. Nous avons construit des attaques CSRF avec des liens <a></a>, via des balises <img></img>, et même via HTTP POST en utilisant des formulaires Web. Nous avons vu à quel point les attaques de type CSRF sont efficaces et dangereuses pour une application, car elles fonctionnent à la fois à un niveau de privilège élevé et sont souvent indétectables par l'utilisateur authentifié.
Dans ce chapitre, nous apprendrons à défendre notre base de code contre de telles attaques, et à atténuer la probabilité que nos utilisateurs soient mis en danger par tout type d'attaque ciblant leur session authentifiée.
Vérification de l'en-tête
Tu te souviens de, les attaques CSRF que nous avons créées à l'aide de liens <a></a>? Dans cette discussion, les liens étaient distribués par courriel ou sur un autre site Web entièrement distinct de la cible.
Comme l'origine de nombreuses demandes CSRF est distincte de ton application Web, nous pouvons atténuer le risque d'attaques CSRF en vérifiant l'origine de la demande. Dans le monde du HTTP, il y a deux en-têtes qui nous intéressent lorsque nous vérifions l'origine d'une demande :