Bonjour,
 
La fonction "mysql_real_escape_string" suffit t-elle à éviter les injections mysql ?
 
Merci

oui,  
mais si tu peux utilise PDO

A ce propos, le fait d'utiliser PDO nous permet-il de ne plus utiliser mysql_real_escape_string ?  
 
Autre chose, si on utilise PDO il faut modifier chaque requête SQL (en plus de l'ouverture de la base) ?

avec les requêtes préparer, tu n'auras plus besoin d'utilisé mysql_real_escape_string
 
pour la modif des requetes pas grand chose a modifié
au lieu de faire

$sql = "SELECT login FORM user WHERE id = 1 AND valid = 1";
mysql_query($sql);

 
en requete preparé tu feras
 

$sth = $pdo->prepare("SELECT login FORM user WHERE id = ? AND valid = ?" )
$sth->execute(array(1, 1))

 
 
http://www.siteduzero.com/tutoriel [...] x-bdd.html
 

Merci ! Sympa ça

Merci pour vos réponses.
 
En quoi l'utilisation des PDO est mieux ?
Merci

 
plus rapide, plus portable, plus simple

A ce propos j'ai assez cherché sur Google mais rien trouvé.
Les PDO sont-(elles?) vraiment sécurisées ?

Ca me dérange un peu de faire confiance à un bouzin dont je ne connais pas le fonctionnement interne.

Avant jbossais avec du sprintf+mysql_real_escape_string  (+ du is_numeric pour les variables ID & co), et là je refais un site.

Et j'hésite à avoir confiance

ce topic m'intéresse ...
 
quelle différence y a-t-il (point de vue sécurité ) entre :

 
et :
 

 
?
En mettant des intval, des abs, on est sûr d'avoir des numériques. En cela, je ne trouve pas PDO plus sécurisé. Reste l'échappement de chaines de caractères ... Mais %s permet déjà de se débarrasser de l'hexa, il ne reste "plus grand chose" ...

Jcrois que c'est surtout + securisé parce que tu risques pas d'oublier un filtrage quelque part dans ton site
 
Et sinon ce que tu fais ne suffit pas (enfin si puisque c'est des 1) mais si c'etait du _POST il faut mettre mysql_real_escape_string($_POST['leun'])

oui effectivement, mais au vu de l'exemple avec des valeurs numériques, je ne suis pas rentré dans le mysql_*_escape_string.
 
Et concernant le filtrage, avec un sprintf si tu oublies une valeur, tu as de toutees façons une erreur... (sprintf : too few arguments ||too many arguments)
Reste encore l'éternel problème de pluralité des hébergeurs et compatibilité des applications (en particulier chez Free où l'activation de PDO est un peu folklorique).

Nan jvoulais dire :
 
Si tu oublies de splintf-er/msqyl_real_escap-er une de tes requetes dans ton site, alors ça peut faire une faille
 
En passant tout par PDO, vu que t'as pu à faire ça... Pu d'oubli. Pu de failles (a priori)

pdo, ça a avant tout comme avantages :
- abstraction de l'accès aux données (les fonctions mysql_* ne fonctionnent qu'avec mysql )
- orienté objet. Dans un projet OO, c'est quand même mieux d'utiliser du OO. Et pdo évite tout simplement d'écrire soit-même les classes d'accès aux données

et les requetes preparer c'est quand même beaucoup plus rapide
 

$stat = $pdo->prepare("INSERT INTO user VALUE(:login, :email)" );
 
foreach($users as $user)
{
    $stat->execute($user);
}

 
qui permet d'avoir qu'une seule requete, au lieu dans boucler plein, et comme dis kao on évite de récrire des fonctions qui feront la même chose (mais en moins bien en plus), et si d'un jour a l'autre on veux passer sous Oracle, SQLite...., on aura juste une petit modif a faire dans la requête (et encore...), au lieu de tout changer

J'ajouterais un petit argument de lisibilité du code aussi. En admettant qu'on ait une requête complexe qui fasse énormément de where clauses, si on peut avoir la requête puis un tableau de paramètres simple plutôt qu'un sprintf avec 10 fois "mysql_real_escape_string", 3 fois "intval" etc, je pense que c'est bon à prendre également.

 
waï mais bon : si tu fais un objet de connexion avec des méthodes de sélection DB + exécution requête, au final, tu n'as plus que ta classe à modifier. Ce que je veux dire, c'est que je ne dénigre absolument pas pdo et ton exemple de "insert" est effectivement assez "simple", mais avec un objet de connexion tu peux avoir le même truc :
 

 
je pense à un truc de ce style. Je vois une différence, c'est que ta variable $query est instanciée autant de fois qu'il y a de passages dans la boucle, certes. mais au final, même avec PDO, t'as X users tu exécutes X fois la requête ...

non puisque c'est une requête préparer, tu peu aussi en faire avec l'extension mysql normal mais ca personne n'y pense
 
http://dev.mysql.com/doc/refman/5.0/fr/sqlps.html
 
t'aura l'avantage aussi du fetchAll, (actif dans mysqli sous php 5.3 avec mysqlnd), tu va recuperer tout ton tableau d'un seul coup au lieu de parcourir (ce qui comprend tout l'avantage du parcours de tableau),
mais encore une fois tu peux tres bien le faire avec une class
 

$items = array();
while($data = mysql_fetch_object($req))
{
    $items[] = $data;
}

Mais pourquoi diable ré-inventer la roue carrée plutôt que d'utiliser une roue circulaire existante ?

je vais faire l'essai, ça m'intéresse. en fait je m'étais fait une classe qui ressemble à  mon exemple ci_dessus, mais celle-ci renvoyait l'ID en cas d'INSERT, le affected_rows en cas de delete ou update, et la ligne en cas d'erreur ... (__LINE__) . Je vais voir ce qu'il est possible de récupérer avec les PS en cas d'erreur.

Salut à tous j'ai un petit souci, j'aimerai éviter les injection SQL mais je ne sais pas comment faire.
Un peut d'aide serait la bienvenu :  
 
Je vous montre mon code :  
 
ma page traitement.php :  
 

 
 
et ma page connect.php :  
 

 
En fait je voudrai juste évité les injection SQL sur mon champ "$email" et mon champ "$phone"
 
Merci pour votre aide

Le topic l'a expliqué : tu fais une requête préparée et tu l'exécutes.