web-dev-qa-db-fra.com

Comment un jeton CSRF empêche-t-il une attaque et comment puis-je l'utiliser / l'éviter en toute sécurité pour mon API JSON?

J'essaie de faire communiquer une application iOS avec un Ruby on Rails site Web utilisant JSON. Tout en essayant de publier une connexion pour créer une session utilisateur, je a découvert qu'il me manquait un jeton CSRF. Je ne savais pas du tout ce que c'est, alors j'ai commencé à l'examiner et j'ai trouvé des solutions qui disent de supprimer la protection CSRF si le format d'appel est 'application/json'. Mais cela semble comme ça laisse le site vulnérable?

Certains résultats sont apparus sur les formulaires JS ayant le même problème. Les réponses devaient être ajoutées dans le jeton CSRF. Ce qui, lors de l'inspection, semble également être dans la balise meta content dans les en-têtes de page.

Donc cela me laisse dans la confusion, voici mes questions:

  • Comment le jeton aide-t-il à protéger quoi que ce soit s'il peut être lu lors d'un appel préalable à l'appel attaquant? Un site malveillant ne peut-il pas simplement faire une demande, analyser le message reçu et envoyer une autre demande avec le jeton?
  • Serait-il sûr de désactiver la vérification du jeton sur l'action de post de connexion et de lui faire renvoyer le jeton avec la réponse de réussite? Sinon, de meilleures suggestions?
web-applicationauthenticationcsrfjson
21
Dan2552

Voici un résumé du fonctionnement des attaques CSRF:

  1. Vous, le bon utilisateur, lorsque vous êtes connecté à un site Web A, visitez la page B. d'un autre site.
  2. Cette page fait un GET (peut être un POST, un peu plus complexe à configurer) vers une page X sur le site A (auquel vous êtes connecté), avec par exemple . Votre navigateur oblige, en utilisant votre session/cookie déjà authentifié
  3. La page X de par sa conception entraîne un changement d'état de votre compte - les exemples classiques sont "transférer X dollars vers B" (moins réaliste) ou "définir la ligne d'état utilisateur sur PWNED" (plus réaliste)

Il existe un certain nombre de façons de mettre en œuvre un jeton CSRF, mais l'idée est qu'une simple demande GET à une URL à changement d'état X ne fonctionnera pas sauf si une information supplémentaire changeante (le jeton) est incluse, par ex. ce doit être "X? token = 123123213". Étant donné que le jeton change assez souvent, l'étape 2 ci-dessus ne fonctionnera pas. L'attaquant potentiel ne connaît pas le jeton actuel.

Votre question 1 - l'attaquant ne voit pas le contenu de la page X, il vous oblige seulement à la visiter.

Votre question 2 - puisqu'il s'agit uniquement d'actions lorsque vous êtes déjà connecté, il est plus ou moins correct de ne pas utiliser la protection CSRF sur la page de connexion. Il est possible que vous soyez obligé de vous connecter en tant que quelqu'un d'autre et que vous ne le remarquiez pas.

http://en.wikipedia.org/wiki/Cross-site_request_forgery

Une classe plus générale de problèmes est http://en.wikipedia.org/wiki/Confused_deputy_problem

22
Vitaly Osipov