Des trous de boucle logique dans cette idée pour empêcher Cross Site Request Forgery?

Question

J'ai lu plusieurs solutions XSRF qui reposent sur l'ajout de plus de jetons à la réponse, ce qui aide à protéger le code qui s'exécute uniquement sur POST.

-à-dire que ce serait une attaque d'une étape reposant sur une page qui répond à HTTP GET

<img src="http://amazon.com/buybook/anarchistscookbook/mailto/me/execute.php"> 

Mais avec de meilleures bibliothèques comme jquery, ça devient plus facile d'écrire des scripts XMLHttpRequest javascript malicieux, qui peut faire deux étape d'attaque (un GET, analyser l'anti-XSRF viewstate/chaîne de requête/cookie supplémentaire etc), puis soumettre un POST. (Ou est-ce que je ne crains pas que AES soit craqué de sitôt, devrais-je même m'inquiéter des attaques XSRF en 2 étapes ciblant les actions HTTP POST devenant aussi faciles que l'attaque par tag img montrée ci-dessus?)

Je suppose l'attaque en une étape peut être tranférée en ne faisant rien de sensible sur GET, les deux types d'attaques peuvent être partagées en demandant à l'utilisateur du site de résoudre un CAPTCHA, qui génère alors un jeton de chaîne de requête qui serait requis pour toutes les URL de la session? Jusqu'à présent, il semble que cela échouerait seulement lorsque CAPTCHA échoue, comme si le logiciel OCR pouvait lire le texte ou s'il y avait un composant mécanique turc.

EDIT: L'attaque particulière à l'esprit est un e-mail avec xhr javascript ou tag d'image. Le code serait donc exécuté dans le navigateur du client de messagerie ou à partir d'une page HTML chargée depuis le système de fichiers local. Pour des raisons de simplicité, j'imagine que le site n'a pas de vulnérabilités XSS (c'est-à-dire aucune possibilité pour les utilisateurs malveillants d'injecter leur code HTML dans le HTML que le site envoie comme réponses)

Answer 1

Le point est que JavaScript ne peut pas lire l'anti -XSRF d'un contexte inter-domaine, et XMLHTTPRequest est de même origine seulement, donc il ne peut pas être utilisé pour voler le jeton.

Si votre site a déjà une vulnérabilité XSS, vous êtes déjà arrosé, et les jetons anti-XSRF ne vous aideront pas.

Answer 2

Ni XmlHttpRequests ni manipulation de trame javascript ne fonctionnent actuellement entre domaines; ce serait de la folie pure. Les attaques CSRF ces jours-ci se composent généralement soit de la balise image comme vous l'avez mentionné ou générant automatiquement un formulaire qui POST à ​​un autre site. Cependant, récupérer un jeton anti-XSRF (vraisemblablement un nonce cryptographique généré sur une base par session) est presque impossible. Ce n'est que s'il s'agit d'un jeton extrêmement pauvre qui ne vérifie pas la session utilisateur et l'adresse IP qu'un langage côté serveur peut être utilisé pour le récupérer et ensuite le combiner avec un CSRF côté client. Mis à part les jetons, beaucoup de gens arrêtent CSRF simplement en vérifiant les référents et en bloquant tous les domaines distants. L'envoi de CSRF avec XmlHttpRequests est pratiquement impossible grâce aux restrictions de domaine. Quoi qu'il en soit, vous n'avez pas à vous soucier que XmlHttpRequest puisse accéder à un domaine distant. La seule fois où quelque chose comme ça pourrait arriver, c'est si vous avez une vulnérabilité XSS, auquel cas, comme l'a dit EricLaw, vous êtes déjà arrosé.

Answer 3

Je pense que vous êtes confus au sujet de la politique de même origine. Demander une page HTML dans un fichier local ne contourne pas cette politique. En fait, je crois que des règles encore plus strictes s'appliquent à une ressource de fichier. Vous trouverez que Javascript dans un fichier html local pas être en mesure de faire une demande avec succès pour récupérer une ressource non-locale.

Les navigateurs modernes ne permettent pas Javascript dans l'accès des fichiers HTML local à distance les ressources HTTP.

Dans quel navigateur avez-vous réussi à effectuer un XHR interdomaine à partir d'un fichier: /// resource? J'ai testé ceci dans ie6, ie7, ie8, firefox 3, firefox 3.5 et les versions récentes de chrome, d'opéra et de safari sur windows; ils rejettent tous la requête http inter-domaine.

<html> 
<head> 
<script 
    type="text/javascript" 
    src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script> 
<script type="text/javascript"> 
    $(document).ready(function() { 
    $('#xhr').append('replace me with remote xhr'); 
    $('#xhr').load('http://stackoverflow.com/', function() { 
     $('#xhr').append('xhr load complete');   
    }); 
    }); 
</script> 
</head> 
<body> 
    test 
    <div id="xhr">original</div> 
</body> 
</html> 

Il est possible que certains navigateurs beaucoup plus anciens soient moins restrictifs.