Discussion :

[Fladnag]

Bonjour,

J'ai réalisé un article sur les différents formats qu'une donnée peut prendre au cours de son exécution dans un script PHP et les problématiques associées.

L'article contient aussi une classe que j'ai réalisé pour répondre a certaines problématiques.

N'hésitez pas a donner votre avis ici si vous avez des remarques ;o)

http://fladnag.developpez.com/tutori...e-donnees-php/

[Maître Kenobi]

un bon article, cependant serait-il possible de revoir la version PDF au chapitre 6.7 résumé car le tableau n'est pas très lisible.

[Fladnag]

un bon article, cependant serait-il possible de revoir la version PDF au chapitre 6.7 résumé car le tableau n'est pas très lisible.

Arf... en effet :/
La génération automatique en PDF n'est pas top.

Je vais voir ce que je peux faire mais je promet rien vu que c'est automatique en principe.

Edit : Voila, la version PDF devrait être mieux maintenant !

[stealth35]

Cela permet d'éviter 99.9% des failles de type Injection SQL.

le 0.1 c'est quoi ?

faut pas oublier PDO quote non plus, et que par exemple pour PDO_MySQL les requêtes préparées sont émulés par défaut

[Fladnag]

le 0.1 c'est quoi ?

En fait il est possible de faire de l'injection SQL dans PDO en jouant sur les charset et les caractères multi octets.
Si tu passes a ta requete une valeur contenant un caractère multi octet valide dans le charset du site dont le 2eme octet correspond au caractère quote ('), ce caractère peux passer l'échappement de PDO et être interprété comme 2 caractères distincts par la base de donnée.

Je n'ai pas développé la problématique des charsets et des caractères multi octets parce que :
* Je ne maitrise pas completement le sujet ^^
* Les charset sont ma bête noire, vive l'UTF-8 partout ;o)
* Ce problème n'arrive en principe que si tu utilise/accepte des charsets bizarres genre langue asiatique.

Si tu veux des exemples, un powerpoint de l'OWASP est disponible ici :
http ://www.slideshare.net/kkotowicz/sql-injection-complete-walktrough-not-only-for-php-developers
le slide qui est parle est le 31.

faut pas oublier PDO quote non plus

Non, PDO::quote ne doit être utilisé que si on utilise PDO sans utiliser les requetes préparés (dans ce cas là on insère les variables au milieu des requête, et il faut utiliser PDO::quote)
Vu que c'est fortement déconseillé et qu'on perd tout les avantages des requêtes préparés, je ne l'ai pas cité.

pour PDO_MySQL les requêtes préparées sont émulés par défaut

Bah, il vaut mieux que ce soit l'API de PDO qui échappe les variables automatiquement que le développeur... le risque d'erreur est moindre ^^

[stealth35]

Non, PDO::quote ne doit être utilisé que si on utilise PDO sans utiliser les requetes préparés (dans ce cas là on insère les variables au milieu des requête, et il faut utiliser PDO::quote)
Vu que c'est fortement déconseillé et qu'on perd tout les avantages des requêtes préparés, je ne l'ai pas cité.

faut pas ce dire requêtes préparés = sécurité c'est pas forcement vrai, c'est pour ca quej e dit qu'il faut pas obligé le PDO quote, et tu peux tres bien l'utilisé dans un requêtes préparées, c'est pas obligé d’insérer tout les variables, si t'as un valeur fixe tu vas la répété X fois ?

pour le problème de charset c'est corrigé avec la version 5.3.6

Bah, il vaut mieux que ce soit l'API de PDO qui échappe les variables automatiquement que le développeur... le risque d'erreur est moindre ^^

PDO échappe aussi en non émulé ...

[Fladnag]

faut pas ce dire requêtes préparés = sécurité c'est pas forcement vrai, c'est pour ca quej e dit qu'il faut pas obligé le PDO quote, et tu peux tres bien l'utilisé dans un requêtes préparées, c'est pas obligé d’insérer tout les variables, si t'as un valeur fixe tu vas la répété X fois ?

Heu... attend, tu veux utiliser PDO::quote avec des requetes préparés ?
Tu risque pas d'avoir un double échappement ?
La doc le déconseille en tout cas :
http://fr2.php.net/manual/fr/pdo.quote.php

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. Les requêtes préparées avec des paramètres liés sont non seulement plus portables, plus souples et plus sécuritaires, mais bien plus rapides à exécuter que d'interpréter les requêtes, étant donné que les côtés client et serveur peuvent mettre en cache une version compilée de la requête.

PDO échappe aussi en non émulé ...

Bien sur, je ne comprends pas ce que tu veux dire...
Ce que je dis c'est qu'il vaut mieux utiliser PDO (qu'il soit émulé ou pas) avec des requêtes préparés de manière a laisser le soin a l'API d'échapper les variables plutôt que de recoder ça dans l'application et risquer d'en oublier une.

[stealth35]

Heu... attend, tu veux utiliser PDO::quote avec des requetes préparés ?
Tu risque pas d'avoir un double échappement ?

pourquoi un double échappement ?

j'ai le droit de faire

Code :

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

1
2
3
4
5
$role = $pdo->quote('truc');
$sql ="INSERT INTO matable (nom, role) VALUE(?, '$role')";
 
foreach($noms as $nom)
$stmt->excute(array($nom));

aucun intérêt de mettre en variable une constante, regarde tes logs SQL et tu comprendras

[Fladnag]

aucun intérêt de mettre en variable une constante, regarde tes logs SQL et tu comprendras

Ok, je comprends mieux !
Dans ce cas là en effet, même si c'est déjà plus rare d'avoir une constante que l'on ait besoin d'échapper

Je pensais que tu voulais utiliser PDO::quote sur une variable que tu envoyais ensuite dans une requête préparée.

Pour reprendre ton exemple, il ne faut surtout pas faire :

Code :

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

1
2
3
4
5
6
$sql ="INSERT INTO matable (nom) VALUE(?)";
 
foreach($noms as $nom) {
  $nom = $pdo->quote($nom); // Pas une bonne idée ^^
  $stmt->excute(array($nom)); // ... car double échappement ici
}