Journal du Net > Développeurs > Contributions > Votre astuce Ajax / JavaScript ?

APPEL
A CONTRIBUTION

Vous manipulez le langage JavaScript au quotidien pour concevoir des pages Web ? Vous avez certainement une astuce à partager ! Cet espace est pour vous.
Participez
 Sécurité des requêtes Ajax  
Sébastien Brémond , Seynod (haute-Savoie)

Sécurité des requêtes Ajax
Sébastien Brémond
Quel est en 3 lignes l'objectif de votre astuce ?
Sécuriser ses requêtes en Ajax afin de préserver l'intégrité du modèle (forme / contenu) et de contrer le vol et l'infiltration de ses données.

Décrivez votre astuce en détail. N'hésitez-pas à inclure des portions de codes.
Dans un premier temps utiliser les sessions serveur en fonction de la plate-forme (PHP / JAVA / ...).

La page servie qui s'affiche au client doit coté serveur générer un clef (alphanumérique par ex. de 10 à 20 caractères)
Affecter cette clef à une variable de l'espace de session:
$_SESSION['Env_UserSession']['AjaxKey'] = $la_clef_alphanum

Phase 2.
Coté client, la clef devra être disponible via javascript. Elle pourra être une valeur d'un champ caché par exemple. (Le script serveur devra l'écrire dans le champ ou l'affecter à une variable javascript)

Phase 3
Lors de la requête Ajax, récupérer cette clef et la transmettre aux paramètres Ajax (aux arguments paires de la requête en réalité)

Phase 4
Lorsque la requête est lancée, le principe est de contrôler coté serveur l'existence de cette clef, et la vérifier avec celle stocké en session.
Celle-ci doit être contrôler avant de servir (générer) le contenu Ajax au client.

Pour aller encore plus loin, je propose de générer un champ input de type hidden (en Phase 2)
Ce champs aura pour nom (attribut name) le hachage en md5 de la clef. La valeur de champs pourra être ce que vous désirer !

Lors du contrôle coté serveur (Phase 4) contrôler bien l'existence POST ou GET d'un argument dont la variable correspond au md5 de la clef stockée en session. (S’assurer bien sûr qu'elle existe sinon c'est qu'elle est vide, donc une tentative de contournement ou de vol en est la cause...)

Si c'est le cas et qu'elles sont identiques, vous pouvez à ce moment livrer votre contenu ou le générer.

Votre requête est donc à présent sécurisée. Je vous laisse le soin d'étudier les échanges serveur / client afin d'optimiser cette astuce ;)


Publié le 07 février 2008

Raphael Robin
J'irai encore plus loin que Laurent : si on utilise les sessions, pourquoi utiliser une clé partagée en plus ? Si un attaquant récupère l'identifiant de session, il n'aura aucun mal à récupérer cette clé !
Jaja
Tout ça ne sert à rien. Il suffit à l'attaquant de récupérer le contenu du champ caché et de le passer dans sa requête AJAX
Gregory
J'utilise ce genre de technique,cependant je ne suis pas certain que le hash seul de la session serveur augmente le niveau de sécurité. Dans tous les cas d'échange de données client-serveur, la règle reste la même : Ne jamais faire confiance aux données du client et toujours contrôler côté serveur l'intégrité des données (ajax ou pas ajax d'ailleurs).

J'aurais tendance à dire que le plus simple serait de sécuriser le transport des données par ssl d'une part pour limiter les possibilités d'attaques de type man in the middle,et d'autre part,peut-être transmettre un jeton crypté à la volée (à partir de la session) à l'aide d'un cryptage à usage unique valide quelques minutes (cf le mécanisme OTP),initié par le serveur lors de la demande de la page principale
Sébastien
Le fait de générer un md5 (ou tout autre encodage) permet de contrôler l'authenticité du nom du champ transmis.
En effet le champ caché peut avoir un attribut name de n'importe quel nom.
Cela évite de générer un champ dont l'attribut name est unique, et facilement repérable par la suite par les moteurs de spam et autres grignoteurs de données.

Si le nom change à chaque accès, il est quasiment impossible de "repérer" un tel champ au sein d'une page
Laurent Dinclaux
Je ne vois pas pourquoi faire un md5 sur la clef... De toute façon si elle est interceptée et retransmise, c'est la version md5 qui sera retransmise et vérifiée pas le serveur et donc elle sera acceptée.

Mais cette approche est intéressante et indispensable pour le requête ajax qui ont pour but de modifier des donnée (ex: soumission de formulaires), elle évite les attaques de type CSRF (http://fr.Wikipedia.Org/wiki/Cross-Site_Request_Forgeries)
11 contributions : 1 2 3 4 5 6 7 8 9 10 11
 




 

© Benchmark Group, 69-71 avenue Pierre Grenier 92517 BOULOGNE BILLANCOURT Cedex

RECHERCHER