Prepare et Injection SQL

Salut all,

Je me pose la question si l'utilisation de requete prepare empeche/parre toutes injections SQL ?
(par prepare j'entends $mysqli->prepare ou mysqli_prepare)

Merci pour vos infos.

Ce n'est pas la fonction prepare() en elle même qui empêche les injections, c'est le fait de ne pas mettre les données potentiellement dangereuse dans la requête mais de les passer en paramètre.

Code:

---

mysqli_prepare('SELECT colonne FROM table WHERE colonne = ' . $_POST['id']); // pas bien

---

Merci sabotage pour ta reponse, mais je parlais dans des conditions correctes d'utilisation ;)
(genre l'exemple http://php.net/manual/fr/mysqli.prepare.php)
Donc si on fait comme l'exemple, ca empeche les injections ?

Avec Mysql, il vaut mieux aussi desactiver l'emulation :

Code:

---

$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, FALSE);

---

Citation:

---

Envoyé par sabotage

Ce n'est pas la fonction prepare() en elle même qui empêche les injections, c'est le fait de ne pas mettre les données potentiellement dangereuse dans la requête mais de les passer en paramètre.

Code:

---

mysqli_prepare('SELECT colonne FROM table WHERE colonne = ' . $_POST['id']); // pas bien

---

---

Mais en quoi le fait de passer les données potentiellement dangereuses en paramètre fait qu'elles ne le sont plus ? Et ne le sont-elles plus du tout, ou seulement un peu moins ?

Bonjour,

il serait bon de lire la doc :

• Requêtes préparées et procédures stockées

Citation:

---

Envoyé par Supracode

Mais en quoi le fait de passer les données potentiellement dangereuses en paramètre fait qu'elles ne le sont plus ? Et ne le sont-elles plus du tout, ou seulement un peu moins ?

---

Si j'ai tout compris (lol)

Code:

---

mysqli_prepare('SELECT colonne FROM table WHERE colonne = ' . $_POST['id']);

---

Pas glop, car utilisation du $_POST['id'] directement dans le prepare.

Code:

---

1 2	mysqli_prepare('SELECT colonne FROM table WHERE colonne = ?'); $con->bind_param('i', $_POST['id']);

---

Glop, car le $_POST['id'] est en dehors de la cmd sql.

Pièce jointe 266449

Citation:

---

Envoyé par jreaux62

Bonjour,
il serait bon de lire la doc :

---

D'accord, c'est affirmatif :

Citation:

---

. Si votre application utilise exclusivement les requêtes préparées, vous pouvez être sûr qu'aucune injection SQL n'est possibl

---

Mais pas très explicite pour autant.

Réceptionnons une variable pirate $_GET['cadeau']="DELETE 'everything' FROM 'la_totale' ".

Code:

---

1 2	$stmt = $dbh->prepare ("INSERT INTO REGISTRY (cadeau) VALUES (:cadeau, :value)"); $stmt->bindParam(':cadeau', $_GET['cadeau']);

---

Pourquoi le fait d'utiliser une requête préparée neutralise-t'il la valeur piégée de la variable $_GET['cadeau'] ?
Je ne me représente pas le truc.

Essaye, pour voir... :aie:

Bah, ce n'est pas de constater le résultat qui va m'expliquer le mécanisme qui produit ce résultat :?


T'sais pas en fait :toutcasse:

Citation:

---

Si votre application utilise exclusivement les requêtes préparées, vous pouvez être sûr qu'aucune injection SQL n'est possible

---

Ca ME suffit comme explication.

• Comprendre PDO

Citation:

---

« Prévenir les injections requiert de séparer les données non sûres des commandes et requêtes. »

Et ça tombe bien ; c'est très précisément ce que font les requêtes préparées : séparer les données de la structure de la requête !

---

[troll on]
Trop fort le pifou ;)
[troll off]

Citation:

---

Envoyé par jreaux62

Je n'ai pas besoin de savoir comment fonctionne le moteur de ma voiture pour la conduire...


Ca ME suffit comme explication.

---

D'accord, ça me rassure.

Mais ne me satisfait point pour autant.

Bon alors, pour la science, quel genre de spécialité informatique faut-il pratiquer, pour être capable de répondre à la question susdite ? Est-ce du ressort exclusif des ingénieurs en base de donnée, par exemple ? Ou de celui des concepteurs du langage PHP (on les appelle comment) ? Ou est-ce que ça se passe côté serveur ?

Je sais, je complique. Mais savoir comment tourne le moteur, c'est toujours intéressant.

Il me semble que le principe de fonctionnement est clair : "séparer les données non sûres des commandes et requêtes".

LIRE aussi :

• MySQL - Les requêtes préparées

Citation:

---

L'exécution d'une requête préparée se déroule en deux étapes : la préparation et l'exécution.

Lors de la préparation, un template de requête est envoyé au serveur de base de données.
Le serveur effectue une vérification de la syntaxe, et initialise les ressources internes du serveur pour une utilisation ultérieure.

---

Je ne vois pas ce que tu cherches d'autre...

La protection des requêtes préparée intervient parce que on sépare le programme à executer (la requête) des paramètres qui le compose.

Prenons l'exemple suivant :

Code:

---

1 2	$param = "1; DROP TABLE users;" $query = "SELECT * FROM users where id=$param ";

---

Si je fait une requête standard , je vais demander à mon serveur d'executer la requête : SELECT * FROM users where id=1; DROP TABLE users;Ce qui va résulter en là suppression de ma table ...

Maintenant si je fait une requête préparée :

Code:

---

1 2	$param = "1; DROP TABLE users;" $query = "SELECT * FROM users where id=?";

---

Le server SQL va "compiler" la requête à executer, qui va donc être :

Code:

---

SELECT * FROM users where id=

---

puis y appliquer le paramètre qui sera

Code:

---

1; DROP TABLE users;

---

Le serveur va donc simplement essayer de trouver un utilisateur avec l'id "1; DROP TABLE users;" et non pas interpréter celà comme une seconde requête collé à la première.
La seul partie que le serveur execute est la partie que l'on prépare et non la partie paramètre qui pourrait potentiellement contenir d'autres instructions.

Je ne sais pas comme ça marche en interne précisément , mais l'idée général est celle exposée plus haut ;)

Note que les requêtes préparées ne sont pas toujours indispensable. Dans l'exemple précédent , il suffit simplement de faire un intval() sur le paramètre attendu pour éviter tout problème. Elle sont en revanche très pratique dès que les paramètres passée sont textuelles et donc difficiles à controler

Intéressant, j'ai compris, merci. +1

Voyez, ça vaut le coup de détailler.:P