Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
débutant en développement web (php/mysql / notepad)
Ensuite, c'est visiblement encore un qui n'a compris que ce qu'il a voulu comprendre.
Ce qui m'inquiète est que vous n'êtes visiblement pas capable de différencier deux arguments et de vous faire votre propre opinion en toute objectivité.
oui merci pour le complément
j'attacherai de revoir le module de sécurité d'une application web
Or ce que l'on vient de vous expliquer, se résume à dire que cette définition n'est pas pertinente etPreventing injection requires keeping untrusted data separate from commands and queries.
Source :http://www.owasp.org/index.php/Top_10_2010-Injection
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. »
"un doute sur les paramètres? => pas de requête". Donc à partir du moment où on vérifie soit même, pas besoin de PDO pour le faire quand surtout il n'est pas capable de contrôler la pertinence des données reçues vis-à-vis du modèle.
Y en a qui ont la tête dure^^
++
les tutos c'est comme la doc, tu n'est jamais à l'abri d'une erreur...
Je vais essayé d'être clair...
en pratique, il y a 2 types de requêtes préparées:
- celles que tu génères par l'extension du langage appelant (méthodes ou fonctions dédiées selon l'interface). elles le sont au niveau du driver SGBD puis envoyé au SGBD
- celles que tu génères au niveau du SGBD directement...
ça implique quoi?
- certaines actions interdites dans les requêtes préparées au niveau SGBD sont faisables au niveau driver parfois
- le processus de préparation n'est pas le même (tu as pas forcément la même phase d'optimisation par exemple)
- la version préparée n'est pas stockées dans le SGBD si elle est générée par le drivers
- des écarts de performances considérables peuvent apparaitre entre les 2 façons de faire
la SEULE façon d'isoler le sql du langage appelant est l'utilisation des procédures stockées avec une politique de sécurité particulière (un utilisateur sql avec seulement "GRANT EXECUTE" coté langage appelant) et une gestion des actions interne aux procédures (passage d'un token ou d'un identifiant/mdp en paramètre des procédures faisant des modifications sur la bd)
en procédant ainsi, tu n'as plus que des appels aux procédures et impossibilité d’accéder directement à la bd ou sa structure... de plus, les requêtes n'apparaissent plus au niveau du langage appelant... donc tu as bien isolé le SQL...
rien à voir avec les requêtes préparées tu vois...
ATTENTION!! cela ne veut pas dire que tu ne dois pas vérifier la cohérence des paramètres passés aux procédures
Avec ce que tu viens de dire, je crois qu'on va à nouveau le perdre^^. Mais bon maintenant qu'on y est, je vais en rajouter une couche
Passer exclusivement par des proc stocks, est effectivement et définitivement le mieux, et puis le jour où on n'a plus une ligne de sql côté php on ne peut plus s'en passer^^. Mais la contrepartie c'est comme viens de le dire eric, c'est qu'il faut être intraitable sur le contrôle qualité des paramètres passés, bref faut être en tolérance zéro.ATTENTION!! cela ne veut pas dire que tu ne dois pas vérifier la cohérence des paramètres passés aux procédures
D'ailleurs passer par un token dans les proc d'update ou d'insert, merci eric, je suis déjà fan
++
Petit oubli. En général les dev PHP sont habitués à travailler exclusivement avec des arrays au niveau des paramètres de requêtes surtout quand le nombre de paramètres à traiter est important (30+ par exemple).
Et comme en proc stock les arrays n'existent pas, en général ils renoncent car cela nécessite des techniques particulières et la difficulté leur semble insurmontable.
A ce propos j'ai commencé à faire un topic sur un autre fofo, que j'espère pouvoir continuer sur celui-ci bientôt.
là je suis en train de pondre un tuto sur le procédural dans mysql
après je verrais à en pondre un sur cette pratique de sécurité un peu plus sérieuse que ce qui a été présenté au début
et là encore je vais répété un truc c'est que l'échappement simple via \ n'est pas toujours une bonne idée car on peut le contourner... il est préférable de faire des substitutions dans les caractère litigieux... c'est pas les méthodes qui manquent...
et là impossible même si le texte fournit à la requête est une requête sql aussi de faire des injections...
l'autre avantage du procédural avec un utilisateur qui ne peut qu'exécuter des procédures:
- aucun accès possible hors les procédures, aucun show, select,etc... aussi bien dans les versions proposées par le driver que sur le SGBD
- pas de possibilité de passer une requête en paramètre de la procédure pour cet utilisateur...
- c'est les droits du "definer" de la procédure qu'on peut utiliser pour tout ce qui est exécuté dans la procédures
aucun cms couramment utilisé pour la création web (à ma connaissance) n'est programmé comme ça...
et on s'étonne toujours du nombre de hacks régulièrement trouvés pour chacun d'eux... cherchez l'erreur
Quand ta chaîne est traitée et considérée comme "propre" dans ta procédure et qu'elle accepte les quotes (simple ou double ou les deux) il faut bien les echapper dans tous les cas. De toute manière si elle n'est pas échapée l'appel de la procédure ne passera pas, et une fois les données validées par la procédure, personne ne peut intervenir entre le moment où elle est validée et que le traitement commence car on est dans la procédure. Entre nous, que l'échappement puisse être contourné, dans un contexte proc stock, je m'en fou un peu, ca ne peut rien changer de toute manière.
++
sauf quand tu fais des dump version sql comme proposé dans phpmyadmin, là ça peut être dangereux selon ce que tu utilises pour exécuter le code généré ...
tu sais que tu peux faire une extraction de chaine plus efficace avec un appel à une requête préparée et la fonction elt() dans une boucle toute simple pour lire un tableau sous forme de chaine...
après faut aussi rappelé que un tableau ça revient à une table temporaire avec le moteur memory aussi si tu dois traiter toutes ces valeurs en une ou plusieurs fois
en réponse au #64
requêtes préparées vs procédures stockées ,
donc il faut bien différencier les deux,
(Par contre, le moteur SGBD va se servir de C de plus en plus, et donc traiter indifféremment l'un et l'autre...: lecture annexe );
pour l'instant il paraît intelligent de différencier clairement ces deux manières de faire, et donc dans tous vos Topics, dire soit procédures stockées ( en sql par exemple), soit requêtes préparées ( en php par exemple ) ;
ce n'est pas très clair dans les réponses en général, pour ma part, et surement pour les novices aussi..
c'est pas encore ça pour te le prouver...
tu peux faire des requêtes préparées dans une procédure stockées...
pour le c dans les procédures stockées ça fait des années qu'ils le prévoient
mais si tu veux faire du c pour étendre les fonctions de mysql tu as les UDF
@Ascito : Oui eric à raison de le notifier, les requêtes préparées n'ont rien à voir avec les procédures stockées, il ne faut pas mélanger.
@Eric: Je serais curieux de faire des benchs comparatifs sur nos deux méthodes. Avec ELT() la tentation de retomber dans les pièges qui font l'objet de ce post sont grandes.Envoyé par ericd69
tu sais que tu peux faire une extraction de chaine plus efficace avec un appel à une requête préparée et la fonction elt() dans une boucle toute simple pour lire un tableau sous forme de chaine...
Ce cas de figure mis à part, car ce n'est pas cela qui m'interesse maintenant, pour faire le point, faisons un petit comparatif:
1a) Ma méthode est déterministe : je ne lis que les paramètres attendus. Si d'autres sont passés, ils sont ignorés.
1b) On peut le faire aussi avec ELT() j'en conviens.
2a) Je vérifie le type en même temps, si le type ne corresponds pas, je lui affecte une valeur hors domaine dans le type attendu, je la contrôle immédiatement en sortie de vérification, et dans ce cas de figure, je génère une erreur et sort de la procédure dès la première erreur rencontrée dans la vérif. L'ordre des paramètres est choisi de manière à minimiser les traitements à ce niveau.
2b) On ne peut pas faire d'assignation dans la boucle, sauf à peupler une table temporaire en insert/select dont les colonnes sont définies dans l'ordre des paramètres. Il faut passer par un gestionnaire d'erreur pour traiter les erreurs de type à l'insertion, et en cas d'erreur supprimer la table temporaire et sortir de la proc. Le contrôle de type se fait en une seule passe pour tous les paramètres. Etant en MySQL on ne peut pas faire de contrôle de domaine sur la même passe (dommage).
3a) Je fait un contrôle qualité variable par variable dans le code.
3b) On peut faire ce contrôle en faisant une requête globale bourée de structures conditionnelles au choix, ou en faisant une requête par colonne (contre-productif pour ce dernier choix). Ici tu n'as pas le choix, on est en MySQL je le rappele (pas de contrainte CHECK sur la table).
Je pense que l'essentiel y est. Quelques remarques personnelles si tu me le permets.
- Bien que le nombre d'instructions de contrôle soient identiques dans ces deux cas de figure, le nombre de requêtes est limitée à sont strict minimum avec ta solution.
- Le fait qu'il s'agisse d'un insert sur une seule ligne, la validation de masse que permets ta méthode est à pondérer fortement je pense.
- Ma méthode permets l'encapsulation totale du process et ne sollicite pas de pose de verou quelconque durant le process de vérification.
- Concernant la tienne, étant obligé de travailler dans un contexte transactionné dès l'étape de vérification, à moins de générer un nom de table temporaire aléatoirement, je ne vois pas comment tu peux éviter le risque de contention autrement dans un contexte fortement concurrentiel.
Bien que l'on travaille uniquement sur une seule ligne, je pense que ton taux d'occupation RAM de ta méthode risque de ne pas avoir une courbe linéaire avec une augmentation des accès concurrentiels non plus.
EDIT: J'oubliais! A cause de l'obligation de passer en mode transactionnel dès la vérification des paramètres dans ta méthode, tu as l'avantage d'avoir une trace des tentatives d'insert dans le log binaire. Mais cela peut être un inconvénient selon le CDC, et va augmenter la volumétrie du log.
Je pense qu'on a là une bonne base de discussion
je te rappelle alors le fonctionnement d'une table temporaire...
elle n'est à considérer qu'au niveau de la session... donc comme tu ne pourras rien lancer d'autre parle fonctionnement des appels langage serveur/mysql avant la fin de la procédure sur cette même session... pas de problème de concurrence intra-session ou de collision de nom de table...@
en plus, si tu utilise memory tu accélère la table , certes au détriment du risque de perte si il y a panne du sgbd mais d'un autre côté tu t'en fout car le traitement ne serait pas validé avant le fin de transaction non plus, si tu plantais plus loin dans la procédure...
de toute façon une table temporaire serait dropée en cas de panne
la solution est juste un parcours plus simple d'une liste de valeur séparée par des virgules
et en effet, ça n'empêche en rien de faire les traitement souhaité à la volée
perso je suis pas trop pour passer les paramètres d'une procédure comme ça (à la mode php, qui est surtout utilisée par beaucoup comme une facilité et pas comme tu le vois dans les api pour du paramétrage complexe de passage de variable à une fonction ou parce que tu as réellement besoin d'un tableau simplement), j'utilise un tableau pour passer une liste de valeur d'un typage identique (genre tableau de points par exemple, etc...), ce qui remet ça dans une utilisation plus simple et facile à contrôler à tous les niveaux...
pour mémoire je te rappel que les transactions ne touchant que les tables innodb, les tables temporaires ne sont pas impactées par ça... sauf indirectement par des requêtes les liant à une action sur une table innodb bien sur
le seul défaut des procédures sur mysql c'est qu'elle sont compilées à la 1ère demande lors de la session et non à la création au niveau serveur... ce qui leur enlève un poil d'efficacité...
donc après en effet, les 2 techniques trouvent une équivalence pour certaines situations et des avantages à l'une ou l'autre pour des utilisations plus particulières...
après pour les logs c'est vrai que ça se discute surtout si tu as une activité importante...
Bonsoir,
Merci pour ton retour.
Désolé de te contredire, mais en MySQL une table de type MEMORY n'a pas de visibilité limitée à la session utilisateur contrairement aux variables utilisateurs qui elles sont détruites avec la session utilisateur.
En résumé, une table de type MEMORY une fois créée, est visible par tous les utilisteurs connectés sur la BD, et persiste jusqu'à ce qu'un DROP TABLE soit fait dessus, que le serveur crashes, ou jusqu'à ce qu'un mysql -stop ou -restart soit fait.
Tout comme une table innoDB elle est soumise aux accès concurentiels au même titre que n'importe quel autre table. Elles sont plutôt optimisées pour du read intensive (usage recommandé ex:cache en lecture) et peu pour du read/write tout court, car elles ne disposent pas de système de verrou au niveau ligne ni ne sont multi threadés pour limiter la contention au niveau accès concurrentiel.
Or dans notre cas de figure qui est de l'insert essentiellement on est dans un contexte où (si utilisée)
1) on fait du read/write à 50% et systématique.
2) on va mettre les accès concurentiels en file d'attente de part sa nature.
Ici ce n'est pas tout à fait vrai. Permets moi de rectifier tes dires.
Il ne faut pas confondre les transactions et la gestion des verrous dans un contexte concurrentiel.
En vulgarisant un peu mais pas trop, une transaction permets de valider un ensemble d'opérations lecture/ecriture comme une seule action sur la base. La conséquence pour les verrous est que la transaction va les maintenir en fonction du niveau d'isolation choisie pendant toute la durée de la transaction.
Par contre dans un contexte hors transaction (tables myISAM, MEMORY,...) si des opérations sont menées sur des tables ne les supportant pas et que des tables innodb sont impliquées, les opérations seront logguées mais ne pourront pas être considérées comme consistantes pour les opérations hors tables innodb (et autre moteurs supportant les transactions). Au delà de cela, cela n'empêche pas les accès concurrentiels de survenir, mais à la différence d'une transaction, les verrous seront posés le temps des traitements puis seront libérés au même titre que sur une table innoDB hors transactionnel.
Il est vrai par rapport à cela que moi même j'ai dérapé un peu niveau language dans mon post précédent et je m'en excuse auprès des puristes, mais le problème de la gestion des verous et de contention dans un contexte concurrentiel se pose avec ta solution.
++
@ ericd69donc faut manipulé avec prudence ; alors je me demande qui les valides !!!!les tutos c'est comme la doc, tu n'est jamais à l'abri d'une erreur...surtout ceux qui se trouve sur le site developpez.com qui est une référence dans la matière (pour les débutant , les étudiants , les amateurs , les experts et ......).
la barre est poussée un peut plus haut.
en résumé un avis de conduite a tenir ou a suivre pour pallier au phénomène des injections sql et surtout pas des tutos
allez, pour moi injection, c'est un code qui va faire des choses qui sont "CONTRE NATURE"
mais pour cela, il faut déjà qu'une de tes requêtes permette d’exécuter le code compromis...
alors vous allez me dire :
$string = 'exec( del * ) '; // donc un code corrompus
echo $string ; pour ma part, je vois pas dans quel cas de figure cela va exécuter le code, dsl
A partir du moment, ou tu caste trankil les données, en entrée et en sortie, dans un typage simple de données int, string , bool par exemple, je vois pas à quel moment ton code pourra devenir "CONTRE NATURE" ???
@tse_jc
erreur de ta part, mon cher tse_jc:
j'ai bien dit: "une table temporaire avec le moteur memory"Une table temporaire sera immédiatement effacée dès que la connexion se termine. Cela signifie que vous pouvez utiliser le même nom de table temporaire depuis deux connexions différentes sans risque de conflit entre les connexions. Vous pouvez aussi utiliser une table temporaire qui a le même nom qu'une table existante (la table existante est alors cachée tant que dure la table temporaire).
extrait de la doc
après, je suis pas ultra pointu en transactionnel SGBD subtile, mais je te rassure j'ai suffisamment bouffé de programmation processus, threads et autres sémaphores en c/c++ (linux et windows) pour bien saisir les concepts bas niveaux derrière
mais je crois qu'on a gravement dérivé du sujet de base
@ascito
là encore on revient à ce que moi ou tse_jc on a déjà dit
ça dépend ce que tu vises...
tu peux passer une chaine de caractère qui ne fera à priori rien en php mais qui une fois interprété:
- en sql va permettre de s'attaquer à la bd...
- en html va inclure du code malveillant
tiens une faille que pas tant de gens connaissent:
beaucoup de fonction codées en c en dessous interprètent un caractère dont le code ascii vaut 0 comme une fin de chaine mais pas php
si je remplace un de tes formulaires pour tenter de charger un fichier sur ton serveur parce que ton script le permet...
ça affiche bien:
Code php : Sélectionner tout - Visualiser dans une fenêtre à part echo"machin.php\0truc.jpg";
mais en fait pas mal de commandes liées aux fichiers vont voir:machin.php.truc.jpg
j'ai retesté cette vulnérabilité avec la version 5.3.9 de php, elle ne passe plus mais il faut se méfier avec des versions antérieures...machin.php
d'où ne jamais croire l'extension d'un fichier et toujours détruire un fichier dont le nom contient un \0 (là tu peux être sur que c'est pas ce que ça dit être)
toujours mettre les fichiers uploadés dans un répertoire ou l'exécution est impossible, jamais à 777 comme on le voit dans certains scripts
ne jamais faire d'actions sur les fichiers via un script qui prends le nom du fichier (ou dossier) en $_POST ou $_GET sans moult précautions et vérification
autre truc pas toujours connu le réglage du php pour la génération automatique des variables venant de données externes($_POST, $_GET, ...)
à la génération de ces tableaux super globaux tu as selon le réglage éventuellement la génération automatiques de tout un tas de variables:
$_GET['user'] ou $_POST['user'] vont automatiquement générer une variable $user...
c'est sensé facilité la vie des programmeurs mais en fait c'est juste un trou de sécurité
car admettons que tu n'initialises pas systématiquement la valeur de $user de ton code je te fais pas un dessin de ce qui se passe à l'utilisation...
donc ne jamais utiliser de variable sans les initialiser systématiquement
voilà des exemples d'injection de valeur coté php
tu as même une faille majeur de sécurité qui permet de lire le code php sur des sites qui exécutent php en mode cgi au lieu d'exécuter le code... lire ça en anglais
on pourrait citer plein d'autres choses mais ça ira bien déjà
bref c'est pas parce que tu ne vois pas forcément
ah oui, toujours mettre un index.html même vide dans tous les répertoires ou faire un .htacces à la racine du site qui empêche de lister ce qu'il y a dans les répertoires...
si on sait faire utiliser l'url rewriting et utiliser de fausses extensions (html au lieu de php par exemple) ou aucune pour empêcher le mec de facilement savoir quel langage tu utilises...
j'ai bien dit: "une table temporaire avec le moteur memory"Tu sais quoi? je n'avais pas vu que tu parlais d'une table temporaire (je ne savais pas non plus que l'on pouvait en faire en MySQL) et non d'une table simple de type MEMORY. Pourtant tu l'as bien écrit et plus d'une fois.... On a donc raison tous les deux, sauf que l'on ne parlait pas de la même chose. Vraiment désolé. Bref, ça fera de la lecture pour certains.^^
Maintenant le problème de verous à la vérification levé avec ta solution, je vais reconsidérer la chose.
Ceci mis à part, développer en SGBDR épais avec MySQL reste encore un bien grand mot, et n'est pas toujours possible à 100%.
Register_global est obsolète depuis php 5.3.0 et supprimé depuis php 5.4.autre truc pas toujours connu le réglage du php pour la génération automatique des variables venant de données externes($_POST, $_GET, ...)
à la génération de ces tableaux super globaux tu as selon le réglage éventuellement la génération automatiques de tout un tas de variables:
$_GET['user'] ou $_POST['user'] vont automatiquement générer une variable $user...
c'est sensé facilité la vie des programmeurs mais en fait c'est juste un trou de sécurité
Le réglage par défaut est sur off depuis la 4.2.0 , soit un peu plus de 10 ans maintenant , on est je pense tranquil de ce coté là
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager