HervéRenault.fr

Cross-Site Request Forgery, le danger en résumé

La cross-site request forgery est une faille de sécurité moins fréquente que le Cross-Site Scripting. Son nom est abrégé en CSRF ou parfois XSRF. Quelques références : Wikipedia et OWASP.

L'erreur est de permettre dans l'application web des actions telles que effacer des choses ou publier des choses sans vérifier au minimum le referer, ou mieux, un nonce, ou tout simplement en demandant une confirmation en JavaScript.

Imaginons qu'une extension de WordPress gère un type d'article particulier qui est publié sur le site site-avec-une-faille-csrf.fr. Imaginons qu'un agresseur ("pirate" ou "mauvais hackeur") repère que ce site utilise ce type d'extension avec une faille. L'agresseur va, par exemple, envoyer un mail à l'administrateur du site avec un lien trompeur qui pointe en réalité sur https://site-avec-une-faille-csrf.fr/wp-admin/admin.php?page=extension_bidule&action=effacer&id=tous

Si l'administrateur voit s'afficher une boite d'alerte JavaScript, évidemment il va bloquer l'action.

Sinon, c'est à l'application de vérifier que le referer n'est pas bon ou que le nonce n'est pas bon, et d'afficher que l'action a été bloquée.

Le nonce se trouvera normalement dans la page de l'extension qui propose un lien "Effacer tout", par exemple :
<a href="admin.php?page=extension_bidule&action=effacer&id=tous&nonce=<?php wp_create_nonce('mon-nonce') ?>">Effacer tout</a>
Et dans la page de l'extension qui effectue l'action, la vérification du nonce se fait par
if (wp_verify_nonce($_GET['nonce'], 'mon-nonce'))
(Le paramètre nonce peut porter n'importe quel autre nom)

Il y a aussi une fonction de WordPress nommée check_admin_referer

Pour en revenir à l'agresseur : il ne peut pas deviner un nonce et le passer en paramètre de son mail piégé, et il ne peut pas forcer le referer dans le navigateur de sa victime, donc ces mesures protègent l'utilisateur de l'application.