Yop,
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):
![[Image: SendMessage.php?message=XSS-from-jeuweb!]](http://haishin.fr/SendMessage.php?message=XSS-from-jeuweb!)
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).
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).
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!).
PS: ton pattern coté client est trop rigide, et n'autorise pas les espaces ni les ponctuations.
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).
Citation :les messages sont envoyé par formulaire GETDé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.
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):
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).
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).
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!).
PS: ton pattern coté client est trop rigide, et n'autorise pas les espaces ni les ponctuations.
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).