Citation :Déjà, problème car GET est prévu pour récupérer une ressource et non pour en créer une (et GET est idempotente). En d'autres mots, si je fais une requête GET, rien ne change coté serveur. Si je fais 1x ou 100x une requête GET, j'ai le même résultat. Donc, dans ton cas, passe par un POST et non un GET.
D'accord je vais modifier cela, c'est vrai que ça me paraît plus logique maintenant d'utiliser POST que GET
Citation :Par exemple, cette "image" te fait envoyer un message, ce qui est complètement anormal (bon, même en POST, on peut faire pareil, mais c'est un peu plus délicat, c'est juste pour la démo):Oui j'ai vu tes tests, je compte passer en POST et limiter le nombre de message par joueur sur un laps de temps (à déterminer)
Citation :D'ailleurs, t'as un pâté dans tes redirections... L'URL http://haishin.fr/SendMessage.php?message=Looping! doit rediriger vers elle-même, ce qui envoie du message en boucle (jusqu'à ce que le navigateur détecte la boucle et stoppe le train).Je vais regarder et essayer de comprendre pourquoi ça boucle :/ (même si j'imagine qu'en POST, ce problème n'existeras plus...)
Citation :Sinon, tu peux avoir une injection SQL si ta requête est simplement une concaténation avec les données du POST. Si tu passes par une requête préparée (INSERT INTO ... (...) VALUES (?, ?, ?...)) alors tu ne devrais pas avoir de soucis.
Quand tu envoie les données au client, tu peux avoir une injection aussi (qu'on appelle XSS). Si tu envoies les données au client sous forme HTML en faisant une bête concaténation de chaine ou un bête "echo" (<ul><li><?php echo $myData; ?></li></ul> ou <?php echo '<ul><li>' . $myData . '</li></ul>';?> qui revient au même) alors tu envoies une chaine de caractère au client, qui n'a pas moyen de savoir comment elle a été construire. Du coup, si du code HTML se ballade dans MyData, il sera interprété par le client (XSS). Cela se règle en l'échappant lors de l'envoie des données (<li><?php echo htmlentities($myData); ?></li>, en précisant quand même l'encodage, cf doc). Même principe pour du JSON (avec json_encode()). Même principe pour une sortie XML (avec DomDocument ou SimpleXML). Même principe avec du CSV (là, je ne sais pas comment on échappe ses données).
Merci pour ces explications !
je comprend mieux maintenant pour le premier cas.Pour le second cas, je ne comprennais pas trop, jusqu'à ce que je vois ton exemple (test barré dans la discussion
)Je comprend maintenant l'effet que ça peux avoir et vais corriger ça (cf:htmlentities)
Citation :Pour le reste, ce que MySQL te retourne ne sont que des données, donc si la donnée dans la table est litéralement "DROP DATABASE..." alors MySQL va juste te retourner la chaine de texte "DROP DATABASE..." (il ne l'exécute pas, pourquoi le ferait-il?!). En revanche, tu aurais de gros emm***des si tu re-exécutais ce que MySQL t'as envoyé (façon while ($row = mysql_fetch_assoc($r)) { mysql_query($row); } mais je ne vois pas pourquoi tu aurais à faire cela!).
Je vois, donc si on récupére un varchar par exemple (avec une requête dedans) au moment de l'afficher sur la page, le serveur ne vas pas l'executer puisqu'il ne fait que l'afficher, idem au niveau de l'envoie car j'ai une requête préparée et non pas juste un SELECT..... FROM ...... where A=$variable; <- Dans ce cas, une injection est possible. J'ai bien compris ?
Merci pour ton aide
Citation :PS: ton pattern coté client est trop rigide, et n'autorise pas les espaces ni les ponctuations.Oupssss :/ je n'ai pas testé ça, je vais corriger
Citation :PSS: Si j'appelle la page http://haishin.fr/SendMessage.php sans paramètre et en étant connecté, alors une erreur SQL intervient: tu n'as pas vérifié que le message existe (et est non vide par exemple).Effectivement, j'ai ajouté un check sur la connection (sinon redirection vers login.php) mais je n'ai pas vérifier ça :/ j'ajoute à ma todo list
EDIT: Je dois aussi modifier l'heure du serveur :/