Bonjour à tous,

je viens vers vous afin de savoir quel type de protection vous mettez en place pour les scripts appelé en Ajax?

Des tokens, des sessions?

Merci de vos réponses.

hello

vérifier les données reçu surtout

mais c'est quoi ta problématique en faite ?

++

hello

vérifier les données reçu surtout

mais c'est quoi ta problématique en faite ?

++

Je veux sécurisé l'appel de mes scripts ajax...c'est à dire que si l'appel du script est fait par qq'un d'autre que mon appli, l'appel ne doit pas exécuter le script.

Un système de sessions avec des codes dedans devrait faire l'affaire. Moi par exemple j'avais un truc du genre

index.php
image.php

Une page Ajax n'est qu'une page comme une autre : il suffit de lui appliquer les mêmes règles que pour les autres pages de l'application.

L'idée de session est bonne. Moi en plus je "cache" l'accès de la page AJAX dans le flow des includes de ma page globale. Cela veut dire : je fais pointer ma page AJAX vers index.php et dans index.php je teste via POST ou GET (selon le mode que tu as choisi en fait) qu'elle page appelle l'AJAX et je fais un include_once de la page qui fera le traitement.

L'idée de session est bonne. Moi en plus je "cache" l'accès de la page AJAX dans le flow des includes de ma page globale. Cela veut dire : je fais pointer ma page AJAX vers index.php et dans index.php je teste via POST ou GET (selon le mode que tu as choisi en fait) qu'elle page appelle l'AJAX et je fais un include_once de la page qui fera le traitement.

t'as pas des risque qu'un petit malin te bombarde de requêtes cUrl et/ou analyse le comportement de tes requêtes, ou autres dans le but de trouver les variables (nom de la page à inclure) pour par la suite aller la chercher directement ?

perso, je considère les pages Ajax comme tout autre page, gérée avec un urlRewriting vérification des sécurité et autres sessions la seul différence entre une page ajax et une page dite "normale" c'est le template en charge de mettre les données en place et appeler les modules externes autonomes ... ainsi, si le gars viens directement, il a les données dans le design du site, et si il n'a pas les droits, il a la page d'accueil ou une 404 !
ça permet entre autre de stoquer +/- dans le template (ou autre) la liste des urls que le log JS va devoir charger en plaçant par exemple une classe sur les liens ou formulaires qui remplaceront le rechargement par une requete ajax pour les mettre (si className : popUp) dans une popUp ^^ ... c'est assez souple comme système ... et on reste dans un environnement de sessions donc c'est pas trop galère à sécuriser.

@+

Bonjour,

je souhaiterai que l'on ne puisse pas venir directement sur une page que j'appel avec AJAX mais je ne trouve pas, votre méthode avec session ne fonctionne pas.

Impossible, si on peut appeller via Ajax, on peut l'accèder autrement.

Concrétement, quelle est ta problèmatique ? Ce sont des données "sensibles" ?

c'est un tchat en ajax, les données sont appeler comme ceci:

ya index.php qui reçois les données de la page messages.php dans une div (<div id="tchat"></div>)

j'ai essayer de mettre le code de la page messages.php directement dans la balise div mais du coup ça me recharge un tchat à l'intérieur du tchat et pas moyen d'écrire un message

Bonsoir,

pour sécuriser un appel AJAX (ou tout autre appel d'ailleurs), rien de tel qu'un jeton d'authentification.
Voici un scénario :

1. authentification du client
2. un token unique et temporaire est généré coté serveur, transmis au client et stocké sur le serveur (<token>)
3. le client utilise ce token pour signer ses requêtes => création d'un hash concaténant ce token + la requête (ex: <token> + "GET /ma/ressource" = <mon hash> ; le MD5 est à bannir, privilégier SHA1 ou +)
4. envoi de la requête du client avec le hash (ex: GET /ma/ressource?hash=<mon hash>&user=<mon user>)
5. le serveur reçoit la requête et l'authentifie grâce au hash recalculé avec le user et le token temporaire.
6. le serveur sert la réponse ou rejette la requête (et archive les erreurs, prévient des admins, etc.)

A+

Merci mais le token est il fixe ou généré un nouveau à chaque rechargement de la page ?

car si il est fixe on à juste à faire un appel de la page comme tu la préciser (ex: GET /ma/ressource?hash=<mon hash>&user=<mon user>)

Ah bah non il est régénéré à chaque chargement de page. Sinon aucun intérêt de le stocker en session puisqu'on pourrait le mettre en dur.

D'accord mais comment le généré à chaque fois et vérifier que c'est le bon ?

Merci mais le token est il fixe ou généré un nouveau à chaque rechargement de la page ?

car si il est fixe on à juste à faire un appel de la page comme tu la préciser (ex: GET /ma/ressource?hash=<mon hash>&user=<mon user>)

Dans mon scénario, il est fixe. Ce que le client transmet dans la requête ci dessus ce n'est pas directement le token mais le hash calculé en fonction du token (dans mon exemple, le hash est calculé en concaténant le token + la requête URI, sans les paramètres GET).

Les jetons générés à chaque utilisation/validation de formulaire utilise un principe similaire, sauf que le jeton à une durée de vie courte (quelques minutes) et que le jeton est transmis tel quel (pas de hash). Il sont généralement utilisés pour contrer le CSRF.