Je sais que pour se protéger des injections SQL (en utilisant PDO) il faut utiliser les requêtes préparées.
Le problème c'est que ce n'est pas possible de spécifier une table qui sera dans la clause FROM comme paramètre (ex: " SELECT * FROM ? ")

Dans ce cas comment éviter toute injection ?

Merci d'avance

Je suis pas sur d'avoir bien compris, tu veux mettre une table en paramètre à ta requête sql ?

Essaye ça pour voir:
$qry = objet_pdo->prepare("SELECT * FROM :table");
$qry->bindValue(":table", "ma_table");
$qry->execute();

je n'ai pas bien compris non plus, et je ne connais pas php mais en sql après FROM viens le nom de la table. Pourquoi ne pas simplement filtrer tes inputs avec un regex et une whitelist?

Pourquoi ça te serait utile de préciser une table précise en paramètre ?

Le 05 juin 2015 à 21:50:12 rangerprice a écrit :
Je suis pas sur d'avoir bien compris, tu veux mettre une table en paramètre à ta requête sql ?

Essaye ça pour voir:
$qry = objet_pdo->prepare("SELECT * FROM :table");
$qry->bindValue(":table", "ma_table");
$qry->execute();

Ca marche pas, PDO n'autorise pas de bind le nom de la table.

Ce code ne sert à rien. Il faut protéger contre les données envoyées par l'utilisateur :

$variable = $_POST['foo'];
$requete = $pdo->prepare("SELECT * FROM table WHERE foo = :foo");
$resultat = $requete->execute(array(":foo" => $variable));

C'est pour les données de $_POST['foo'] qu'il faut établir une protection. Mais si tu fais une requête sans WHERE, ça ne sert à rien.

Ok désolé je vais essayer d'être plus clair

Pour utiliser un script, un administrateur a besoin de renseigner le nom de tables sur lesquelles effectuer des actions.
La requête serait donc du type "SELECT * FROM".$table, sauf que dans l'idéal ce n'est pas sécurisé.

Je voulais donc faire " SELECT * FROM ?", requête sur laquelle je fais un bindValue(1, $table, PDO::PARAM_STR);
Sauf que PDO ne fonctionne pas pour le bind d'un nom de table...

Utiliser http://php.net/manual/fr/pdo.quote.php pour proteger le nom de ta table. Attention, il faut toutefois supprimer les simples quotes dans la nouvelle chaine de retour. Tu peux simplement les supprimer ou les remplacer par des `backticks` si tu n'est pas sure que ta table n'aura pas un nom réservé par mysql. Regarde bien comment est construit la chaine protégé, je crois qu'il y a des quotes au milieux en fonction de l'entrée.

La solution la plus simple pour moi, serait d'utiliser un regex pour s'assurer que l'utilisateur a rentré un chaine qui te convient, par exemple preg_match('/^[a-z0-9_]+$/i', $table)

edit: A la limite tu peux meme faire un preg_replace pour supprimer tous les caractères qui ne sont pas alpha numériques.

Pour les utilisateurs, si l'user est déjà auth en tant qu'admin il n'y pas de problème de confiance et si il ne connais pas a l'avance tous les noms de tables il ne pourra pas faire de liste.

Bien que l'user soit deja admin, je suis d'accord qu'il faut quand meme vérifier l'intégrité du nom de la table et je pense que la meilleure solution si tu ne connais pas le nom des tables est d'utiliser un regex pour formater la chaine et éviter les injections.

Si tu connais a l'avance le nom des tables, tu peux faire une table (par exemple: tListe) qui contient le nom de tes tables dynamiques. Losque l'admin veut selectioner une table, tu regarde si le nom de la table existe dans tListe (tu utilises une requete préparée a ce moment la) comme ca tu récupère le nom depuis la bdd pour l'utiliser dans ta prochaine requête.

Je peux plus édit donc je double post.

@RedSky Javais mal lu ta premère phrase, forcement qu'il faut faire une blacklist pour exclure certaines tables, ou un système de prefixe. Je pensais que ça coulait de source

personnellement je pense plutot qu'une whitelist est plus pertinente.

si l'user est déjà auth en tant qu'admin il n'y pas de problème de confiance

Faux (cf CSRF)

Leonidas_NS+1

Le 08 juin 2015 à 16:18:00 deepblue a écrit :

si l'user est déjà auth en tant qu'admin il n'y pas de problème de confiance

Faux (cf CSRF)

Leonidas_NS+1

Bien de quote un truc hors contexte ?
Juste apres je dis : " Bien que l'user soit deja admin, je suis d'accord qu'il faut quand meme vérifier l'intégrité du nom de la table "
L'OP veut savoir comment se proteger des injections sql. Je part du principe qu'il a système d'auth et que l'user s'est auth avant de faire les requetes. A aucun moment il ne parle de CSRF.

Le 08 juin 2015 à 16:00:32 Leonidas_NS a écrit :
personnellement je pense plutot qu'une whitelist est plus pertinente.

Si il connais le noms des tables a whitelister pourquoi pas

Sauf que y a une grosse faille CSRF si il check pas par exemple une clé générée aléatoirement

Ok étant donné que l'application va pour l'instant rester en intranet je vais partir sur une expression rationnelle classique merci