Discussion :

[Danyel]

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.

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Danyel]

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 ?

[sabotage]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Supracode]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Invité]

Bonjour,

il serait bon de lire la doc :

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

[Danyel]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Invité]

[Supracode]

Bonjour,
il serait bon de lire la doc :

D'accord, c'est affirmatif :

. 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Invité]

Essaye, pour voir...

[Supracode]

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

[Invité]

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

« 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 !

[Danyel]

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

[Supracode]

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.

[Invité]

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

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...

[grunk]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM users where id=

puis y appliquer le paramètre qui sera

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Supracode]

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

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