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?