Discussion :

[ascito]

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.

Je parle exp�rience;

une requ�te dite complexe en pdo, pour moi commence en la jointure de 3 tables ( T1.id , T2.id , T3.id ) , la �a m'� pos� des probl�mes donc j'ai fais des requ�tes pr�par�s plus simple, ( T1.id , T2.id ) as id puis ( id , T3.id );

Pour moi une requ�te mysql d�compos� de la m�me fa�on prenais plus de 30 s ( voir un bad complet ) , et l� avec PDO moins de 2s...

Donc si tu te tiens � d�composer les requ�tes , plus qu'� les rassembler , c'est optimum, avec mysql � l'�poque, et avec PDO maintenant. Cela dit je fais un exemple qui prends pas en compte le moteur complexe mysql...

Donc PDO et la citation confirme mon v�cu. � vous de voir.

[ericd69]

l�, je pense que ton probl�me venait de l'�criture de la requ�te... tu peux souvent utiliser des subtilit�s d'�criture voir forcer l'ordre des jointures...



L� encore, on pourra toujours avoir des contre-exemples ou le connecteur mysql ou mysqli serait soit disant plus performant...

je pense que le simple argument suffisant et n�cessaire au passage inconditionnel � pdo est juste la volont� d'abandon pure et simple des 2 autres extensions et leur non mise � jour depuis un certain nombre de version de php d�j�... donc:

• risque de bug grandissant avec l'�volution du sgbd plus prise en compte
• la gestion de l'�chappement ne va plus �tre accessible en terme de r�glage dans php... et donc des risques de sales surprises pour certains qui maitrisent pas toujours bien le fonctionnement de addslash et stripslash

[ascito]

l�, je pense que ton probl�me venait de l'�criture de la requ�te... tu peux souvent utiliser des subtilit�s d'�criture voir forcer l'ordre des jointures...

La la bdd c'est moi qui la m�ne depuis 5 ans, simple, enfin , plus simple c'est pas possible, cl� �trang�re virtuel pour les script etc... M�me base depuis plus de 5 ans, et �volution des m�thodes d�acc�s, mais la bdd change pas ....
Donc, quand je dis ca , c'est juste que conceptuellement, j'ai certaines exp�riences, et que au niveau s�curit�, exp�rience, pro, tout ce que tu veux, c'est PDO pour un site transactionnel simple et �labor� le plus ADEQUAT...

[stealth35]

Faut pas oublier que les requ�tes pr�par�es (avec mysql) sont d�sactiv�s par d�faut avec PDO.
Et comme le dit tse_jc � part en requ�te d'insertion en masse, les requ�tes pr�par�es ne servent pas a grand chose.
Niveau s�curit� c'est juste qu'il faut bien comprendre comment marche cette m�thode, en tout cas ce n'est pas dutout son but.
En ce qui concerne l'extension mysql_*, on pouvais tr�s bien faire des requ�tes pr�par�es avec https://github.com/stealth35/mysql_prepare

[ericd69]

@stealth35
heureusement c'est quand une des fonctionnalit�s de base
si tu vas par l� tu peux m�me faire des appel � des proc�dures stock�e avec les derni�res version des mysql_ ... car y a une astuce pour faire de la bufferisation de plusieurs requ�tes pour 1 seul appel...

@ascito
quand je te parle d'astuce d'�criture de ta requ�te, ce que tr�s souvent tu peux la r��crire de mani�re astucieuse et �viter que parfois l'optimiseur fasse des siennes... et �a tout le monde sait largement pas le faire...
et je te rappelle que j'arr�te pas de dire qu'il faut abandonner mysql_ et mysqli
pour tout un tas de raisons dont la praticit� ou de fonctionnalit�s...
perso j'utilise plus que �a depuis plus de 3 ans

pour info lisez bien la doc de pdo et mysql, mysqli, vous aurez des surprises sur la fa�on dont sont impl�ment�s les requ�tes pr�par�es par leur commandes sp�cifiques:

• elles ne sont pas compil�es par le sgbd mais par l'extension...
• elles n'utilisent donc pas forc�ment l'optimisation...

d'o� le fait que tu puisses aussi avoir des soucis de performance que tu n'aurais pas forc�ment si tu ex�cutais les commandes sur le sgbd...

perso j'ai pas le probl�me, j'utilise que pdo->query pour mes appels de proc�dures stock�es donc je suis sur que ce que je fais n'est pas tritur� de mani�re interm�diaire

[tse_jc]

Bonjour

avec les derni�res version des mysql_ ... car y a une astuce pour faire de la bufferisation de plusieurs requ�tes pour 1 seul appel...

Je ne suis pas certain d'avoir bien compris ce dont tu parles. Tu pourrais d�velopper un poil histoire d'�tre certain de ne pas passer pas � c�t� d'un truc important?

Merci

[ericd69]

oui dans les derni�res versions de mysql tu pouvais d�bloquer le multi-requ�te (permettant du coup les proc�dures stock�es) avec un r�glage sur la commande de connexion...

je l'utilisais avant de passer � mysqli puis pdo... il y a bien longtemps

[tse_jc]

En effet, j'�tais pass� � c�t� de �a.. merci en tout ca.

[ericd69]

pour la culture de tous: doc constantes pour le client mysql...
lire le 1er commentaire � la fin de la doc...

enfin �a n'a plus gu�re d'int�r�t...

[redoran]

afin de permettre de d�finir quel est le bon moyen de se prot�g� ou simplement �voqu� le probl�me de s�curit� d'une application ou une unit� de code de cette application et selon les diff�rentes r�ponses du post par diff�rentes comp�tences , l� je crois que je me retrouve plus ; y 'a des vas et viens ou des ressacs.
vuln�rabilit� - m�thode de protection

c'est une �quation qui permet de comprendre le risque afin de d�veloppez une m�thode de d�fense de font.
l� aussi surgi un autre probl�me : degr� d�efficacit� de la m�thode!!!!!
exemple:
requ�te qui attend un param�tre chiffre:
soit on v�rifier le param�tre par le regex ( gourmand en ressource),
soit avec Bindvalue .....
exemple2:
requ�te d�identification ( user , password).
l� on pr�conise les �chappements.
ou PDO + requ�te pr�par�e.
la liste est longue.....
donc faut identifier le probl�me afin de trouver la bonne solution.
et la bonne solution qui reste le domaine des sp�cialistes de la s�curit� qui sont cordialement invit�s a participer a ce post.

[tse_jc]

c'est une �quation qui permet de comprendre le risque afin de d�veloppez une m�thode de d�fense de font.
l� aussi surgi un autre probl�me : degr� d�efficacit� de la m�thode!!!!!
exemple:
requ�te qui attend un param�tre chiffre:
soit on v�rifier le param�tre par le regex ( gourmand en ressource),
soit avec Bindvalue .....
exemple2:
requ�te d�identification ( user , password).
l� on pr�conise les �chappements.
ou PDO + requ�te pr�par�e.
la liste est longue.....
donc faut identifier le probl�me afin de trouver la bonne solution.
et la bonne solution qui reste le domaine des sp�cialistes de la s�curit� qui sont cordialement invit�s a participer a ce post.

La d�marche a beau �tre louable, parfois on se demande, si le temps qu'on a investi � expliquer en d�tail les choses, � servi � quelque chose. Ma consolation en tout cas pour ce post c'est que je suis a peu pr�s certain que ca a profit� au moins � une personne. Mais bon...

Alors je le dit et je le r�p�te, il ne peut pas y avoir plus clair que ce qui a �t� dit et abord� dans ce post. Mais voil�, ca semble ne pas vous convenir parcequ'il n'y a rien de simple ni de solution passe partout qu'on puisse utiliser sans se fatiguer, du moins c'est l'impression que vous donnez.

Tout ce qui a �t� dit, c'est des contraintes, du temps de d�veloppement, de la m�thode et de l'organisation, c'est certain.

Pour la regex, le "c'est gourmand en ressource" pour pseudo justifier de ne pas l'utiliser car cela fait partie des notions complexes � ma�triser de php c'est tr�s passable. En dehors du cas de figure ou un str_replace est plus adapt� � une regex, sachez qu'il existe des op�rateurs non gourmands et des techniques qui limitent fortement les consommations de ressources inutiles.

Mais je pense que si vous faites l'impasse sur de telles notions, vous limitez consid�rablement vos possibilit�s de dev car beaucoup de choses d�pendent de sa ma�trise : spiders, crawlers, rewrite, parseurs, etc...

Je vous invite donc � relire tout ce qui a pu �tre dit dans ce post et sur ce site.

++

[redoran]

si le temps qu'on a investi � expliquer en d�tail les choses, � servi � quelque chose. ...

l� y a eu de la dimension par rapport au post.

Alors je le dit et je le r�p�te, il ne peut pas y avoir plus clair que ce qui a �t� dit et abord� dans ce post. Mais voil�, ca semble ne pas vous convenir parcequ'il n'y a rien de simple ni de solution passe partout qu'on puisse utiliser sans se fatiguer, du moins c'est l'impression que vous donnez.

c'est votre avis et je le respect pas besoin d'entr� dans ce cercle.

Tout ce qui a �t� dit, c'est des contraintes, du temps de d�veloppement, de la m�thode et de l'organisation, c'est certain.

sa ce voit dans les propos des intervenants d�o� l�int�r�t de ce type d'intervention.

Je vous invite donc � relire tout ce qui a pu �tre dit dans ce post et sur ce site.

merci pour le conseil
personnellement sa ma permet de voir vol� s�curit� par rapport aux injections avec un autre angle.

[ABCIWEB]

je pense que le simple argument suffisant et n�cessaire au passage inconditionnel � pdo est juste la volont� d'abandon pure et simple des 2 autres extensions et leur non mise � jour depuis un certain nombre de version de php d�j�...

L'abandon du d�veloppement de l'extension mysql est annonc�e depuis assez longtemps par contre jamais vu de document "officiel" concernant l'abandon de mysqli, en tous cas ce n'est pas ce qu'indique cette page. Rumeur ou r�alit� ?

Sinon pour le reste de ce sujet, je suis de ceux qui utilisent les requ�tes pr�par�es uniquement si n�cessaire (requ�tes multiples dans une boucle par exemple).
D'un autre c�t� je comprends qu'on puisse aussi pr�coniser aux d�butants d'utiliser les requ�tes pr�par�es pour se prot�ger des injections sql. Mais de l� � ce que cela devienne une r�gle imp�rieuse du genre "sans cela point de salut", cela ressemble assez � un abandon de comp�tences. Et comme d�j� dit, cela peut s'av�rer contre productif dans certaines circonstances.

[redoran]

...cela ressemble assez � un abandon de comp�tences. Et comme d�j� dit, cela peut s'av�rer contre productif dans certaines circonstances. ...

autrement dit explicitement svp.

[tse_jc]

@redoran :

autrement dit explicitement svp

Et bien soit.
Que signifie tout ce qui a �t� dit dans ce post? Si on devait le r�sumer, que devrait-on en retenir?

Lorsque l'on effectue un contr�le syst�matique de type de contenu et de d�finition de chaque variable publique de son application, l'injection n'y est plus possible.

Si on part du principe qu'appliquer cette m�thode rel�ve d'une comp�tence certaine, la remplacer par une autre ou d'autres moins contraigantes, peut � juste titre, �tre per�u pour un abandon de comp�tence, avis que je partage � 100% d'ailleurs.

Si vous avez bien not� la d�finition que j'ai donn� pr�cedemment de l'injection, vous vous rendrez compte qu'elle n'est pas sp�cifique � SQL mais peut aussi s'appliquer � votre code PHP, et parfois peut engendrer des cons�quences tout aussi dramatiques qu'une injection SQL.

++

[redoran]

@ tse_jc:
donc faut attendre a une attaque de n'importe quel angle.
donc l�id�al faut faire des barri�res ou des ripostes par niveau d'attaque.
la aussi faut comprendre le processus d'intrusion !!!!
exemple cas d'injection sql:
faut faire un nettoyage des variables avant d'entr� dans le corps de la requ�te.
ou au moment de la pr�paration d'ex�cution de la requ�te.
ici on a deux moments diff�rents ; aussi reste de d�termin� quel est la meilleur m�thode a utilis� entre ce qui est dans la doc et ce qui rel�ve de l'exp�rience !!!!

[stealth35]

La meilleur m�thode est de pas chercher la m�thode mais de comprendre les chose et ne pas �tre feignant, oui faire du code s�curis� est chiant et long � faire, mais c'est � faire. Y'a pas de miracle y'a que du travaille.

[tse_jc]

Merci stealth35



Sinon, pour d�velopper un peu plus loin, philosophiquement parlant, si je peux dire ainsi, le but n'est pas de dresser des remparts contre des niveaux d'attaque identifi�s ou pr�d�finis, on n'est pas en train de configurer un r�seau non plus.


L'objectif quand on d�veloppe une application et en adoptant de telles pratiques est simple: il est de stabiliser son application, minimiser le risque de bug et d'�tre le plus fiable possible. C'est ainsi qu'il faut voir les choses.

Il ne faut pas oublier que si ce travail n'est pas correctement fait, la factorisation du code (de mise et incontournable), va contribuer � augmenter et diversifier les contextes d'appels internes publics et � fragiliser la stabilit� du code.

La POO gr�ce � l'encapsulation contribue � faciliter cette factorisation en limitant l'exposition du code et en donnant les outils pour g�rer les contextes d'une mani�re structur�e et ais�e.

++

[redoran]

La meilleur m�thode est de pas chercher la m�thode mais de comprendre les chose et ne pas �tre feignant

dans le domaine du d�veloppement les comp�tences diff�rents , et chaque produit et le d�but de naissance d'un autre ( dont comprendre les choses fait partie..) alors pourquoi r�invent� la roue sauf l'am�lior�.

�tre feignant

c'est d..

ui faire du code s�curis� est chiant et long � faire, mais c'est � faire. Y'a pas de miracle y'a que du travaille.

j�adh�re a ce principe.

le partage d'opinion est la cl� maitresse de cette r�ussite.

[redoran]

Ok ; restant dans les injections sql.
d�butant en d�veloppement web (php/mysql / notepad) , avoir fait un grand tour sur la doc , et comme par hasard je decouvre quelque chose qui s' appel requ�te pr�par�:

....Le SGBD va pr�parer (interpr�ter, compiler et stocker temporairement son "plan d'ex�cution logique" (merci doctorrock)) la requ�te.

ensuite :

....Alors pourquoi diable a-t-on invent� les requ�tes pr�par�es ? Eh bien, exactement pour la m�me raison que nous avons invent� les syst�mes de templates : pour isoler les donn�es du traitement.

ainsi :

impose une certaine rigueur de programmation ;
optimisation du temps d'ex�cutions requis pour les requ�tes ex�cut�es plus d'une fois ;
plus grande s�curit� au niveau des requ�tes.

aussi

Les requ�tes pr�par�es sont plus s�curis�es, vraiment ?
Ce qui peut se traduire par : � Pr�venir les injections requiert de s�parer les donn�es non s�res des commandes et requ�tes. �

Et �a tombe bien ; c'est tr�s pr�cis�ment ce que font les requ�tes pr�par�es : s�parer les donn�es de la structure de la requ�te !

source : http://fmaz.developpez.com/tutoriels...omprendre-pdo/

c'est l'un parmi des articles qui parle des requ�tes pr�par�s et leurs r�le sur le plan s�curit�.

alors comment faire un choix?