CSRF est-il possible avec les méthodes PUT ou DELETE?

CSRF est-il possible avec les méthodes PUT ou DELETE? Ou l’utilisation de PUT ou DELETE empêche-t-elle CSRF?

Bonne question!

Dans un monde parfait, je ne peux pas imaginer un moyen d’effectuer une attaque CSRF.

  • Vous ne pouvez pas faire de requêtes PUT ou DELETE en utilisant des formulaires HTML.
  • Les images, les balises de script, les liens CSS, etc. envoient toutes des requêtes GET au serveur.
  • XmlHttpRequest et les plug-ins de navigateur tels que Flash / Silverlight / Applets bloquent les requêtes inter-domaines.

Donc, en général, il ne devrait pas être possible d’attaquer CSRF sur une ressource qui prend en charge les verbes PUT / DELETE.

Cela dit, le monde n’est pas parfait. Une telle attaque peut être possible de plusieurs manières:

  1. Les frameworks Web tels que Rails prennent en charge la “pseudo-méthode”. Si vous placez un champ masqué appelé _method , définissez sa valeur sur PUT ou DELETE, puis soumettez une requête GET ou POST, il remplacera le verbe HTTP. C’est un moyen de prendre en charge PUT ou DELETE à partir de formulaires de navigateur. Si vous utilisez un tel framework, vous devrez vous protéger de CSRF en utilisant des techniques standard

  2. Vous pouvez accidentellement configurer un en-tête de réponse laxiste pour CORS sur votre serveur. Cela permettrait aux sites Web arbitraires de faire des requêtes PUT et DELETE.

  3. À un moment donné, HTML5 avait prévu d’inclure la prise en charge de PUT et DELETE dans les formulaires HTML. Mais plus tard, ils ont retiré ce support. Il n’y a aucune garantie que cela ne sera pas ajouté plus tard. Certains navigateurs peuvent effectivement prendre en charge ces verbes, ce qui peut vous nuire.

  4. Il y a peut-être un bug dans un plug-in de navigateur qui pourrait permettre à l’attaquant de faire des requêtes PUT / DELETE.

En bref, je vous recommande de protéger vos ressources même si elles ne prennent en charge que les méthodes PUT et DELETE.

Non. L’utilisation d’un verbe HTTP n’est pas un moyen d’empêcher une attaque CSRF. Tout est dans la façon dont votre site est créé. Vous pouvez utiliser les PUT en tant que POST et DELETE en tant que GET – cela n’a pas vraiment d’importance.

Pour empêcher CSRF, suivez certaines des étapes décrites ici :

Les sites Web proposent différentes contre-mesures CSRF:

  • L’exigence d’un jeton secret spécifique à l’utilisateur dans toutes les soumissions de formulaires et les URL à effets secondaires empêche CSRF; le site de l’attaquant ne peut pas mettre le
    droit token dans ses soumissions 1
  • Exiger que le client fournisse des données d’authentification dans la même requête HTTP utilisée pour effectuer toute opération ayant des implications de sécurité (transfert d’argent, etc.)
  • Limiter la durée de vie des cookies de session Vérifier l’en-tête HTTP Referer ou (et)
  • Vérification de l’en-tête HTTP Origin [16]
  • S’assurer qu’il n’y a pas de fichier clientaccesspolicy.xml permettant un access non intentionnel aux contrôles Silverlight [17]
  • S’assurer qu’il n’y a pas de fichier crossdomain.xml permettant un access non intentionnel aux animations Flash [18]
  • Vérification que l’en-tête de la requête contient un X-Requested-With. Utilisé par Ruby on Rails (avant v2.0) et Django (avant v1.2.5). Cette protection a été prouvée non sécurisée [19] sous une combinaison de plug-ins de navigateur et de redirections qui peuvent permettre à un attaquant de fournir des en-têtes HTTP personnalisés sur une requête à n’importe quel site Web, permettant ainsi une demande falsifiée.

En théorie, cela ne devrait pas être possible car il n’y a aucun moyen d’initier une requête PUT ou DELETE interdomaine (sauf pour CORS, mais cela nécessite une demande de contrôle en amont et donc la coopération du site cible). En pratique, je ne me fierais pas à cela – de nombreux systèmes ont été mordus, par exemple en supposant qu’une attaque par téléchargement de fichier CSRF n’était pas possible (cela ne devrait pas être le cas, mais certains bogues de navigateur l’ont rendu possible).

Oui, CSRF est possible avec les méthodes PUT et DELETE, mais uniquement avec CORS activé avec une stratégie non ressortingctive.

Je ne suis pas d’accord avec la réponse de Sripathi Krishnan :

XmlHttpRequest et les plug-ins de navigateur tels que Flash / Silverlight / Applets bloqueront les requêtes inter-domaines

Rien n’empêche le navigateur de créer une requête interdomaine. La politique de même origine n’empêche pas une demande – tout ce qu’elle fait est d’empêcher que la requête soit lue par le navigateur.

Si le serveur n’accepte pas CORS , cela entraînera une demande de contrôle en amont. C’est le mécanisme qui empêchera l’utilisation de PUT ou DELETE, car il ne s’agit pas d’une requête simple (la méthode doit être HEAD, GET ou POST). En supposant une stratégie CORS correctement verrouillée (ou aucune stratégie sécurisée par défaut).

CSRF est en effet possible avec PUT et DELETE en fonction de la configuration de votre serveur.

La manière la plus simple de penser à CSRF consiste à envisager l’ouverture de deux tabs dans votre navigateur, l’un ouvert à votre application avec votre utilisateur authentifié et l’autre à un site Web malveillant.

Si le site Web malveillant envoie une requête javascript à votre application, le navigateur envoie les cookies standard avec la demande, permettant ainsi au site Web malveillant de “falsifier” la demande en utilisant la session déjà authentifiée. Ce site Web peut faire tout type de demande qu’il souhaite, y compris GET, PUT, POST, DELETE, etc.

La manière standard de se défendre contre la RFTS est d’envoyer quelque chose avec la demande que le site Web malveillant ne peut pas connaître. Cela peut être aussi simple que le contenu de l’un des cookies. Bien que la demande du site malveillant contienne les cookies, elle ne peut pas réellement accéder aux cookies car elle est desservie par un domaine différent et la sécurité du navigateur l’empêche d’accéder aux cookies pour un autre domaine.

Appelez le contenu du cookie un «jeton». Vous pouvez envoyer le jeton avec les demandes et sur le serveur, assurez-vous que le «jeton» a été correctement fourni avant de poursuivre la demande.

La question suivante est de savoir comment envoyer cette valeur avec toutes les différentes requêtes, avec DELETE particulièrement difficile car il n’est pas conçu pour avoir un type quelconque de charge utile. À mon avis, la méthode la plus propre consiste à spécifier un en-tête de requête avec le jeton. Quelque chose comme ce jeton x-security-token =. De cette façon, vous pouvez regarder les en-têtes des requêtes entrantes et rejeter celles qui ne contiennent pas le jeton.

Dans le passé, la sécurité standard ajax restreignait ce qui pouvait être fait via ajax sur le serveur malveillant. Cependant, la vulnérabilité dépend de la configuration de votre serveur par rapport aux configurations de contrôle d’accees. Certaines personnes ouvrent leur serveur pour faciliter les appels interdomaines ou pour permettre aux utilisateurs de créer leurs propres clients RESTful ou autres, mais cela facilite également l’utilisation d’un site malveillant, à moins que les méthodes de prévention CSRF mettre en place.