Discussion :

[Madfrix]

Bonjour,

je sais que via les requêtes préparées, il est impossible de subir des attaques de type injection, mais je n'ai jamais compris le pourquoi du comment

Est-ce PDO qui caste automatiquement les variables connaissant le type à l'avance des champs en base ou...?

Merci de vos éclairssissements

[nosferapti]

PDO échappe automatiquement les données si tu les passe par les méthodes "bind*" ou par "execute"

[Petibidon]

En prenant l'exemple que tu attaques une base mySql,

PDO::PARAM_STRING appliquera un équivalent de mysql_real_escape_string() sur la variable liée.

PDO::PARAM_INT castera la variable en entier, si tu lui passes une chaîne non numérique, ça te rentrera 0 en base.

Edit : fichus smileys automatiques !

[RunCodePhp]

Salut

PDO::PARAM_INT castera la variable en entier, si tu lui passes une chaîne non numérique, ça te rentrera 0 en base.

J'avais fais pas mal d'essai sur ce point là, et j'en avais conclu que PDO ne typait (ou castait) rien du tout.
Les constantres PARAM_INT, PARAM_NULL, etc ... ne provoquait strictement rien sur les valeurs, c'est comme si on ne mettais rien.

J'avais créé un topic la dessus pour avoir des avis d'ailleurs.
-> BindValue() : Paramètre data_type sans effet ?
Apparemment, et selon Julp ça dépendrait du SGBD, du driver/pilote utilisé.

Pour PDO (Php5.3.0) et MySQL5.1.36, ça donne pas grand chose, du moins, selon mes essais.


A coté de ça, il me semble que les requêtes préparées offrent énormément de sécurité contre les SQL injections.

[julp]

C'est la séparation des données de la requête même (les valeurs des colonnes dans une requête update/insert ou au niveau de la clause where notamment) qui assure l'absence d'injections. C'est ensuite totalement géré par le SGBD. La requête préparée aura été analysée/compilée par le SGBD avant la prise en compte des valeurs des paramètres, ces dernières sont donc totalement indépendantes et sans influence.

Les (potentielles) conversions effectuées par PHP ne sont pas liées, elles n'assurent la correspondance de type (PHP vers SGBD) que lorsque nécessaire (d'autant que certaines peuvent être implicitement réalisées par le SGBD).

[RunCodePhp]

Les (potentielles) conversions effectuées par PHP ne sont pas liées, elles n'assurent la correspondance de type (PHP vers SGBD) que lorsque nécessaire

C'est vraiment potentielles, car pour MySQL ce n'est jamais le cas malheureusement.

Si, (par exemple) on met comme paramètre PARAM_NULL et que coté Bdd le champ accepte une valeur nulle, et bien dans tous les cas ce n'est pas une valeur nulle qui sera insérée, au mieux, ça sera vide.
Enfin, si la valeur n'est pas nulle j'entends. Ca veut bien dire que PARAM_NULL n'a aucune relation entre PDO et MySQL.
Si on veux mettre une valeur nulle, on a pas d'autre choix que la valeur soit vraiment nulle, donc on doit traiter le cas avant PDO.
C'est nulle ...


Si ce paramètre n'est pas là pour résoudre ce genre cas (comme caster une variable), alors je dirais qu'il est trompeur, il laisserait sous entendre que ...
Je serais tombé dans l'panneau, si on peu dire.


Pour donner mon sentiment sur les requêtes préparées, et sauf erreur de ma part, vous me direz si je me trompe , mais il me semble que certains y feraient un peu trop confiance.

Si on fait une requête comme celle ci :

Code :

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

1
2
3
4
 
$sql = 'SELECT champ FROM table WHERE user_id = '.$_POST['user_id'];
$stmt = $pdo->prepare($sql);
$stmt->execute();

Ici, et théoriquement, on ne serait pas protégé contre une éventuelle injection venant de $_POST.

Il faudrait au moins binder (si on peu dire) la valeur extérieure.
Comme par exemple :

Code :

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

1
2
3
4
 
$sql = 'SELECT champ FROM table WHERE user_id = ?';
$stmt = $pdo->prepare($sql);
$stmt->execute(array($_POST['user_id']));

Ou

Code :

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

1
2
3
4
5
 
$sql = 'SELECT champ FROM table WHERE user_id = :user_id';
$stmt = $pdo->prepare($sql);
$stmt->bindValue(':user_id', $_POST['user_id'], PDO::PARAM_INT);
$stmt->execute();

Ici on profite pleinement des requêtes préparées pour le coté sécurité.

[julp]

C'est vraiment potentielles, car pour MySQL ce n'est jamais le cas malheureusement.

Ça n'a pas de lien direct avec les requêtes préparées de toute manière. Mais la cast n'est pas systématique car dépendant du SGBD au niveau de sa propre implémentation, API, conversions implicites qu'il peut réaliser, etc comme ce fut abordé dans la discussion précédemment pointée. (Je m'attendais cependant aussi à une cast plus systématique, ne serait-ce que par principe)

Si on fait une requête comme celle ci :

Code :

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

1
2
3
4
 
$sql = 'SELECT champ FROM table WHERE user_id = '.$_POST['user_id'];
$stmt = $pdo->prepare($sql);
$stmt->execute();

Ici, et théoriquement, on ne serait pas protégé contre une éventuelle injection venant de $_POST.

Un risque d'injection est bien présent ici. On exécute bien la requête comme une requête préparée mais elle n'a rien d'une requête préparée : la valeur de user_id devrait faire l'objet d'un paramètre, auquel on associe plus tard la valeur. Une telle utilisation des requêtes préparées n'a aucun intérêt et ce à tous les niveaux (performances comme sécurité). L'unique et bonne méthode est de passer par des paramètres puis de réaliser leur association à leurs valeurs respectives (méthodes bindParam, bindValue ou execute) tels les autres exemples.

Pour illustrer : une requête préparée c'est une requête à trous (les paramètres : nommés - syntaxe :nom - ou anonymes - à base de points d'interrogation) dont le code SQL est statique. Ces "trous" sont ensuite remplacés (niveau SGBD) par des valeurs que l'ont fournies ensuite (méthodes bindParam, bindValue ou execute). Cela a plusieurs avantages : l'absence d'injections imputables à ces immondes concaténations ou autres interpolations et de pouvoir être exécutées plusieurs fois (que ces paramètres aient des valeurs différentes ou non - d'où le gain en performance d'ailleurs).

[Madfrix]

Bonjour,

tout d'abord merci pour vos réponses éclairées

Code :

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

1
2
3
4
 
$sql = 'SELECT champ FROM table WHERE user_id = '.$_POST['user_id'];
$stmt = $pdo->prepare($sql);
$stmt->execute();

Ici, et théoriquement, on ne serait pas protégé contre une éventuelle injection venant de $_POST.

On ne peut plus d'accord vu que je l'ai testé en local et que je me suis auto attaqué

Mais comme l'a dit nosferapti :

PDO échappe automatiquement les données si tu les passe par les méthodes "bind*" ou par "execute"

Encore d'accord mais juste une question : ne serait ce pas plus simple (et encore plus sécurisé) que ce ne soit pas execute() qui échappe la string mais bien prepare() ? Ce serait finalement facilement implémentable non ?

Ainsi que l'on execute via des ?, :id ou tout simplement une requete ne présentant pas d'intéret à etre préparée et bien dans totu ces cas de figure, l'echappement de prepare() nous assurerait (en théorie) une protection optimale non ?

[julp]

ne serait ce pas plus simple (et encore plus sécurisé) que ce ne soit pas execute() qui échappe la string mais bien prepare() ? Ce serait finalement facilement implémentable non ?

Non, et c'est ce que j'explique depuis le début. La requête préparée n'est qu'une ossature, du SQL pur sans données lorsqu'elle est préparée via la méthode prepare. Elle n'a donc pas à être traitée/échappée, chose que le SGBD est tout aussi incapable de réaliser. Les données ne sont associées qu'après à leurs paramètres respectifs (méthodes bind[Param|Value] ou execute). Le traitement des données ne peut donc avoir lieu qu'à ce seul moment et non avant qu'elles ne soient connues. D'autant, je le répète, qu'une même requête préparée peut être exécutée plusieurs fois (en attribuant des données différentes ou non à ses paramètres).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$dbh = new PDO(DSN, LOGIN, MOT_DE_PASSE, $options);
 
// Préparation de notre requête
if (!$insert = $dbh->prepare('INSERT INTO `utilisateurs`(`login`, `mot_de_passe`, `email`) VALUES(?, SHA(?), ?)')) {
    list($pdoCode, $internalCode, $msg) = $dbh->errorInfo();
    die(sprintf("La préparation de la requête a échoué : %d/%d, %s", $pdoCode, $internalCode, $msg));
}
 
// Exécution, une première fois de la requête, avec nos valeurs
if (!$insert->execute(array('Duvin.Marie', 'saphir', 'duvin.marie@bidule.fr'))) {
    list($pdoCode, $internalCode, $msg) = $insert->errorInfo();
    die(sprintf("L'exécution de la requête a échoué : %d/%d, %s", $pdoCode, $internalCode, $msg));
}
// Requête exécutée : INSERT INTO `utilisateurs`(`login`, `mot_de_passe`, `email`) VALUES('Duvin.Marie', SHA('saphir'), 'duvin.marie@bidule.fr');
 
// Exécution, une deuxième fois de la requête, avec de nouvelles valeurs
if (!$insert->execute(array('Morin.Hervé', 'zircon', 'morin.herve@bidule.fr'))) {
    list($pdoCode, $internalCode, $msg) = $insert->errorInfo();
    die(sprintf("L'exécution de la requête a échoué : %d/%d, %s", $pdoCode, $internalCode, $msg));
}
// Requête exécutée : INSERT INTO `utilisateurs`(`login`, `mot_de_passe`, `email`) VALUES('Morin.Hervé', SHA('zircon'), 'morin.herve@bidule.fr');

Le réaliser lors du prepare serait revenir à la case départ puisqu'impossible : retour aux injections et/ou les requêtes préparées seraient sans intérêt.