mysql_real_escape_string et compagnie

Bonjour,

Voila, j'ai un formulaire avec un champ 'gamename'.
Le formulaire envoi a une page de vérification 'verifFormulaire.php'.
Dans cette page, je récupère le nom du membre avec :

Code:

---

1 2	$_SESSION['gamename'] = mysql_real_escape_string(htmlentities($_POST['gamename']))

---

Ensuite, je vérifie si la valeur de $_SESSION['gamename'] est dans la base via :

Code:

---

...`gamName` LIKE '%".$_SESSION['gamename']."%'...

---

et je récupère la liste des jeux.

En haut de cette liste j'affiche :

Code:

---

echo 'Jeux contenant : '.stripslashes($_SESSION['gamename']);

---

Et éventuellement, je remet le texte entrer en valeur par défaut

Code:

---

1 2	echo '<input type="text" name ="gamename'" value=" '.stripslashes($_SESSION['gamename']).' ">

---

Si j'entre un ' dans le champ 'gamename', j'obtient bien la liste des jeux contenant ' dans le nom, et cela affiche Jeux contenant " ' ".

si j'entre : <a href="nonSite">test</a>, j'obtient aucun jeux donc c'est normal, et cela affiche Jeux contenant "<a href="nonSite">test</a>"


Donc
1) Suis-je bien protéger de cette façon contre les injonctions sql ?
2) Faut-il protéger l'envoi de donnée via une liste déroulante pré-rempli, il me semble que non, mais...
3) la fonction addslash dans tout ça, elle sert a quoi ? sachant que tout les champs texte des formulaires sont nécessairement lié a une base de donnée dans mon cas.

Merci,

Tu ne devrais pas utiliser les fonctions htmlentities avant d'inserer les données dans ta base.
Pas pour une question de sécurité mais pour une question de données.
En effet il n'y a pas de raison que le nom de ton jeu soit présent sous une forme HTML dans la base.
C'est ensuite au moment de l'affichage que tu le convertis :

Code:

---

echo 'Jeux contenant : '.htmlentities($_POST['gamename']);

---

Tu peux egalement utiliser strip_tags() pour nettoyer un peu ta chaine.

Utilise effectivement mysql_real_escape_string() pour placer des variables externes dans une requete.

Code:

---

LIKE '%".mysql_real_escape_string($_POST['gamename'])."%'...

---

Pour ton stripslashes() il ne devrait pas être nécessaire ; si tu as des problemes d'antislash dans ta base de donnée c'est plutot au niveau de l'insertion qu'il faut le résoudre.

Bonjour à nouveau,

j'ai changer pas mal de truc dans mes requête etc, et voila ou j'en suit pour par exemple une requête insert.

Code:

---

1 2 3 4 5 6 7 8 9 10

$query = " INSERT INTO `user` (`useName`, `useEmail`, `usePassword`, `useLocalisation`, `useFuseau`, `useInscription`, `useMAJ`) VALUES ('".utf8_encode(mysql_real_escape_string($_SESSION['userFourni']))."', '".utf8_encode(mysql_real_escape_string($_SESSION['emailFourni']))."', '".utf8_encode(mysql_real_escape_string($hashPassword))."', '".utf8_encode(mysql_real_escape_string($_SESSION['localisationFourni']))."', '".utf8_encode(mysql_real_escape_string($_SESSION['fuseauFourni']))."', '".$quand."', '".$quand."')";

---

avec ce code, si $_SESSION['userFourni'] = " <p'o"i/u\t"> "
la chaine <p'o"i/u\t"> s'inscrit bien dans la base sql.

Pour la connection a l'espace membre par exemple, si j'entre <p'o"i/u\t"> dans le champ du formulaire, et que je le récupère ensuite

Code:

---

1 2 3 4 5 6

$query =" SELECT * FROM `user` WHERE `useName` LIKE '".mysql_real_escape_string(addslashes($login))."' AND `usePassword` LIKE '".mysql_real_escape_string(md5($password))."' ";

---

tout fonctionne bien, j'entre bien dans la section membre.

Je trouve un peu étrange de devoir faire un addslashes($login) avant de faire le mysql_real_escape_string, vous faite comme ça pour gérer les anti-slashs ?

Finalement ça fait plein de fonction dans une requête sql, c'est pas super joli ;)

Citation:

---

Je trouve un peu étrange de devoir faire un addslashes($login)

---

pourquoi le fais-tu ?

Pareil pour le utf8_encode, tu ferrais mieux d'harmoniser tes encodages.

D'abord merci pour ton aide,

Pour le addslash :
Si un $login du genre est dans la bd: <p'o"i/u\t">. C'est exagérer mais c'est pour tester ;)

et la récupération avec le post['login'] n'affiche rien

Code:

---

1 2 3 4

$login = $_POST['login']; echo $login; //affiche rien echo mysql_real_escape_string($login); //affiche rien

---

donc je n'est pas trouver la façon de passer un $login avec un \ via un $_post, pour exécuter un SELECT.

Par contre, étrangement ce code exécute bien le SELECT et retourne les bon résultats.

Code:

---

1 2 3 4 5 6

$query =" SELECT * FROM `user` WHERE `useName` LIKE '".mysql_real_escape_string(addslashes($login))."' AND `usePassword` LIKE '".mysql_real_escape_string(md5($password))."' ";

---

Pour l'encodage,

chaque champ texte dans la base de donnée est en utf8_unicode_ci.
j'ai aussi dans mes script php

Code:

---

1 2 3 4

$bdd = mysql_connect("localhost","root","blablabla") or die(mysql_error()); mysql_query("SET NAMES 'utf8'"); mysql_select_db("nombase",$bdd) or die(mysql_error());

---

et dans les métas

Code:

---

1 2	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" >

---

sans le utf8_encode j'avais des caractère bizarre dans ma table, notamment des 㨠machin a la place de ô.

pourtant, ça me semble du utf-8 partout non ?

dans ta chaine <p'o"i/u\t"> c'est le < qui fait que rien ne s'affiche puisque le navigateur le considere comme un début de tag html.

Vois bien que addslashes() et mysql_real_escape_string() font a peu pres la meme chose.
Toi tu n'as pas besoin de addslashes.
Si tu dois afficher une chaine avec des < ou des guillemets, il faut utiliser htmlspecialchars().

Pour tes problemes d'encodage, lance la requete "SET NAMES 'UTF8'" au début de ton code et enleve tes utf8_encode, ca devrait marcher.

Bonjour, pour l'encodage c'est bon, plus besoin de utf8_decode.

Je me demandais pour htmlentities, par défaut c'est ISO-8859-1, donc je doit spécifié chaque fois, htmlentities($_POST['login'],ENT_QUOTES,'UTF-8');

il y a moyen de mettre le utf-8 par défaut ? via .htaccess peut être ? remarque je ne sais pas si ovh autorise ou pas.

Par pour la requete SELECT, ca ne fonctionne toujours pas.
Voici un bout de code avec un formulaire de test etc..

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

<?php header('Content-type: text/html; charset=UTF-8'); ob_start("ob_gzhandler"); session_start() ; $bdd = mysql_connect("localhost","root","****") or die(mysql_error()); mysql_query("SET NAMES 'utf8'"); mysql_select_db("gem",$bdd) or die(mysql_error());   echo ' <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> ... <meta http-equiv="Content-Type" content="text/html; charset=utf-8" > .... <title>blablatest</title> </head> <body class="thrColLiqHdr">'; if (isset($_POST['login'])) { echo "_POST['login'] Rempli : <br>";   $a = $_POST['login']; echo "Post['login'] = ".$a." <br>";   $query = "INSERT INTO `user` (`useName`) VALUES ('".mysql_real_escape_string($_POST['login'])."')"; echo $query."<br>"; mysql_query($query) or die(mysql_error());   $rechUser = "SELECT `useName` FROM `user` WHERE `useName` LIKE '".mysql_real_escape_string($a)."'"; echo "Requete Sans ADDSLASHES() : <br><br>"; $resultUser = mysql_query($rechUser,$bdd); if (mysql_numrows($resultUser)>0) echo "Trouver dans la base<br>"; else echo "Pas Trouver dans la base<br>";     $rechUser = "SELECT `useName` FROM `user` WHERE `useName` LIKE '".mysql_real_escape_string(addslashes($a))."'"; echo "Requete Avec ADDSLASHES() : <br><br>"; $resultUser = mysql_query($rechUser,$bdd); if (mysql_numrows($resultUser)>0) echo "Trouver dans la base<br>"; else echo "Pas Trouver dans la base<br>"; } else { echo ' <form name="test" action="testCaractere.php" method="post"> <input type="text" name="login"> '; //j'y met ca : à<b"c'd/e\f>g echo '<input type="submit" value="tester"> </form>'; }   echo '</body></html>'; ?>

---

et comme résultat de ce code :

Citation:

---

_POST['login'] Rempli :
Post['login'] = àg

INSERT INTO `user` (`useName`) VALUES ('àg')
Dans la bd sur ce Insert,
j'ai exactement comme valeur du champ : à<b"c'd/e\f>g

Requete Sans ADDSLASHES() :

Pas Trouver dans la base

Requete Avec ADDSLASHES() :

Trouver dans la base

---

donc bref, comment faire un SELECT qui fonctionne sans le addslashes() comme tu dis que je n'est n'est point besoin.

Merci,

Regarde dans ton phpinfo() si tu as les magic_quotes activés.

malheureusement tout est a off,
Local Master
magic_quotes_gpc Off Off
magic_quotes_runtime Off Off
magic_quotes_sybase Off Off

j'ai lu un peu les topics sur les autres type d'injections SSX, ASCII et ben... je vais avouer que j'ai l'impression que seulement la protection des donnée c'est un emploi à temps plein.

je commence a me poser la question si ça vaut pas le coup d'interdire certaine chose dans les champs texte d'un formulaire : <,\, SELECT, DELETE, etc..) et de mettre seulement les lettres accentués ou non et les ', ".

J'ai pas fini de développer le site et juste faire les protections ça va prendre très longtemps je sens vu mes connaissances limités dans le domaine ;)

Quand tu fais ton test en inserant '\" tu obtiens quoi ?

Ne fonctionne pas non plus, c'est le \ le problème.
car si j'entre 'a"b'c, ça fonctionne bien.

même avec a\b ça ne marche pas.

l'INSERT fonctionne bien lui, mais pas le sélect

si je vais directement dans phpmyadmin et que j'y fait une requête

Code:

---

SELECT * FROM `user` WHERE `useName` LIKE 'a\\\\b';

---

j'obtient bien le nom a\b

et pour '\"

Code:

---

1 2	SELECT `useName` FROM `user` WHERE `useName` LIKE '\' \\\\ \"'

---

j'obtient bien '\"

donc... alors la je comprend pas pourquoi il doit y avoir 3\ de suite avant le vrai \ dans phyadmin pour réussir a sortir le login, moins de 3\ et ça fonctionne pas.

Quand tu as inseré a\b, quelle etait la requete d'insertion et qu'as tu dans la base au final ?

si $_POST['login'] = a\b;

a l'insertion avec tout les test :

Code:

---

1 2 3

$query = " INSERT INTO `user` (`useName`) VALUES ('".mysql_real_escape_string($_POST['login'])."')";

---

au final dans la base a\b donc ok normalement.


petit truc ici, tirer du MySQL 5.0 Reference manual, sur lequel je suis tomber:

Citation:

---

Note : Comme MySQL utilise la syntaxe d'échappement de caractères du langage C dans les chaînes (par exemple, ‘\n’), vous devez doubler tous les slash ‘\’ que vous utilisez dans les expressions LIKE. Par exemple, pour rechercher les nouvelles lignes (‘\n’), vous devez le spécifier comme cela : ‘\\n’. Pour rechercher un anti-slash (‘\’), vous devez le spécifier comme cela : ‘\\\\’ (les anti-slash sont supprimés une première fois pas l'analyseur syntaxique, puis une deuxième fois par le moteur d'expression régulières, ce qui ne laisse qu'un seul anti-slash à la fin).

---

donc... selon eux si je recherche une chaine avec un \ dedans, je devrais faire un str_replace("\", "\\\\",$login);

j'ai louper un truc ?

Citation:

---

Envoyé par Sylvain245

donc... selon eux si je recherche une chaine avec un \ dedans, je devrais faire un str_replace("\", "\\\\",$login);

---

C'est mysql_real_escape_string( ) qui se chargera de ça.

Mes résultats :

Code:

---

SELECT * FROM table WHERE useName = 'a\b'

---

ok

Code:

---

SELECT * FROM table WHERE useName LIKE 'a\b'

---

non

Code:

---

SELECT * FROM table WHERE useName LIKE 'a\\b'

---

non

Code:

---

SELECT * FROM table WHERE useName LIKE 'a\\\b'

---

non

Code:

---

SELECT * FROM table WHERE useName LIKE 'a\\\\b'

---

ok

Seb merci pour ton post,

Cependant... je ne sait pas si tu as tout lu, car si je fait

Code:

---

1 2 3

$rechUser = "SELECT `useName` FROM `user` WHERE `useName` LIKE '".mysql_real_escape_string($_POST['login'])."'";

---

et que $_POST['login'] = a\b, le select retourne rien comme je les mentionnés plus haut

Citation:

---

Envoyé par sabotage

Code:

---

SELECT * FROM table WHERE useName LIKE 'a\\\\b'

---

ok

---

Ah oui qd même, donc oublier ce que j'ai dit plus haut :roll:

Hum.... en fait.... si je vire mon Like 'a\b' pour = 'a\b' ça fonctionne aussi pour moi.

Donc autant de cassage de tête pour un LIKE au lieu de un = :oops: :evilred:

Citation:

---

Envoyé par Sylvain245

Donc autant de cassage de tête pour un LIKE au lieu de un = :oops: :evilred:

---

LIKE n'a d'intérêt que si tu utilises ses méta-caractères, sinon le = est plus efficace.

ah ... comme indiqué plus haut dans la documentation mysql, LIKE, contrairement à =, utilise un moteur d'expression réguliere, ce qui fait qu'il faut doubler les \