IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

PHP & Base de données Discussion :

Sécurité PHP / Mysql - Injections SQL


Sujet :

PHP & Base de données

  1. #61
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    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é.

  2. #62
    Membre éprouvé Avatar de redoran
    Homme Profil pro
    Développeur-Amateur
    Inscrit en
    Juin 2010
    Messages
    1 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur-Amateur
    Secteur : Santé

    Informations forums :
    Inscription : Juin 2010
    Messages : 1 346
    Points : 1 031
    Points
    1 031
    Par défaut
    oui merci pour le complément
    j'attacherai de revoir le module de sécurité d'une application web

  3. #63
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    Preventing 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. »
    Or ce que l'on vient de vous expliquer, se résume à dire que cette définition n'est pas pertinente et
    "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^^

    ++

  4. #64
    Membre expert
    Avatar de ericd69
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2011
    Messages
    1 919
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2011
    Messages : 1 919
    Points : 3 295
    Points
    3 295
    Billets dans le blog
    1
    Par défaut
    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

    soyons pensez à mettre quand votre problème est résolu ou à utiliser pour les réponses pertinentes...
    ne posez pas de problématique soi-disant simplifiée sur des problèmes que vous n'êtes pas capable de résoudre par respect pour ceux qui planchent dessus... sinon: et à utiliser pour insérer votre code...

  5. #65
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    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

    ATTENTION!! cela ne veut pas dire que tu ne dois pas vérifier la cohérence des paramètres passés aux procédures
    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.

    D'ailleurs passer par un token dans les proc d'update ou d'insert, merci eric, je suis déjà fan j'avoue que je n'y avais jamais pensé et pourtant c'est déjà si évident maintenant que j'y pense!

    ++

  6. #66
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    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.

  7. #67
    Membre expert
    Avatar de ericd69
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2011
    Messages
    1 919
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2011
    Messages : 1 919
    Points : 3 295
    Points
    3 295
    Billets dans le blog
    1
    Par défaut
    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
    soyons pensez à mettre quand votre problème est résolu ou à utiliser pour les réponses pertinentes...
    ne posez pas de problématique soi-disant simplifiée sur des problèmes que vous n'êtes pas capable de résoudre par respect pour ceux qui planchent dessus... sinon: et à utiliser pour insérer votre code...

  8. #68
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    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.

    ++

  9. #69
    Membre expert
    Avatar de ericd69
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2011
    Messages
    1 919
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2011
    Messages : 1 919
    Points : 3 295
    Points
    3 295
    Billets dans le blog
    1
    Par défaut
    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

    soyons pensez à mettre quand votre problème est résolu ou à utiliser pour les réponses pertinentes...
    ne posez pas de problématique soi-disant simplifiée sur des problèmes que vous n'êtes pas capable de résoudre par respect pour ceux qui planchent dessus... sinon: et à utiliser pour insérer votre code...

  10. #70
    Membre éprouvé

    Profil pro
    Inscrit en
    Juin 2007
    Messages
    748
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 748
    Points : 1 022
    Points
    1 022
    Par défaut
    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..
    Conception / Dev

  11. #71
    Membre expert
    Avatar de ericd69
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2011
    Messages
    1 919
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2011
    Messages : 1 919
    Points : 3 295
    Points
    3 295
    Billets dans le blog
    1
    Par défaut


    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
    soyons pensez à mettre quand votre problème est résolu ou à utiliser pour les réponses pertinentes...
    ne posez pas de problématique soi-disant simplifiée sur des problèmes que vous n'êtes pas capable de résoudre par respect pour ceux qui planchent dessus... sinon: et à utiliser pour insérer votre code...

  12. #72
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    @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.

    Citation 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...
    @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.
    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

  13. #73
    Membre expert
    Avatar de ericd69
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2011
    Messages
    1 919
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2011
    Messages : 1 919
    Points : 3 295
    Points
    3 295
    Billets dans le blog
    1
    Par défaut
    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...

    soyons pensez à mettre quand votre problème est résolu ou à utiliser pour les réponses pertinentes...
    ne posez pas de problématique soi-disant simplifiée sur des problèmes que vous n'êtes pas capable de résoudre par respect pour ceux qui planchent dessus... sinon: et à utiliser pour insérer votre code...

  14. #74
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    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.


  15. #75
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par ericd69
    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
    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.

    ++

  16. #76
    Membre éprouvé Avatar de redoran
    Homme Profil pro
    Développeur-Amateur
    Inscrit en
    Juin 2010
    Messages
    1 346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur-Amateur
    Secteur : Santé

    Informations forums :
    Inscription : Juin 2010
    Messages : 1 346
    Points : 1 031
    Points
    1 031
    Par défaut
    @ ericd69
    les tutos c'est comme la doc, tu n'est jamais à l'abri d'une erreur...
    donc faut manipulé avec prudence ; alors je me demande qui les valides !!!! 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

  17. #77
    Membre éprouvé

    Profil pro
    Inscrit en
    Juin 2007
    Messages
    748
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2007
    Messages : 748
    Points : 1 022
    Points
    1 022
    Par défaut
    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" ???
    Conception / Dev

  18. #78
    Membre expert
    Avatar de ericd69
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2011
    Messages
    1 919
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2011
    Messages : 1 919
    Points : 3 295
    Points
    3 295
    Billets dans le blog
    1
    Par défaut
    @tse_jc
    erreur de ta part, mon cher tse_jc:
    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).
    j'ai bien dit: "une table temporaire avec le moteur memory"
    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...
    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    echo"machin.php\0truc.jpg";
    ça affiche bien:
    machin.php.truc.jpg
    mais en fait pas mal de commandes liées aux fichiers vont voir:
    machin.php
    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...
    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...

    soyons pensez à mettre quand votre problème est résolu ou à utiliser pour les réponses pertinentes...
    ne posez pas de problématique soi-disant simplifiée sur des problèmes que vous n'êtes pas capable de résoudre par respect pour ceux qui planchent dessus... sinon: et à utiliser pour insérer votre code...

  19. #79
    Membre confirmé
    Avatar de tse_jc
    Homme Profil pro
    Data Solutions
    Inscrit en
    Août 2010
    Messages
    287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Data Solutions
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2010
    Messages : 287
    Points : 597
    Points
    597
    Billets dans le blog
    4
    Par défaut
    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%.

  20. #80
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 690
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 690
    Points : 20 211
    Points
    20 211
    Par défaut
    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é
    Register_global est obsolète depuis php 5.3.0 et supprimé depuis php 5.4.
    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à
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

Discussions similaires

  1. [MySQL] Sécurité contre les injections SQL ?
    Par kopros2 dans le forum PHP & Base de données
    Réponses: 5
    Dernier message: 17/06/2014, 20h48
  2. [MySQL] Sécurité PHP/MySQL insert/affichage
    Par thibaud28 dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 07/03/2010, 21h22
  3. Connaissez-vous un CMS connu en "PHP-MYSQL/ASP-SQL" du type "EBP / Quadratus" ?
    Par Apfel dans le forum Autres Solutions d'entreprise
    Réponses: 0
    Dernier message: 01/09/2009, 22h18
  4. Sécurité contre les injections SQL
    Par Generation-Web dans le forum Langage
    Réponses: 2
    Dernier message: 27/11/2008, 15h17
  5. [Sécurité] protections php pour XSS, injections SQL, etc
    Par nintendoplayer dans le forum Langage
    Réponses: 1
    Dernier message: 20/03/2008, 09h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo