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 :

Protection Injection MySql [MySQL]


Sujet :

PHP & Base de données

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Invité
    Invité(e)
    Par défaut Protection Injection MySql
    Bonsoir,

    Je regarde actuellement dans votre tuto les protections pour tout ce qui est faille Xss et injection SQL.

    Je me demandais si elles étaient toujours d'actualité ?

    Faille Xss :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    function failleXss($string) { return htmlentities($string,ENT_QUOTES,'UTF-8'); }
    Et pour l'injection Sql que je n'ai pas très bien saisi :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    function quote_smart($value)
    {
        if(get_magic_quotes_gpc())
        {
        $value = stripslashes($value);
        }
     
        return mysql_real_escape_string($value);
    }
    pour un code du type :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    $req=$bdd->prepare('INSERT INTO minichat values (default, :pseudo , :message )');
    	$req->execute(array('pseudo' => quote_smart($_POST['pseudo']),...(etc)
    Si elle est toujours d'actualité, quelqu'un pourrait m'expliquer l'utilisé du get_lagic_quotes_gpc et du stripslahes ?

    Merci beaucoup d'avance !
    Ca m'est d'une grande aide

  2. #2
    Modérateur
    Avatar de sabotage
    Homme Profil pro
    Inscrit en
    Juillet 2005
    Messages
    29 208
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Juillet 2005
    Messages : 29 208
    Par défaut
    magic_quotes était un mécanisme de protection automatique des données de formulaire mais c'est complétement obsolète (même si on pourra bien le trouver encore sur certains serveurs).
    mysql_real_escape_string() concerne l'ancienne extension mysql_ (qu'on trouve encore largement sur tous les serveurs).

    Étant donné que tu utilises PDO avec des requêtes préparées, cela ne te concerne pas.

    Par contre htmlentities() à l'affichage c'est toujours valable.
    N'oubliez pas de consulter les FAQ PHP et les cours et tutoriels PHP

  3. #3
    Invité
    Invité(e)
    Par défaut
    Salut, merci du retour.

    Concernant l'affichage , il existe strip_tags qui permet non pas d'écrire les balises pour éviter la faille , mais au contraire de les enlever.
    T'en penses quoi si je mets celle ci à la place de htmlentities. ( on m'a également parlé de htmlspecialchars )

    Concernant les failles SQL, je suis un peu perdu.
    Comment je dois me protéger actuellement ?

    La fonction ne me sert à rien ? :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    function quote_smart($value)
    {
        if(get_magic_quotes_gpc())
        {
        $value = stripslashes($value);
        }
     
        return mysql_real_escape_string($value);
    }

  4. #4
    Membre chevronné
    Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    504
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 504
    Par défaut
    Citation Envoyé par tchoumo Voir le message
    Salut, merci du retour.

    Concernant l'affichage , il existe strip_tags qui permet non pas d'écrire les balises pour éviter la faille , mais au contraire de les enlever.
    T'en penses quoi si je mets celle ci à la place de htmlentities. ( on m'a également parlé de htmlspecialchars )
    Ca serait une mauvaise utilisation de la dite fonction, qui conduiront tôt ou tard à des problèmes (c'est bête, mais par exemple, il se peut que tu te retrouve un jour avec des utilisateurs qui peuvent pas écrire de formule de math dans un champs texte, car les symboles < et > pourraient former des balises).

    edit : d'ailleurs, en faisant ça, je n'aurais pas pu écrire < et > dans ce forum !

    Par ailleurs, htmlentities, en plus des caractères des balises convertis également tous les caractères accentués, évitant de fait des problèmes d'encodage chez certains utilisateurs. Donc à partir du moment ou tu veux ecrire du texte dans le code html depuis le code php, si ça vient d'une bdd ou d'un formulaire, le htmlentities devrait être systématique.

    Concernant les failles SQL, je suis un peu perdu.
    Comment je dois me protéger actuellement ?
    si tu utilises la PDO et les requetes préparées (comme dans ton exemple), tu es totalement protégé sans n'avoir rien à faire.

    $req=$bdd->prepare('INSERT INTO minichat values (default, :pseudo , :message )');
    $req->execute(array('pseudo' =>$_POST['pseudo']),...(etc)
    l'exemple ci-dessus est exempt de faille, bien que tu ailles chercher la valeur direct dans le post sans la protégé car la PDO gèrera automatiquement la protection en fonction du type !

    Par contre, si tu fais :

    $req=$bdd->prepare('INSERT INTO minichat values (default, :pseudo , "'.$variable.'" )');
    $req->execute(array('pseudo' =>$_POST['pseudo']),...(etc)
    là, tu ouvres potentiellement un faille.

    Donc tant que tu utilises la PDO et que tu passe tes variables à ta requetes via execute() ou bindValue(), tu es protégé !

  5. #5
    Modérateur
    Avatar de sabotage
    Homme Profil pro
    Inscrit en
    Juillet 2005
    Messages
    29 208
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Juillet 2005
    Messages : 29 208
    Par défaut
    Pour les injections SQL ce que tu fais est bon : requête préparée avec paramètres nommés et execution avec les valeurs.

    Pour XSS, strip_tags() n'est pas suffisant et peut par contre retirer du texte innoncent en pensant que c'est un tag html.
    N'oubliez pas de consulter les FAQ PHP et les cours et tutoriels PHP

  6. #6
    Invité
    Invité(e)
    Par défaut
    Bon bah voilà, je vous aime

    Merci infiniment, c'est très clair et ça m'enlève un clou !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [MySQL] Tables vidées et injection mysql
    Par sam01 dans le forum PHP & Base de données
    Réponses: 18
    Dernier message: 03/02/2015, 19h23
  2. [MySQL] Eviter les Injections mysql
    Par johnson95 dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 17/02/2010, 16h03
  3. Injection MySQL depuis PHP
    Par Jayrome dans le forum Requêtes
    Réponses: 3
    Dernier message: 04/05/2009, 11h26
  4. [MySQL] Protection injection SQL
    Par Slashs dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 07/01/2009, 01h01
  5. Protection connection mysql
    Par Amenos dans le forum SQL Procédural
    Réponses: 5
    Dernier message: 02/02/2006, 14h42

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