L'exposition du jeton de protection CSRF d'une session est-elle sécurisée?

Question

Django est livré avec le middleware de protection CSRF , qui génère un jeton unique par session à utiliser dans les formulaires. Il analyse toutes les POST requêtes entrantes pour trouver le bon jeton et rejette la demande si le jeton est manquant ou invalide.

Je voudrais utiliser AJAX pour certaines requêtes POST, mais lesdites requêtes ne disposent pas du jeton CSRF. Les pages ne contiennent pas <form> d'éléments et je préfère ne pas confondre le balisage en insérant le jeton en tant que valeur masquée. Je pense qu'un bon moyen de le faire consiste à exposer un élément comme /get-csrf-token/ pour renvoyer le jeton de l'utilisateur, en s'appuyant sur les règles de script intersite du navigateur pour empêcher les sites hostiles de le demander.

Est-ce une bonne idée? Existe-t-il de meilleurs moyens de se protéger contre les attaques CSRF tout en permettant les requêtes AJAX?

Answer 1

Si vous savez que vous allez avoir besoin du jeton CSRF pour les demandes AJAX, vous pouvez toujours l'intégrer quelque part dans le code HTML. alors vous pouvez le trouver via Javascript en parcourant le DOM. De cette façon, vous aurez toujours accès au jeton, mais vous ne l'exposerez pas via une API.

En d'autres termes, utilisez les modèles de Django et non le répartiteur d'URL. C'est beaucoup plus sécurisé de cette façon.

Answer 2

MISE À JOUR : la réponse ci-dessous était vraie et devrait l'être si tous les navigateurs et plug-ins étaient correctement implémentés. Malheureusement, nous savons maintenant qu'ils ne le sont pas et que certaines combinaisons de plug-ins de navigateur et de redirections peuvent permettre à un attaquant de fournir des en-têtes arbitraires lors d'une requête entre domaines. Malheureusement, cela signifie que même les requêtes AJAX avec & Quot; X-Requested-With: XMLHttpRequest & Quot; l'en-tête doit maintenant être protégé par CSRF. En conséquence, Django n'exempte plus les demandes Ajax de la protection CSRF .

Réponse originale

Il est à noter que la protection des requêtes AJAX à partir de CSRF n'est pas nécessaire, car les navigateurs n'autorisent pas les requêtes AJAX entre sites. En fait, le middleware Django CSRF exempte automatiquement les requêtes AJAX de l'analyse de jetons CSRF .

Ceci n'est valide que si vous vérifiez réellement l'en-tête côté serveur côté X-Requested-With pour " XMLHttpRequest " valeur (ce que fait Django) et exempte uniquement les requêtes AJAX réelles de l'analyse CSRF.

Answer 3

Annuler ça, je me suis trompé. (Voir les commentaires.) Vous pouvez empêcher l'exploit en vous assurant que votre JSON respecte la spécification: assurez-vous toujours de renvoyer un littéral d'objet en tant qu'objet de niveau supérieur. (Je ne peux pas garantir qu'il n'y aura pas d'autres exploits. Imaginez un navigateur donnant accès au code défaillant dans ses événements window.onerror!)

Vous ne pouvez pas vous fier aux règles de scriptage intersite pour préserver la confidentialité des réponses AJAX. Par exemple, si vous renvoyez le jeton CSRF sous forme JSON, un site malveillant pourrait . redéfinissez le constructeur String ou Array et demandez la ressource.

bigmattyh est correct: vous devez intégrer le jeton quelque part dans le balisage. Vous pouvez également rejeter les POST pour lesquels avoir un référent avec lequel ne correspond pas . De cette façon, seules les personnes avec des pare-feu logiciels trop zélés seront vulnérables à CSRF.