Protéger son service rest des CSRF

Bonjour,


Je développe actuellement un service rest (java/jersey/spring-security) avec un système de connexion (sessionid).

Les clients de ce service seront des clients légers (javascript/ajax), pas forcément sur le même domaine, donc requêtes cross-domain autorisées.

Je souhaite donc mettre en place un système de token afin d'empêcher les CSRF.

Ce que je compte faire, c'est transmettre ce token lors de la connexion de l'utilisateur (dans l'entête http). Ce token sera ensuite transmis du client au serveur à chaque requête du client afin de valider qu'il s'agit bien d'une requête initiée par la personne qui s'est connectée (en plus du ssid).


Est ce que cette approche vous semble sûre ?


Merci d'avance.

Hello,

je ne comprends pas quelle est la différence avec un ssid ?

A priori si le système est fait pour autoriser les cross-site request, mais que l'idée de CSRF existe quand même, c'est qu'il est possible que l'utilisateur, ne souhaite pas utiliser ton service même si un site qu'il visite le propose, ou qu'il ne souhaite pas que n'importe quel site ait les mêmes droits d'utiliser ton services en son nom que les autres sites.

Dans ce cas-là, l'idée serait de faire en sorte que l'utilisateur doive d'abord autoriser les sites tiers avant qu'ils puissent faire utiliser ton service. Une fois que cette autorisation est faire, ton site retient que cet utilisateur a autorisé ce domaine, et il n'y a plus qu'à vérifier le domaine d'origine des requêtes et si l'utilisateur a autorisé ce domaine.
Bref, un genre de OAuth simplifié grâce à l'aide des navigateurs.

Bonjour,

Merci pour ta réponse :-)

Le but de l'opération est de s'assurer que les requêtes de l'utilisateur sont bien désirées par celui ci.
Imaginons que celui ci se connecte un site malicieux qui lui fait exécuter des requêtes pour par exemple spammer les autres utilisateurs du site. Si la sécurité ne se base que sur le ssid, alors le site malveillant pourra envoyer des requêtes du type POST("message", "spam"). Si l'utilisateur s'est déjà authentifié au service, ses requêtes seront alors autorisées et il fera du spam sans s'en rendre compte.

Avec ce système, l'utilisateur se connecte avec le client prévu à cet effet, il entre son login/mdp, et le serveur lui renvoie son token. A chaque requête envoyée par le client, on transmet le token pour que les requêtes soient acceptées.
Si maintenant l'utilisateur se connecte au site malicieux, celui ci pourra toujours tenter d'envoyer du spam par csrf, mais comme il n'aura pas accès au token reçu par le client sûr, toutes ses requêtes seront rejetées.

Effectivement, c'est clair, merci :).

Moi ça m'ennuierait qu'un site A demande le login/mdp que j'utilise sur un site B. Qui nous prouve qu'il ne mémorise pas ce login/mdp ? Quels sont mes recours s'ils les donne, ou s'il donne le token, à quelqu'un d'autre ?

En fait non, ce n'est pas tout à fait ça :P

L'idée est plutôt que chaque utilisateur ait son propre client en local sur sa machine (même si c'est du léger). Donc que le client léger ait accès au mot de passe n'a pas vraiment d'importance.

Le truc, c'est que du coté du serveur on ne peut pas identifier les requêtes qui sont fiables de celles qui ne le sont pas à partir de l'adresse http à l'origine de la requête. Du coup on autorise toutes les requêtes, quelle qu’en soit la provenance. Si l'utilisateur utilise le client qui lui est fourni, pas de problème, il met son mdp, il fait ses requêtes.
Par contre, avec ssid, sa connexion reste active, et si après il décide d'aller sur boobs.com qui le redirige vers un site malveillant qui est capable de faire des csrf.

Donc :
1) L'utilisateur se sert du client pour se connecter au serveur rest
2) L'utilisateur fait tranquillement ses requêtes grâce au client
3) L'utilisateur se connecte à un site malveillant qui exploite le fait que l'utilisateur se soit déjà authentifié pour envoyer des requêtes en ajax (puisque serveur pas protégé contre requêtes cross-domain)

Avec le token ça donnerait :
1) utilisateur se sert du client pour se connecter au serveur rest, le serveur l'identifie et lui envoie un token aléatoire
2) L'utilisateur fait ses requêtes grâce au client, qui renvoie le token à chaque requête
3) Si l'utilisateur se connecte sur un site malveillant, celui-ci ne peut pas exploiter sa connexion parce qu'il n'a pas accès au token aléatoire.