2009-05-23 18 views
7

Nous développons actuellement une application entièrement basée sur AJAX qui interagira avec le serveur via une API RESTful. J'ai examiné les schémas potentiels de protection contre les attaques XSRF contre l'API.Protection XSRF dans une application de style AJAX

  1. utilisateur authentifie et reçoit un cookie de session , qui est aussi double soumis à chaque demande.

  2. Nous mettons en œuvre un consommateur OAuth dans Javascript, récupérer un jeton lorsque l'utilisateur se connecte à et signer toutes les demandes avec ce jeton.

Je penche vers l'approche OAuth, principalement parce que je voudrais offrir un accès 3ème partie à notre API et je préfère ne pas avoir à mettre en œuvre deux systèmes d'authentification.

Y a-t-il une raison pour laquelle un consommateur OAuth ne fonctionnerait pas dans cette situation?

Répondre

0

La méthode la plus simple pour empêcher XSRF de vérifier le referer de chaque requête RESTful pour s'assurer que la requête provient du même domaine. Le cookie de session est important pour conserver l'état, mais il ne se défendra pas contre XSRF parce qu'il sera également envoyé avec une demande falsifiée. Il est commun de voir le système de protection XSRF basé sur le référentiel sur le matériel réseau intégré avec des exigences de mémoire limitées, Motorola utilise cette méthode sur la plupart de leur matériel. Ce n'est pas la protection XSRF la plus sûre, la protection basée sur les jetons est meilleure mais les deux systèmes peuvent encore être contournés avec XSS. Le plus gros problème avec la protection XSRF basée sur les jetons est qu'il faut beaucoup de temps pour revenir en arrière et corriger chaque requête et vous manquerez probablement quelques requêtes. Assurez-vous de lire le same origin policy et le scan your site for xss. Vous devriez également lire le Top 10 d'OWASP pour 2010 A3-Broken Authentication and Session Management.

4

La plupart des bibliothèques AJAX définissent un en-tête supplémentaire "X-Requested-With: XMLHttpRequest", ce qui est difficile à simuler dans une attaque XSRF de base (bien que possible si elle est combinée avec XSS). Vérifier que cet en-tête existe est une bonne stratégie de défense en profondeur si vous vous attendez à ce que toutes vos demandes soient AJAX.

1

Utilisez une requête en deux étapes, la première demandant au serveur un jeton imprévisible, la seconde demandant l'action réelle avec le jeton. Comme l'attaquant ne peut pas prédire le jeton et ne peut le lire (même règle d'origine), il ne peut pas donner un jeton valide dans la seconde requête.

Mais attention à ne pas fuir jetons (apprendre à capturer à l'aide JSON quand ils affectent la valeur à une variable globale et ainsi de suite) et lire:

http://www.google.com/search?q=xsrf+defence