10
votes

Utilisation de la protection de la CSRF de Django sur des vues mis en cache de vernis

J'ai une vue Django avec un formulaire qui utilise la protection CSRF. Je veux que cette vue soit mise en cache de vernis lorsqu'il y a une demande d'obtention normale (puisque tous les utilisateurs ont besoin du même formulaire, pas de connexion).

Donc, il y a deux défis:

  1. Comment cacher cette page en vernis et non livré des versions mises en cache / anciennes du champ masqué CSRF à l'utilisateur? Est-il possible de cacher des pages de cache avec le champ CSRF?

  2. Mon vernis par défaut des bandes Toutes les cookies, comment pourrais-je facilement faire bande de tous les cookies, à l'exception du cookie CSRFTOK? Et dois-je définir un CSRF_COOKIE_DOMAINE spécifique?


0 commentaires

3 Réponses :


8
votes

Utilisation du CSRF sur une vue signifie essentiellement que chaque rendu de la vue est intrinsèquement différent (même si seule la valeur d'un champ caché change). La mise en cache ne fonctionne pas dans un tel scénario.

Cependant, Django fournit des mécanismes permettant de contourner cette limitation, à savoir les cookies, car vous semblez déjà avoir deviné. Donc, sur votre deuxième partie, il y a deux choses qui doivent être faites:

  1. Configurez Django pour envoyer des cookies CSRF au lieu d'utiliser le champ caché. (Voir: https://docs.djangoproject.com/fr / dev / ref / titt / CSRF / # S-cachefing )
  2. Faire du vernis ignorant le cookie django envoie. (Voir: http://www.varnish-cache.org/docs/ Trunk / tutoriel / cookies.html )

    Il vous suffit de définir csrf_cookie_domain dans Django si la demande provenait d'un domaine différent de celui de son traitement.


3 commentaires

Je voudrais un peu de clarification ce que vous voulez dire en 1) "Configurez Django pour envoyer des cookies CSRF au lieu d'utiliser le champ caché" - y a-t-il un moyen de faire cela? C'était ma compréhension que vous devez inclure la balise {% csrf_token%} sous toutes formes (ce qui crée le champ caché).


Je ne pense pas que cette solution soit viable. La protection de Django CSRF fonctionne en définissant un cookie et en vérifiant que sa valeur correspond à celle d'un champ caché. En d'autres termes, il a besoin d'un champ caché et de cookies pour faire varier pour chaque demande.


@Eli: Mais le vernis n'a besoin que d'un cookie pour varier.



1
votes

J'ai eu des problèmes similaires à l'aide de @csrf_protect et AJX, si quelqu'un utilise ce décorateur cela pourrait aider

ainsi que d'ajouter des exceptions au vernis. Assurez-vous que la vue avec la forme et la vue que les données sont affichées pour utiliser le décorateur.

i uniquement @csrf_protect sur la vue Post qui a fonctionné des tests fins localement, mais quand je suis allé vivre une émission de vérification de 403 échec de la vérification Ajout du tot de décorateur de la page Vue de la page corrigée Ceci


0 commentaires

9
votes

Ceci est quelques années de retard, mais voici comment je me suis vu autour de ce problème récemment.

L'astuce consiste à utiliser ESI , quel vernis soutient. Nous prenons l'extrait de CSRF et le collez-vous dans sa propre page, y compris via ESI lorsque vous traversez le vernis et directement autrement (comme lors de l'exécution du serveur de devir local). P>

CSRF_ESI.HTML: H3 >
<form action="">
    {% csrf_token_esi %}
    <button type="submit">Push me</button>
</form>


2 commentaires

Et qu'en est-il du cookie CSRF? Django vérifie à la fois le champ de formulaire caché du CSRF et le cookie CSRF. Cette solution ne résout que le problème avec le champ caché, n'est-ce pas?


@Srus +1, qu'en est-il du cookie CSRF? C'est le problème, pas l'entrée de champ cachée. Le vernis par défaut ne cache pas le jeton caché d'entrée!