[AJAX] Sécurité de la transmission des données

[php_addict]

C'est le principe des jetons d'accès, et c'est ce qui devrait être utilisé pour toute action.

ca c'est encore un principe que je n'ai pas tout à fais compris...

[Sephi-Chan]

Cela devrait être fait pour toutes les requêtes d'actions (donc les méthodes HTTP Post, Put et Delete).

A chaque fois que le serveur rend une page, tu lui fais générer une chaîne aléatoire : ce sera ton jeton (token).
Tu stockes cette chaîne dans la session du visiteur et tu l'envoie dans les requêtes d'actions (grâce à un champ caché).
Sur la page de traitement, tu compares le jeton en session à celui transmis dans la requête.

Ainsi, ça te garantit que l'utilisateur est passé par le formulaire (et qu'il n'a pas cliqué sur un lien). C'est une contremesure courante aux attaques CSRF.

Exemple : si je sais que tu es administrateur du site Lambda, je t'envoie un lien (TinyURL par exemple) qui t'envoie sur lambda.tld/admin/delete_user.php?id=23. Hop j'ai gagné, tu as supprimé l'utilisateur 23 toi même ! Ça implique de deviner certaines choses, mais quand tu sécurises, il faut penser que rien n'est secret et faire un test dit full knowledge.

Ensuite, quand on utilise Ajax, il faut transmettre ce token à Javascript. Pour cela, il y a plusieurs moyens. Une variable Javascript globale, mais c'est crade. Le plus propre reste à mon sens de s'inspirer Rails 3 et de déclarer une balise méta :

<meta name="csrf-token" content="ton_token" />

<meta name="csrf-param" content="authenticity_token" />

Ainsi, dans tes requêtes Ajax, tu as juste à récupérer le couple (nom du paramètre; token) et l'injecter dans ta requête. C'est trivial et propre.

Enfin, comme toujours (vraiment toujours), de bons développeurs ont déjà pensé à ça avant vous et ont mis au point des solutions propres et sûres. Encore du temps gagné à utiliser un bon framework, où tout cela se fait automatiquement.


Sephi-Chan

[php_addict]

merci...

Cela devrait être fait pour toutes les requêtes d'actions (donc les méthodes HTTP Post, Put et Delete).

Exemple : si je sais que tu es administrateur du site Lambda, je t'envoie un lien (TinyURL par exemple) qui t'envoie sur lambda.tld/admin/delete_user.php?id=23. Hop j'ai gagné, tu as supprimé l'utilisateur 23 toi même ! Ça implique de deviner certaines choses, mais quand tu sécurises, il faut penser que rien n'est secret et faire un test dit full knowledge.

ok, ca y est j'ai compris...

donc pour tout les HTTP Post, Put et Delete on met un jeton (<input type="hidden" value="sdf654sdf6499"> )

Mais l'exemple que tu donne est un _GET, et là je vois pas comment mettre un jeton...

Enfin, comme toujours (vraiment toujours), de bons développeurs ont déjà pensé à ça avant vous et ont mis au point des solutions propres et sûres. Encore du temps gagné à utiliser un bon framework, où tout cela se fait automatiquement.

merci de me le rappeler mais vu l'etat d'avancement de mon projet, je vais avoir du mal à le passer sous un framework...

[Sephi-Chan]

L'exemple est un GET car c'est ce que font la plupart des gens (car ils n'utilisent pas d'architecture REST et/ou qu'ils n'ont pas les bons outils pour le faire).

Et avec GET ça ne change rien, mais dans un monde parfait, aucune action qui modifie la base ne doit être effectuée par la méthode GET, c'est pas fait pour ça. Si tu le fais quand même, il suffit d'ajouter le token à la query string, tu auras un lien de la forme : lambda.tld/admin/delete_user.php?id=23& authenticity_token=ton_token.


Sephi-Chan

[Aleskweb]

Je comprends pas pourquoi tu dis qu'aucune action qui modifie la base ne doit être effectuée par la méthode GET.
Tu veu dire par la:
-Un insert ou update avec direct le Get (completement débile bien sur)
-Ou meme ayant passé par une vérification c'est pas bien (J'ai un système de deplacement fonctionant par get, je vérifie si les points de mouvement sont ok et ensuite je déplace. Après si il préfére se deplacer en modifiant les get c'est son choix >< Mais il pourra pas aller plus loin que d'habitude)

[Sephi-Chan]

Quand je dis c'est pas bien, c'est purement d'un point de vue architecture logicielle : HTTP nous donne des outils (les méthodes GET, PUT, DELETE, POST, etc.) qu'il convient d'utiliser pour ce pourquoi ils sont fait.

Concernant ton exemple de carte : tu utilises des paramètres GET pour définir la viewbox (la zone visible par l'utilisateur), donc GET convient puisque les paramètres ne servent qu'à l'affichage d'une carte (aucune modification des données).

Par contre, quand le personnage se déplace, ça devrait être au moyen d'une requête POST (ou PUT, si elle envoie directement les nouveaux coordonnées du personnages).

Dans certains cas, respecter une telle architecture peut se révéler contraignante, c'est pourquoi je ne pense pas utile de le faire si vous n'utilisez pas les outils qui gèrent ça. Ça va plus vous embêter qu'autre chose.


Sephi-Chan