Discussion :

[tse_jc]

Bonjour,

J'aimerais corriger une inexactitude / abus de language qui m'inquiète concernant

$requete = mysql_query("SELECT age FROM membres WHERE pseudo='$pseudo'");
L'utilisation de guillemet pour inclure la variable pseudo peut faire courrir un risque à l'application car PHP va interpréter le code $pseudo pour le jouer dans le code et cela peut être très dangereux. De plus l'utilisation de guillemet et fortement consommatrice de ressource car justement PHP recherche entre guillemet des éléments à exécuter en tant que code PHP...

Il ne faut pas confondre ce qui est executé côté php et côté SGBDR. L'utilisation de guillemets pour inclure la variable pseudo n'a strictement rien à voir avec un risque éventuel dans l'interprétation du code.
Dans tous les cas, la variable $pseudo doit être interprétée par PHP sinon la connexion ne peut se faire. L'utilisation de guillemets qu'il soient représentés par des simples ou doubles quotes dans la requête mySQL sont indispensables lorsque la variable passée doit être considérée comme une chaîne de caractères par MySQL. Par contre si la variable attendue est un nombre, la seule incidence de placer des guillemets, est une perte de performances au niveau SGBDR seule car cela oblige le moteur base de données à recaster implicitement une variable inutilement.

L'utilisation de doubles quotes pour encadrer une requête SQL en PHP est une recommendation car elle permet d'en simplifier l'écriture fortement.

Le meilleur conseil à donner c'est ericd69 qui l'a donné à savoir toujours vérifier ce que contiennent tes variables PHP avant de les passer (il faut donc passer systématiquement par des variables locales utilisateur). Je rajouterai de retyper fortement tes variables évite aussi bien des soucis inutiles. ex: $id=intval($_GET['id']); suffit à protéger la valeur numérique attendue contre toute tentative d'injection. Au pire une rajouter un contrôle de valeur s'il est essentiel d'interdire une valeur négative d'être passée.

Donc en résumé
Le code suivant :

Code :

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

1
2
3
$id=intval($_GET['id']);
$requête=mysql_query("SELECT age FROM membres WHERE id=$id");

Ne pose aucun problème et il n'y a pas meilleure façon de l'écrire.

++

[Ingesys]

Ouais t'inquiète, je répondais à ta question simplement, à toi et ascito, et elle était tout à fait légitime : pourquoi faire simple quand on peut faire compliqué ?

En fait, c'est sûr que si je faisais un simple site de vente avec 3 T-shirts, je me serais contenté d'un CMS genre Prestashop, et hop c'était réglé.

Mon projet est un peu plus complexe et j'essaie d'emblée de pondre une structure qui me permettra une bonne évolutivité. Il n'y a rien de plus embêtant que de se voir bloqué par la technique ou les trucs tout faits qui ne vont pas forcément dans le sens de ce que tu veux faire.

Tu me cites Scrum : en voilà une méthodologie évolutive qui fait intervenir toute une équipe jusqu'au client, mais je peux pas être au four et au moulin et être à la fois Product Owner, Scrum Master et faire mes sprints (même si en fait c'est le cas puisque je ponds pour moi). Mais bon on atteindrait là un degré grave de schizophrénie

Mais j'ai compris ton allusion. Je parlais effectivement de bonnes pratiques (tu aurais pu citer ITIL, CMMI,..), et ça veut pas dire que c'est forcément une recette à adapter à tout projet, je suis d'accord avec toi.

Je prends juste un exemple au niveau stock/livraison : un site comme cdiscount s'est développé avec l'acharnement (je crois bien que c'est eux) de leurs créateurs qui stockaient leurs produits chez eux au départ (CD et DVD au début je crois) et les expédiaient eux-mêmes.

Je pense que si leur aventure commençait aujourd'hui, ils utiliseraient les structures existantes en évitant de gérer du stock et de livrer eux-mêmes (bon, après ils ont viré à l'usine, donc c'est sûr il faut des entrepôts, du personnel, etc...).

Mais tu m'accorderas que s'ils avaient vendus des bagnoles ou des canapés, ça aurait été un peu plus dur à stocker chez eux !

Non, non je ne vais pas concurrencer ebay... mais j'ai ma petite idée sur une vente de produits...à ma façon.

[Ingesys]

Merci tse_jc pour ces précisions.

En gros c'est comme cela que j'ai procédé (comme tu l'as écrit):

1) Définition d'une variable 1 qui contient l'instruction SQL $Get ou $Post
2) Définition d'une variable 2 qui contient le résultat de la fonction PHP query sur la requête SQL de la valeur de la variable 1

Maintenant le coup des guillemets... Moi qui croyait avoir compris

Je crois qu'il serait bon d'en remettre une couche...

[tse_jc]

Maintenant le coup des guillemets... Moi qui croyait avoir compris

Je crois qu'il serait bon d'en remettre une couche...

Ok voici une liste d'expression avec des guillemets toutes équivalentes (bonnes) pour t'aider à mieux comprendre.

Code php :

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

1
2
3
4
5
6
7
8
9
10
 
$p_string = 'salut';
$msg=" $p_string tu vas bien? "; echo $msg; // salut tu vas bien?
$msg= $p_string.' tu vas bien? '; echo $msg; // salut tu vas bien?
$msg=' He! '.$p_string.' tu vas bien? '; echo $msg; // He! salut tu vas bien?
//Ensuite avec des guillemets dans $msg
$msg = " '$p_string' tu vas bien?"; echo $msg; // 'salut' tu vas bien?
$msg = " \"$p_string\" tu vas bien?"; echo $msg; // 'salut' tu vas bien?
$msg = ' "'.$p_string.'" tu vas bien? '; echo $msg; // "salut" tu vas bien?</p>
$msg = ' he! '\''.$p_string.'\' tu vas bien? '; echo $msg; // he! 'salut' tu vas bien?

Voilà je pense que tu devrais mieux comprendre comment ça fonctionne^^.

++

[Ingesys]

Je suis pas sûr de bien comprendre, JC.

Que fais-tu de ça ?

Exemple ou mysql_real_escape_string est inefficace :

Si ma requete est :

Code :

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

1
2
 
$IsDo = mysql_query('SELECT * FROM toto WHERE id='.mysql_real_escape_string($_GET['donnelabmda']));

Si je met dans $_GET['donnelabmda'] ceci : "1 OR 2<>3" mysql_real_escape_string n’échappera aucun caractères et l'injection marchera sans soucis. Et je pourrais réaliser des requêtes voir sous requêtes complexe.

Donc toujours écrire comme ci :

Code :

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

1
2
 
$IsDo = mysql_query('SELECT * FROM toto WHERE id="'.mysql_real_escape_string($_GET['donnelabmda']).'"');

Le but étant d'avoir toujours des guillemets qui entoure les valeurs donné à MySQL provenant de variable non sur (variable saisie par l’utilisateur ou pouvant être altéré tel que USER_AGENT)

Autrement dit, je pense qu'il serait bon de récapituler en classifiant les injections possibles de hackers en fonction de leur type (sans les écrire, pour ne pas donner de mauvaise idées). Exemples :

- Récupération de valeurs
- Introduction de valeurs
- Modification de requêtes
- ...

Avec un exemple de code montrant la protection à apporter à chacun d'entre eux.

J'ai cru comprendre qu'il faut avant tout séparer les variables users récupérant des valeurs de la table lors de requêtes (ou en introduisant), par des variables intermédiaires (puisque la valeur d'une variable est stockée en mémoire sur le serveur qui exécute le script - et donc inaccessible (à part localement par un admin voyou)).

D'où :

Code :

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

1
2
3
$id=intval($_GET['id']);
$requête=mysql_query("SELECT age FROM membres WHERE id=$id");

Maintenant, faire la part des choses sur l'utilisation des guillemets entre la syntaxe du code d'un côté et la sécurité au niveau injection de l'autre ne m'apparaît pas si évident que cela.

En effet, tes différents exemples ne mettent pas en évidence le rapport PHP/Mysql qui nous intéresse ici.

Merci de bien vouloir (à qui voudra bien) faire un récap structuré avec des étapes claires en fonction du type de risque. On pourrait d'ailleurs mettre à chaque étape "A faire", et "A ne pas faire". Une petite explication serait la bienvenue à chaque étape, pour bien identifier où se situe le risque.

C'est le but originel du POST et ça servira à d'autres.

Merci à vous tous.

[redoran]

En effet, tes différents exemples ne mettent pas en évidence le rapport PHP/Mysql qui nous intéresse ici.

367 affichages avec 24 post , vue l'importance du sujet chaque élément est important afin d'adopter une réaction de fond , et l'exemple sur utilisation des des guillemets toutes équivalentes se n'est que pour mettre en évidence leurs action ensuite sa reste a voir leurs effets sur les requêtes.
je crois que le problème de sécurité dépasse de loin les guillemets.

[tse_jc]

Bonjour,

Je dois bien avouer que je suis très surpris de vos réactions, car il me semble humblement qu'il s'agit de choses fondamentales que le considère peut être à tort de problème de débutant. Enfin je me pose maintenant la question.

Peut être que le problème de la confusion viens en fait de l'utilisation de fonctions génériques dont finalement on ne prends pas trop la peine de savoir ce qu'elles font exactement (peut être le café aussi?^^) et on se fie aveuglément à ce qui est dit ou recommandé sans se soucier réellement des véritables enjeux et contraintes de nos développements.

Je vous fais un copier coller d'une recommendation que j'avais faite dans un autre forum pour comprendre de façon générale comment doit être construit un code:

Quand vous développez une fonction pour accomplir une tache A à partir d'un paramètre p (ou plusieurs)
1) La fonction ne sait pas ce qu'est p si ce n'est un paramètre : Assurez vous de la bonne valeur du paramètre p avant de le valider et retourner un message d'erreur ou un Numéro d'erreur pour chaque mauvaise valeur de p qui est tentée d'être passée à la fonction.
2) Une fois qu'on est sur de la valeur de p ainsi que de son format, sa nature, etc... traiter l'information donnée par le paramètre avec une gestion d'erreur associée à tous les stades du processus.
3) retourner la valeur de resultat de la fonction d'une manière standard (date, etc...), et réserver un rendu particulier de valeur qu'au moment de l'affichage.

Dit différemment il ne faut jamais faire confiance aux paramètres reçus du côté PHP (et idéalement côté SGBDR aussi mais il s'agit d'un autre débat).

Je vais essayer donc de donner une méthodologie dans le contexte donné ici qui est le rapport PHP/MySQL.

Il faut prendre conscience avant tout que le contexte PHP/MySQL ne crée pas de contexte spécifique particulier à partir du moment où l'on code comme l'on doit coder c'est à dire en s'assurant à tous les stades du programme de la qualité de l'information traitée.

Une injection SQL c'est quoi de façon générique?
C'est le passage d'un paramètre à une requête SQL dont le contenu, la valeur n'est pas celui/celle qui est censé(e) être reçu(e) par cette requête.

Donc une mauvaise valeur de paramètre peut être
1) Sans incidence pour la sécurité de l'application
2) Peut provoquer des dommages considérables (accès non autorisé, etc...) : c'est de ce cas dont il s'agit quand on parle communément d'injection SQL.

La méthode à appliquer pour éviter des injections devrait être maintenant claire pour tout le monde. Mais détaillons tout de même.

Que sont d'abord les variables $_GET, $_POST, $_REQUEST, etc.. ou encore les paramètres d'une fonction php? (ex: function myfn($p,$q){ } )

Ce sont des paramètres publics pour votre application et donc des paramètres dont vous ne pouvez pas connaître leur contenu dans l'absolu. Pensez le contraire, et tôt ou tard votre application connaîtra des problèmes de sécurité voire d'injection.

Première règle "anti-injection"
Ne jamais passer ces paramètres directement en validation de traitement (cf quotes du post précédént).

Voyons les autres "règles" par l'exemple.
1) cas d'un entier (valeur censée être récupérée) passée en $_GET (méthode à adapter et à appliquer pour toute variable publique).
Pour éviter de générer aussi des erreurs on va regarder ce qu'elle contient.

Code php :

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

1
2
3
4
 
if (isset($_GET['id'])){$id=intval($_GET['id']);}else{$id=0;} // on s'assure ici que la variable existe, auquel cas on la re-type comme entier et quelque soit le contenu de $_GET['id'] on aura bien un entier dans $id, sinon on initialise notre variable locale $id (qui est une recommendation aussi et évite bien des heures de débogage inutilement)
// on peut maintenant passer notre variable locale $id dans notre requête car on est certain de son contenu
$sql="SELECT id, colonneA, colonneB FROM MYTABLE WHERE id=$id";

2) Pour les chaînes de caractères
Le cas est un peu plus complexe car retyper une chaîne de caractères ne permets pas de s'assurer de sa bonne valeur. Il faut donc étendre notre traitement. Celle que je préfère, et déjà évoquée précedemment, est d'utiliser une expression régulière car elle est suffisante et à l'avantage dans un contexte de base de données, de contrôler la qualité de l'insertion ou la mise à jour dans la base: on s'assure en plus du contenu que le format d'écriture de la donnée est conforme à notre standard d'écriture choisi dans la base. Donc elle a bien un double avantage non négligeable.

Que faire lorsque aucun pattern de contenu n'est applicable? c'est à dire quand il ne s'agit pas d'un numéro de téléphone, de pays, bref de donnée déjà définie par un standard quelconque ou un standard propre à votre application?
Il suffit tout simplement de convenir au niveau applicatif, en prévenant l'utilisateur, des caractères qui ne sont pas acceptées à la saisie. Vous pourrez ainsi vérifier leur présence via une expression régulière et ainsi une valeur de type "1 OR 2<>3" n'a plus de raison d'être présente.
On aurait donc

Code php :

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

1
2
3
4
5
6
7
8
 
if (isset($_GET['chaine'])){$mychaine=$_GET['chaine'];}else{$mychaine="";}
if (!preg_match($pattern,$mychaine)){throw exception('erreur dans paramètre $chaine');}
// arrivé ici on est certain que le contenu de $mychaine est conforme à nos attentes et par conséquent est SAFE pour l'application.
// cependant si les guillemets ou les apostrophes sont acceptés dans le pattern, il faudra les echapper pour eviter une erreur SQL à l'insertion ou à la mise à jour
$mychaine=addslashes($mychaine); // si la chaîne peut contenir des apostrophes ou des guillemets. (peut être remplacé par QUOTE() dans la requête).
$mychaine=utf8_encode($mychaine); // si necessaire.
$sql="SELECT id, colonneA, colonneB FROM MYTABLE WHERE colonneA='$mychaine' ";

Vous l'aurez compris donc pour la question des guillemets posée initialement il s'agit tout simplement d'un problème de syntaxe d'écriture de PHP qui n'a rien à voir avec l'injection de près ou de loin.

J'espère n'avoir rien oublié et que maintenant tout est clair pour ceux que cela interesse^^.

[tse_jc]

Un petit complément d'information qui n'est qu'un simple avis personnel si vous me le permettez concernant le lien fourni (je ne sais plus par qui) mais qui est celui-ci :
http://stackoverflow.com/questions/6...ection-in-php/

Faire des requêtes préparées en ayant pour seul objectif d'éviter les injections SQL n'est pas une bonne pratique en soi. Ceux qui la prônent c'est encore et une fois de plus les partisans du moindre effort. C'est ceux qui pensent que tout ce que l'on viens de dire = OSEF je fais nimp et comme je veux et à la fin, hop, une petite requête préparée et le tour est joué plus d'injection SQL.

Une requête préparée en SQL, sans rentrer dans les subtiles différences, c'est un peu comme lorsque l'on fait du currying en javascript (sur l'ensemble ou partie des paramètres en SQL et sur partie uniquement des paramètres en Js). L'intérêt primaire d'une requête préparée est de pouvoir rejouer la requête et donc le même plan de requête successivement avec des paramètres différents, beaucoup plus performant qu'un

Code php :

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

1
2
for($a=0;$a<1000;$a++){mysql_query("INSERT INTO MYATABLE (colonneA) VALUES ($a)");}

même en proc stock.

Déjà qu'en proc stock on est obligé de passer par une requête préparée pour toute requête statique générée dynamiquement (sauf à utiliser les user variables), et pour toutes les requêtes dynamiques. C'est largement suffisant.

++




En effet si on veut être certain du comportement d'une application et que l'on a besoin de garantir cela à un client, il faut le vérifier soi même.

[redoran]

@ tse_jc
selon la doc php.net les requêtes préparées :

La requête ne doit être analysée (ou préparée) qu'une seule fois, mais peut être exécutée plusieurs fois avec des paramètres identiques ou différents. Lorsque la requête est préparée, la base de données va analyser, compiler et optimiser son plan pour exécuter la requête. Pour les requêtes complexes, ce processus peut prendre assez de temps, ce qui peut ralentir vos applications si vous devez répéter la même requête plusieurs fois avec différents paramètres. En utilisant les requêtes préparées, vous évitez ainsi de répéter le cycle analyse/compilation/optimisation. Pour résumer, les requêtes préparées utilisent moins de ressources et s'exécutent plus rapidement.
Les paramètres pour préparer les requêtes n'ont pas besoin d'être entre guillemets ; le driver le gère pour vous. Si votre application utilise exclusivement les requêtes préparées, vous pouvez être sûr qu'aucune injection SQL n'est possible (Cependant, si vous construisez d'autres parties de la requête en vous basant sur des entrées utilisateurs, vous continuez à prendre un risque).

donc double jeu sur plan optimisation et sécurité.
avec PDO: un des avantages c'est les exceptions.
mais je crois que c'est une partie d'un tout

[tse_jc]

Rien de cette citation va à l'encontre de ce que j'ai dit. Mais ce qu'il n'y est pas dit c'est qu'à la préparation de la requête, PDO mets plus de temps à mettre la requête en place qu'une requête non préparée. Donc si c'est pour n'exécuter qu'une seule fois chaque requête c'est contre performant à plus d'un titre:

- Chaque requête est beaucoup plus longue à être traitée au niveau de PHP
- La gestion des variables applicatives devant de toute manière être faite dans de bonnes conditions avec ou sans PDO, il n'y a aucune raison d'utiliser les requêtes préparées avec PDO dans un contexte autre que de rejouer plusieurs fois le même plan de requête.

++

[redoran]

PDO mets plus de temps à mettre la requête en place qu'une requête non préparée

par rapport au bénéfice acquis sur le plan sécurité et optimisation c'est en milliseconde

il n'y a aucune raison d'utiliser les requêtes préparées avec PDO dans un contexte autre que de rejouer plusieurs fois le même plan de requête.

.
là je crois que c'est a revoir non !!!!

[tse_jc]

ca peut aller sur la mise en place jusqu'à 80% de temps en plus que la même requête non préparée. Après tu fais comme tu veux, voire n'importe quoi et continuer à faire ce qui est à la mode et résoudre tes lacunes de codage par une requête préparée miracle qui n'a pas de raison d'être dans le contexte. J'ai dit tout ce que j'avais à dire sur ce sujet.

[redoran]

continuer à faire ce qui est à la mode

et évolution technologique basée sur de bon arguments sa fait deux non !!!

[tse_jc]

Si vous avez des arguments plus pertinents et fondés que tous ceux que je vous ai fournis précédemments (je vous invite à relire au cas où), je suis tout oüi et preneur, car pour le moment les vôtres sont inexistants dans un contexte utile, performant et constructif.

EDIT: et non redondant.

[redoran]

Si vous avez des arguments plus pertinents et fondés que tous ceux que je vous ai fournis précédemment

j'ai rien contre vos propos , je voulai simplement un plus au post.
pdo : http://fmaz.developpez.com/tutoriels...omprendre-pdo/

[grunk]

ca peut aller sur la mise en place jusqu'à 80% de temps en plus que la même requête non préparée. Après tu fais comme tu veux, voire n'importe quoi et continuer à faire ce qui est à la mode et résoudre tes lacunes de codage par une requête préparée miracle qui n'a pas de raison d'être dans le contexte. J'ai dit tout ce que j'avais à dire sur ce sujet.

Salut,

On est bien d'accord sur le fait qu'il ne faut jamais faire confiance aux données de l'utilisateur et qu'il faut au maximum retyper les données reçues.

Mais dans le cas d'un champs texte "libre" comment peux tu garantir la sécurité des données (à l'insertion) sans passer par une requête préparée ?

Sachant qu'en général on essai de stocker des données brutes dans la base et que par conséquent les fonctions de filtrages/transformation ne sont pas les bienvenues ( à ce moment précis).
Sans compter qu'avec les REGEX on va pouvoir relativement simplement contrer une attaque simple du style "1 OR 2<>3" mais pas forcément une codée en unicode ou en ascii par exemple.

[redoran]

un peut de lecture http://web.developpez.com/tutoriels/...plication-web/

[grunk]

un peut de lecture http://web.developpez.com/tutoriels/...plication-web/

Cet article est à éviter ! , comme je l'ai souligné dans les commentaires , il est plein de graves erreurs (toujours pas corrigées d'ailleurs) pour un article souhaitant traiter de ce sujet.

[tse_jc]

Bien que dans l'absolu on puisse filtrer un encodage avec une regexp, et que cet exercice necessite un certain savoir faire, c'est indéniable, et au delà du fait que normalement un utilisateur connecté doit aussi comprendre que tout n'est pas acceptable non plus de sa part vis à vis d'une application (il y a toujours des contraintes à respecter pour rendre des choses possibles), pour répondre intrinsèquement à

Mais dans le cas d'un champs texte "libre" comment peux tu garantir la sécurité des données (à l'insertion) sans passer par une requête préparée ?

j'appliquerais la méthode suivante :
1) encapsulation de contenu pour rendre inopérant tout contenu malveillant éventuel
2) soumission de ce contenu à un modérateur pour validation définitive dans la base.

Ce qui faut bien le dire pour que les choses soient claires, ce cas de figure représente une contrainte rare (par expérience) qui lorsque elle est imposée, comme par magie, des solutions sont trouvées dans l'heure par les clients pour qu'il n'y ait pas de modération à faire...

++

[ericd69]

perso je soutiens tse_jc là dessus...

la requête préparée ne sert pas de sécurité du tout... elle n'a en effet d'utilité réelle que si on veut faire une répétition de la requête...

après utiliser les fonctions de bind sur les variables de la requête à des fins de sécurité ne garantissent que le typage et un échappement simple par \ fait le job mais ne garanti pas de passer des valeurs hors définition...



maintenant je rappelle qu'on peut le contrer...

après c'est pas les méthodes d'échappement qui manquent (remplacement par entités html, par code unicode, etc...)

je suis aussi favorable à traiter la luttes contre les injections avant d'arriver à la requête à à refaire un test en aval coté sql pour les chaines si besoin...