Discussion :

[Aizen64]

Bonjour,

j'ai un souci lors de l’exécution d'une requête préparée, les valeurs de PDO::bindParam ne sont pas transférées lors de l'appel de la fonction execute() et je ne comprends pas pourquoi.

Le code PHP :

Code :

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

1
2
3
4
5
 
$query = $pdo->prepare("SELECT id, FROM :ma_table");
$query->bindParam(':ma_table', $ma_table);
 
$queryUser->execute();

Le log postgreSQL:
ERREUR: erreur de syntaxe sur ou près de « $1
INSTRUCTION : SELECT id FROM $1,

Les variables passées dans la méthode bindParam() sont bien initialisées et aucune des variables passées avec bindParam ne sont prises lors de l'exécution.

bindValue a exactement le même comportement et je n'ai aucune erreur lors de la connexion à la BDD puisque aucune exception n'est jetée.

[Celira]

Les requêtes préparées n'acceptent des variables que pour les données (par exemple la valeur dans une condition where ma_col = :val ou l'affectation dans une requête insert/update)
Ce que tu veux rendre modifiable, c'est une composante de la requête. Donc, là, pas d'autre choix que la concaténation pure et simple :

Code :

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

1
2
3
$query = $pdo->prepare("SELECT id FROM ".$ma_table." ");
 
$queryUser->execute();

Si jamais la variable $ma_table est alimentée à partir d'une donnée extérieure, mets un maximum de contrôles dessus. Etablir une liste des tables autorisées et vérifier que $ma_table correspond à un élément de la liste est une bonne piste.

[Aizen64]

Grand merci, ça a solutionné le problème mais il reste un point au niveau sécurité par rapport à ton commentaire. Comme la doc spécifie qu'une requête préparée n'a pas besoin de faire de l'échappement de caractères, je n'ai pas utilisé PDO::quote() documentée ici. Donc l'équivalent de pg_escape_string() n'est pas dans mon code.

Est ce que c'est bien ce que tu voulais dire en matière de sécurité ?

[Celira]

Alors là, on est dans un cas limite : on échappe les valeurs qui partent dans les données (ou les conditions) pour éviter de laisser passer n'importe quoi. C'est surtout important lorsqu'on ne maitrise pas les données : typiquement, si elles arrivent d'un formulaire.

Là il s'agit d'un élément de ta base. On n'échappe les noms de colonnes, de tables...
Normalement, tu as la maitrise de la donnée. Par exemple, si ton bout de code est le corps d'une fonction et $ma_table est un paramètre de cette fonction : tu vas appeler ta fonction en renseignant en dur dans le code le paramètre de la fonction. Il n'y a donc pas de risque de faille.

Par contre, si tu es en train de faire une interface où ton utilisateur peut renseigner le nom de la table dans un formulaire, là il y a une faille potentielle : ton utilisateur peut taper n'importe quoi et te pourrir ta base si tu injectes la valeur reçue directement. Comme on ne peut pas échapper un nom de table, il faudra ajouter un contrôle pour empêcher la requête de s'exécuter si ton utilisateur a effectivement tapé n'importe quoi.

[Aizen64]

Je pense que l'on s'est mal compris, une clarification s'impose.

Ma remarque n'avait pas pour but de remettre en question l’échappement de caractères ni de valider les informations fournies dans le formulaire par un utilisateur, c'est une évidence. Par contre la documentation mentionne :

Si vous utilisez cette fonction pour construire des requêtes SQL, vous êtes vivement invités à utiliser PDO::prepare() pour préparer les requêtes SQL avec des paramètres liés au lieu d'utiliser PDO::quote() pour interpréter les entrées utilisateur dans la requête SQL.

D'où ma remarque sur le fait que mon code actuel n'utilise pas d’échappement.

[Celira]

Ah ! oui, une requête préparée n'a pas besoin d'appeler de fonction d'échappement (genre PDO::quote), c'est la préparation de la requête qui fait l'échappement toute seule (sur les données envoyées par BindParam, BindValue ou en paramètres de la fonction execute). C'est bien ça que tu veux dire ?

[Aizen64]

Oui.

[Bastien_Witczak]

Les requêtes préparées n'acceptent des variables que pour les données (par exemple la valeur dans une condition where ma_col = :val ou l'affectation dans une requête insert/update)
Ce que tu veux rendre modifiable, c'est une composante de la requête. Donc, là, pas d'autre choix que la concaténation pure et simple :

Code :

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

1
2
3
$query = $pdo->prepare("SELECT id FROM ".$ma_table." ");
 
$queryUser->execute();

Concernant ce code il est préférable de réaliser ceci

Code :

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

1
2
3
4
5
6
7
$query = $pdo->prepare(<<<SQL 
           SELECT id
           FROM :maTable;
SQL
);
 
$query->execute(array(":maTable" => $maTable));

Ceci evite d'utiliser la concaténation et offre une meilleure lisibilité du code.

[ABCIWEB]

Concernant ce code il est préférable de réaliser ceci

Code :

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

1
2
3
4
5
6
7
$query = $pdo->prepare(<<<SQL 
           SELECT id
           FROM :maTable;
SQL
);
 
$query->execute(array(":maTable" => $maTable));

Ceci evite d'utiliser la concaténation et offre une meilleure lisibilité du code.

C'est intéressant de connaître la syntaxe heredoc mais de là à dire qu'elle est préférable, c'est surtout suivant les goûts et elle impose des contraintes.
Et ne vient-on pas de dire qu'on ne peut pas lier un nom de table (ni de colonne) mais uniquement des variables ?

[Bastien_Witczak]

Oui autant pour moi, je n'ai pas fait attention lorsque j'ai posté mon message.

Comme dit plus haut les requetes préparées n'accepte que des variables que pour les données (where ma_col = :val);