Annonce

Réduire
Aucune annonce.

Initiation aux injections SQL

Réduire
X
 
  • Filtre
  • Heure
  • Afficher
Tout nettoyer
nouveaux messages

  • Initiation aux injections SQL

    Les injections SQL font partie des failles Web redoutables, puisqu'elles s'exploitent côté serveur. Elles touchent les sites qui interagissent de manière non sécurisée avec une base de données, permettant ainsi à un attaquant de détourner les requêtes comme il le souhaite. Nous verrons ici les bases de ce type de failles, et quelques techniques d'injections plus poussées, mais sans rentrer dans le détail des "Blind SQL Injections".

    Sommaire

    Exemple - Principe de base
    Bypasser un formulaire d'authentification
    Correction
    Obtenir des infos - Exemples d'injections plus poussées
    Obtenir un mot de passe
    Autres exemples

    1. Exemple - Principe de base

    Le principe de base qui explique la présence d'une faille d'injection SQL est très simple. Observons ce code pour comprendre :

    Code:
    <!-- recherche.php -->
    <html>
    
    <head>
    <title>Sans titre</title>
    </head>
    <body bgcolor="black" text="white" link="yellow" vlink="fuchsia">
    <p align="center"strong>Recherche dans les articles :</strong/p>
    <?
    if (isset($_POST["rech"]))
    {
      $connect = mysql_connect(HOST,USER,PASS);
      mysql_select_db(BASE,$connect);
      $sql = "SELECT id_article, titre, contenu FROM articles WHERE titre LIKE '%".
      $_POST["rech"]."%' OR contenu LIKE '%".$_POST["rech"]."%'";
      $result = @mysql_query($sql) or die ("Erreur dans le traîtement de la requête :".$sql);
      $n = mysql_num_rows($result);
      if ($n < 1)
      {
        echo  "<p align='center'>Nous n'avons trouvé aucun résultat pour \"<b>".
        $_POST["rech"]."</b>\".";
        ?>
        <p align="center"> Vous pouvez relancer une recherche :</p>
        <form name="form_rech" method="post" action="recherche.php">
            <p align="center"input type="text" name="rech" size="12"/p>
            <p align="center"input type="submit" name="formbutton1" value="Rechercher"/p>
        </form>
        <?
      }
      else
      {
        ?>
        <p>Nous avons trouvé les résultats suivants :</p>
        <?
        while($row = mysql_fetch_array($result))
        {
          ?>
          <table cellpadding="0" cellspacing="0" width="573" align="center">
              <tr>
                  <td width="563" height="28" bgcolor="#660000">
                      <p align="center"b?=$row["titre"]?/b/p>
                  </td>
              </tr>
              <tr>
                  <td width="563" height="18" bgcolor="#000066">
                      <p?=$row["contenu"]?/p>
                  </td>
              </tr>
          </table>
          <?
        }
      }
      mysql_close($connect);
    }
    else
    {
      ?>
      <p align="center"> Tapez ce que vous voulez rechercher sur le site :</p>
      <form name="form_rech" method="post" action="recherche.php">
          <p align="center"input type="text" name="rech" size="12"/p>
          <p align="center"input type="submit" name="formbutton1"   value="Rechercher"/p>
      </form>
      <?
    }
    ?>
    </body>
    </html>
    Bien qu'un peu long, ce code montre un exemple complet de page. Quel est son rôle ? C'est un moteur de recherche dans des articles, tout simplement. La vulnérabilité se situe dans le code en rouge. En effet, la requête effectuée est la suivante :

    $sql = "SELECT id_article, titre, contenu FROM articles WHERE titre
    LIKE '%".$_POST["rech"]."%' OR contenu LIKE '%".$_POST["rech"]."%'";

    Entre les % se trouve le contenu encadré par des guillements simples ; c'est ce que va rechercher le script dans la table des articles, à l'aide de l'opérateur LIKE. En effet, LIKE utilisé avec le caractère '%' permet de chercher du contenu qui "ressemble" à ce qui est tapé par l'utilisateur, car le % est interprété par LIKE comme "n'importe quelle chaîne de caractères". C'est un peu comme une expression régulière ; si vous recherchez "%un%", vous pourrez obtenir n'importe quelle chaîne de caractère contenant "un", comme "une", "lune", et "brun".

    Mais cet opérateur ne constitue pas une faille. La vulnérabilité est due au fait que l'entrée $_POST["rech"] n'est pas filtrée. Car nous pouvons imaginer qu'un utilisateur rentre cette chaîne : "n'importe quoi". A ce moment là, la requête devient :

    $sql = "SELECT id_article, titre, contenu FROM articles WHERE titre LIKE '%n'importe quoi%' OR contenu LIKE '%n'importe quoi%'";

    Et l'on remarque très vite le problème qui va se poser : une erreur de syntaxe due au guillement, que mysql intermprète comme la fin de la chaîne de caractères. La requête ne sera pas exécutée, et le visiteur obtiendra :

    Erreur dans le traîtement de la requête :

    SELECT id_article, titre, contenu FROM articles WHERE titre
    LIKE '%n'importe quoi%' OR contenu LIKE '%n'importe quoi%'

    Maintenant, imaginons un visiteur plus expérimenté, et qui connaît ce type de faille. Il teste une première fois le script en rentrant "n'importe quoi", le script plante et lui affiche la reqête fautive. Ensuite, voici ce qu'il pourraît rentrer dans le formulaire :

    a' OR 'a%' = 'a

    La requête devient donc :

    SELECT id_article, titre, contenu FROM articles WHERE titre
    LIKE '%a' OR 'a%' = 'a%' OR contenu LIKE 'a' OR 'a%' = 'a%'

    Ici, le script ne plantera pas ; il n'y a aucune erreur de syntaxe. Le script ressortira la liste de tous les articles, puisque la condition 'a%' = 'a%' est toujours réalisée.

    Ceci était un exemple de détournement de requête, mais il n'est pas très utile.

    Cependant, il est tout à fait possible de détourner le script afin d'obtenir des renseignements utiles sur le serveur. C'est ce que nous allons bientôt voir.

    2. Bypasser un formulaire d'authentification

    Laissons cet exemple de côté et penchons-nous plutôt sur un deuxième :

    Code:
    <!-- admin.php -->
    <html>
    <head>
    <title>Sans titre</title>
    </head>
    <body bgcolor="black" text="white" link="yellow" vlink="fuchsia">
    <p align="center"span style="font-size:14pt;"b>Page d'administration
    </b/span/p>
    <p align="center"?
    if (isset($_POST["login"]) && isset ($_POST["pass"]))
    {
      $connect = mysql_connect(HOST,USER,PASS);
      mysql_select_db(BASE,$connect);
      $sql = "SELECT login, pass FROM users WHERE login = '".$_POST["login"]."'
      AND pass = '".$_POST["pass"]."'";
      $result = @mysql_query($sql) or die ("Erreur lors du traitement de la requête ".$sql);
      if (mysql_num_rows($result) < 1) die ("Login/Pass incorrect !<br /a href = 'admin.php'>Retour</a>");
      ?>
      <p align="center">Bienvenue ! Vous avez désormais accès à toutes les fonctions d'administration
      du site !
      </p>
      <p align="center">> Consulter la BDD</p>
      <p align="center">> Gérer les articles</p>
      <p align="center">> ...</p>
      <?
    }
    else
    {
      ?>
      <p align="left">Cette page est réservée aux administrateurs ! Si vous êtes n'en
      êtes pas un, cliquez <a href="index.php">ici</a> !</p>
      <p align="left"> </p>
      <form name="formlogin" method="post" action="admin.php">
      <p align="center">Entrez votre login / pass :</p>  
         <p align="center"> <input type="text" name="login" value="login"/p>
         <p align="center"input type="password" name="pass" value="pass"/p>
         <p align="center"input type="submit" name="ok" value="OK"/p>
      </form>
      <?
    }
    ?>
    </body>
    </html>
    Ceci est un exemple très basique de formulaire de zone admin. Et non sécurisé... Mis à part qu'il soit vulnérable à une XSS, il l'est également pour les injections SQL. En effet, si nous rentrons ceci :

    a' OR 'a'='a

    La requête en rouge devient :

    $sql = "SELECT login, pass FROM users WHERE login = 'a' OR 'a'='a' AND pass = 'a' or 'a'='a'";

    Ainsi, on peut se loguer sans connaître l'utilsiateur et le mot de passe, puisque la constitution 'a'='a' est toujours vérifiée.

    On se rend donc compte que les injections SQL peuvent devenir très dangereuses si l'administrateur a une politique de sécurité négligente, ou s'il n'en a pas du tout...

    3. Correction

    Si vous êtes webmaster, cela vous intéressera sûrement de savoir comment corriger ce type de failles. En réalité, c'est très simple, encore faut-il prendre le temps de se documenter à ce sujet...

    Le premier réflexe que l'on peut avoir est de se dire "les guillements sont à proscrire, ce sont eux les causes de ce type de failles", et donc de coder un script qui enlève tous les guillements ou qui les échappe en rajouttant un antishash devant. On peut donc utiliser la fonction addslashes() ou bien utiliser les options magic_quotes_gpc et magic_quotes_runtime qui le font en parmanence pour nous. Ainsi, ce code est sécurisé :

    Code:
    function secure($texte){
       return mysql_real_escape_string($texte);
    }
    /*
    ...
     */
    $sql = "SELECT id_article, titre, contenu FROM articles WHERE titre
    LIKE '%".secure($_POST["rech"])."%' OR contenu LIKE '%".secure($_POST["rech"])."%'";
    La fonction que nous avons codé, secure(), ajouttera des antislashes si nécessaire devant tous les ', ce qui les rendra interprétés par mysql non en tant que fin de chaîne mais comme des simples caractères. Elle utilise la fonction mysql_real_escape_string(), conçue spécialement pour éviter ce type de failles.

    Mais le problème de ce genre de solution apparaît très clairement lorsque nous voulons effectuer des requêtes faisant intervenir des nombres :

    $sql = "SELECT id_article, titre, contenu FROM articles
    WHERE id_article = ".$_POST["idarticle"]."";

    En effet, ici, il sera toujours possible de faire des injections SQL car il n'y a pas de guillemets encadrant le nombre (ici, $_POST["idarticle"]). On peut très bien taper "0 OR 1=1" afin de lister tous les articles. Même si c'est inutile, cela permet quand même de prouver l'existence de la faille.

    On en conclut que même si une fonction de sécurisation des guillements est présente, qu'elle soit automatique ou non (magic_quotes), il y a toujours un risque. Pour l'éliminer définitivement, il faut donc faire :

    $sql = "SELECT id_article, titre, contenu FROM articles WHERE id_article = '".secure($_POST["idarticle"])."'";

    On a rajouté des guillements simples encadrant le nombre, ce qui ne gène en rien Mysql. Et cela rend le script sécurisé...

    Pour résumer, la solution pour se protéger des injections SQL est simple : il ne faut jamais faire confiance à l'utilisateur. Ne jamais le sous-estimer et penser qu'il n'est pas informé. Il faut alors filtrer tout ce que peut rentrer l'utilisateur avant de faire quoi que ce soit.

    De plus, vous ne devez jamais laisser paraître les erreurs SQL sur votre site, car une personne malveillante peut faire planter le script volontairement afin de recueuillir des informations sur le nom des champs et des tables du serveur. C'est pour cela qu'il vaut mieux retourner un code d'erreur si une fonction échoue, plutôt que d'affiacher la requête. D'ailleurs, ici, cet affichage provoque une vulnérabilité de type XSS, car l'utilisateur malin qui injectera du javascript dans le champ fera d'une part échouer l'interaction avec la base, et d'autre part afficher son code...

    4. Obtenir des infos - Exemples d'injections plus poussées

    Maintenant, nous allons introduire l'exploitation de ces failles de manière avancée à travers quelques exemples. Ne perdez pas de vue le fait que ces exemples ne sont pas des cas réels ; ici, nous voulons juste montrer l'étendue de ces failles. Dans un autre articles, les "Blind Injections SQL", nous verrons concrètement comment l'on se débrouille en réalité. Je vous conseille donc de vous repporter à cet article pour obtenir des cas plus concrets.

    4.1. Obtenir un mot de passe

    Tout d'abord, reprenons le premier exemple, le moteur de recherche. Ce script très mal conçu affiche la requête lorsqu'il plante, donc nous allons tirer parti de cet affichage pour noter le nom des tables et des champs. Pour le deuxième exemple, nous pouvons aussi faire planter le script en mettant un guillement, ce qui nous révèle le nom de la table "membres", et des deux champs "login" et "pass", assez explicites. A présent, essayons de récupérer le login et le pass de l'admin. Nous voulons afficher ces informations. Il nous faut donc trouver un script sur le site vulnérable qui en affiche. Par exemple, le moteur de recherche affiche les articles. A l'attaque ! Voici ce que nous pouvons rentrer dans le champ :

    ' union all select id_article, pass as titre, login as contenu from users,articles #

    Notez que UNION n'est disponible que depuis MySQL 4. La requête devient :

    $sql = "SELECT id_article, titre, contenu FROM articles WHERE titre LIKE '%' UNION SELECT id_article, pass AS titre, login AS contenu FROM users,articles
    #%' OR contenu LIKE '%' UNION select id_article, pass AS titre, login AS contenu
    FROM users,articles #%'";

    Le # représente pour MySQL un commentaire !

    Remarquez que l'on peut aussi utiliser '/*'. Par conséquent, tout ce qui est après sera ignoré. La requête sélectionne donc tous les articles et ajoute (rôle du mot clé UNION) tous ces résultats à la liste des administrateurs et leur mot de passe. Notez l'astuce consistant à renomer à l'aide de AS les champs afin de réussir l'UNION. De plus, si vous croisez une table A de n champs avec une table B, B devra forcément avoir elle aussi n champs, qui devront avoir le même type. C'est pour cela que l'on sélectionne trois champs dans chaque partie de la requête.

    Cela peut donc produire cet affichage :

    Joyeux Noël
    Je vous souhaite un joyeux Noël est une très bonne année !
    Version 3.8.2 béta 5
    Le site vient d'être mis à jour ! Des nouveautés font leur apparitions !

    123456
    admin

    pass2
    admin2

    On a donc les mots de passe des deux admins, et le comble c'est qu'ils sont codés en clair !

    4.2. Autres exemples

    Imaginons maintenant que nous disposons du nom d'une table et d'un champ dans cette table. Nous voulons obtenir le nom d'un champ et d'une autre table où l'on pourrait trouver des informations utiles.

    La méthode à utiliser est de la divination pure et dure ;-). On peut essayer ainsi les tables "articles", "membres", "admin", "users", etc. et les champs corespondants "login", "password", "pass", etc. Mais comment tester justement ces champs et ces noms de tables ? Nous allons utiliser par exemple cette requête :

    Deviner le nom d'une table

    SELECT id_article,titre,contenu FROM articles WHERE titre
    LIKE '%' UNION SELECT id_article, titre, contenu FROM articles,membres
    #%' OR contenu LIKE '%...%'

    En blanc, la requête initiale, en vert, ce que l'on rentre et en bleu le commentaire. On remarque que l'on n'a fait que dupliquer la requête en ajoutant juste ",membres" dans le nom des tables à interroger. La requête va donc planter si jamais "membres" n'est pas le nom d'une table existante, et afficher des articles dans le cas contraire. Il faut donc remplacer "membres" par le nom de la table à tester.

    Encore une fois, je le rappelle, tous ces exemples ne sont pas ceux que l'on utiliserait dans la réalité puisqu'ils necessitent de connaître pas mal de renseignements sur la base. Repportez-vous aux Blind SQL Injections.

    Deviner le nom d'un champ dans une table connue

    Nous connaissons le nom de la table (membres), nous voulons savoir le nom des champ. Nous testons :

    SELECT id_article,titre,contenu FROM articles WHERE titre LIKE
    '%' UNION SELECT id_article, titre, champatester FROM articles,membres #'

    "champatester" est le champ dont nous voulons vérifier la présence. Si la requête réussit, il existe, sinon, il n'existe pas.

    Deviner un mot de passe :

    Dans certains cas il arrive que le contenu d'un champ soit accesible mais non affiché. C'est le cas par exemple de notre formulaire de zone admin : on ne peut pas directement afficher le mot de passe.

    Il faut donc procéder par essais successifs :

    SELECT * FROM `membres` WHERE login = 'admin' AND pass LIKE '%a'

    A croiser bien sûr avec une injection SQL. Si la session d'admin s'ouvre, c'est que son mot de passe commence par un 'a'. Sinon, on essaye avec 'b', puis ainsi de suite. On remonte les caractères jusqu'à trouver le mot de passe complet.

    Si l'on veut connaître le nombre de caractères du mot de passe, on peut utiliser l'opérateur LENGTH() comme ceci :

    SELECT * FROM membres WHERE login='admin' AND LENGTH(pass)=4# ...'

    Les méthodes que nous venons de voir se font par bruteforcing, puisqu'elles ne nous permettent pas d'obtenir les informations de manière directe, mais simplement de savoir si l'on a bon ou faux. L'opérateur AS est très pratiques dans ces situations puisqu'il permet de renomer un champ temporairement pour la requête, donc de croiser deux champs différents.

    SHOW et GRANT : obtenir tout ce que l'on veut (?)

    Les deux opérateurs ultimes dont nous aurions besoin sont GRANT et SHOW. Ils permettent de lister la structure complète de la base, des tables, lister les utilisateurs, leurs privilèges et leur mot de passe. Le seul problème majeur est qu'il est impossible de les utiliser en les croisant avec SELECT. Impossible donc d'y avoir accès dans les exemples que nous venons de voir.

    Les petits malins auront envie d'utiliser le point virgule afin d'effectuer deux requêtes l'une après l'autre, mais un autre problème nous en empêche : mysql_query(). Cette fonction interagit entre PHP et MySQL mais ne peut permettre que d'effectuer UNE SEULE requête à la fois. Le point virgule est donc à bannir. Et GRANT/SHOW par la même occasion... sauf si c'est une autre fonction qui est utilsée, et qui permet ce genre de choses !

    Ainsi, vous sere peut-être déçu mais il est impossible d'utiliser un opérateur tel que UPDATE, DROP, ou INSERT si la requête commence par SELECT. A moins, comme nous l'avons dit, que la fonction utilisée le permette.

    Obtenir la version du serveur :

    Nous pouvons utiliser les variables spécifiques à chaque serveur SQL. Pour MYSQL, la variable @@version contient le nom de la version du serveur. Ainsi, SELECT @@version affiche cette version. Il faut bien entendu exploiter une injection afin de pouvoir utiliser cette commande. Pour les autres serveurs, c'est une autre variable. Il suffit de chercher un peu dans les documentations pour les trouver.

    Créer un fichier :

    La directive INTO OUTFILE [nom_fichier] croisée avec SELECT permet de créer un fichier contenant les informations de SELECT demandées. On peut donc imaginer un scénario où vous exploitez tout d'abord une injection SQL se situant dans une requête INSERT ce qui vous permet d'écrire du code dans la base, puis vous exploitez une deuxième injection dans SELECT afin de créer un fichier contenant le code que vous avez écrit dans la base. Si c'était du code PHP, une backdoor par exemple, ou un simple script d'une ligne contenant une faille Include, vous obtiendrez un accès supplémentaire sur le serveur.

    Cependant, il faut déja obtenir l'url vers laquelle écrire le fichier, car si vous écrivez à la racine du serveur, cela peut d'une part sembler louche, d'autre part ne pas être accessible sur le serveur... En effet, si votre fichier écrit se trouve avant le répertoire "www" d'Apache, c'est fichu...

    Utiliser un fichier pour effectuer des opérations :

    Il est possible d'utiliser LOAD DATA INFILE [nom_fichier] pour lire un fichier et effectuer les opérations SQL décries à l'intérieur. C'est le complément de INTO OUTFILE. Le seul problème, c'est que LOAD n'est pas compatible avec SELECT, donc inutilisable dans la grande majorité des cas.

    Conclusion

    Vous l'aurez compris, les injections SQL dépassent complétement le cas d'école avec ' or ''='. Il y en a des tonnes, plus ou moins adaptées à ce que l'on veut faire. Les seuls limites sont celles du langage SQL, qui nous empêche parfois de croiser des requêtes pourtant bien pratiques... Dans un second article sur les injections SQL dites "blind", ou "à l'aveuglette", nous exploiterons à fond le langage SQL afin de faire révéler aux scripts vulnérables des informations cruciales.

    credit:trance
    sigpic

    Cyprium Download Link

    Plus j'étudie plus j'me rends compte que je n'sais rien.

    †|

  • #2
    j'adore ce tuto je sais pas pk ^^
    sigpic

    Commentaire


    • #3
      Très bon tuto, je vais pouvoir réviser les bases.

      Merci

      Commentaire


      • #4
        Super tuto au passage mais je voulais savoir si il existait un moyen d'éviter toutes les failles sql? faut-il vraiment vraiment connaître ce language pour s'en prévenir?
        Il faut toujours viser la lune car même en cas d'échec on atterit toujours au milieu des étoiles...

        Commentaire


        • #5
          Faut connaître PHP oui. Les notions SQL sont moins importantes pour "l'attaqué". Pour l'attaquant faut s'y connaître +, mais nul besoin d'être un expert en gestion de base de données pour maîtriser tout type d'injections. Faut tâter un peu quand même. Mais c'est surtout PHP qu'il faut connaître Et, y'a PHP et PHP^^ Y'a PHP tel que la plupart le connaissent, et PHP tels que les pros l'utilisent. Tu me diras, c'est comme pour tout. En gros, faut minimum 5 piges à développer en PHP pour pouvoir affirmer "je suis un bon dév PHP". Bon il te faudrait 10 ans pour dire que t'es un bon dév en C^^ C'est déjà ça de gagné^^ Moi des dévs PHP j'en connais... pfff... plein. Bah crois moi, y'a des fossés entre les bidouilleurs et les experts^^ Mais bon, PHP... pour la sécu du site (je ne parle pas du serveur là, ça c'est encore autre chose, bien que ça reste du PHP/SQL et autre) y'a besoin d'avoir des connaissances correctes en PHP. Genre 6 mois dans les pattes (enfin, tout dépend de la taille du site, si c'est un site énorme de e-commerce, là c'est pas la même^^ je parle pour un petit site dit "vitrine"). Après, côté serveur... déjà y'a d'autres connaissances qui rentrent en jeu (le mécanisme d'un serveur, tout simplement, les protocoles réseaux, blabla modèle OSI comme on dit toujours^^) mais y'a plein d'autres choses à prendre en compte et là pour le coup, c'est beaucoup plus coton^^ En général, les webdév ne savent pas sécu un serveur (à 90% : je suis sérieux). Donc bon, un pas devant l'autre, un bouquin sur PHP, et c'est parti
          sigpic

          Cyprium Download Link

          Plus j'étudie plus j'me rends compte que je n'sais rien.

          †|

          Commentaire


          • #6
            Envoyé par SAKAROV Voir le message
            Faut connaître PHP oui. Les notions SQL sont moins importantes pour "l'attaqué". Pour l'attaquant faut s'y connaître +, mais nul besoin d'être un expert en gestion de base de données pour maîtriser tout type d'injections. Faut tâter un peu quand même. Mais c'est surtout PHP qu'il faut connaître Et, y'a PHP et PHP^^ Y'a PHP tel que la plupart le connaissent, et PHP tels que les pros l'utilisent. Tu me diras, c'est comme pour tout. En gros, faut minimum 5 piges à développer en PHP pour pouvoir affirmer "je suis un bon dév PHP". Bon il te faudrait 10 ans pour dire que t'es un bon dév en C^^ C'est déjà ça de gagné^^ Moi des dévs PHP j'en connais... pfff... plein. Bah crois moi, y'a des fossés entre les bidouilleurs et les experts^^ Mais bon, PHP... pour la sécu du site (je ne parle pas du serveur là, ça c'est encore autre chose, bien que ça reste du PHP/SQL et autre) y'a besoin d'avoir des connaissances correctes en PHP. Genre 6 mois dans les pattes (enfin, tout dépend de la taille du site, si c'est un site énorme de e-commerce, là c'est pas la même^^ je parle pour un petit site dit "vitrine"). Après, côté serveur... déjà y'a d'autres connaissances qui rentrent en jeu (le mécanisme d'un serveur, tout simplement, les protocoles réseaux, blabla modèle OSI comme on dit toujours^^) mais y'a plein d'autres choses à prendre en compte et là pour le coup, c'est beaucoup plus coton^^ En général, les webdév ne savent pas sécu un serveur (à 90% : je suis sérieux). Donc bon, un pas devant l'autre, un bouquin sur PHP, et c'est parti
            et bien voici ce qui répond pleinement à mes questions merci Sakarov
            Il faut toujours viser la lune car même en cas d'échec on atterit toujours au milieu des étoiles...

            Commentaire


            • #7
              Bonjour,
              J'ai juste une question:
              Peut-on utilisé mysql_real_escape_string AVEC intval ?


              A moins que je fais erreur et que les 2 sont "infaillible"
              Dernière modification par FRKorisS, 08 novembre 2013, 22h15.
              Mess with the best, Die like the rest

              Commentaire


              • #8
                Normalement, tu as la réponse sur le web :

                intval — Retourne la valeur numérique entière équivalente d'une variable
                mysql_real_escape_string — Protège une commande SQL de la présence de caractères spéciaux

                Donc : utiliser systématiquement mysql_real_escape_string() avant toute requete et ajouter intval() en présence de valeur numérique

                Bonne journée,
                sigpic

                Commentaire


                • #9
                  Hello,

                  La façon la plus simple pour se prémunir d'injection SQL sur le Web (en PHP) est d'utiliser l'interface PDO. D'autant plus que MySQLi est obsolète et ne sera fourni avec les prochaines versions de PHP.

                  Cordialement.

                  Commentaire


                  • #10
                    Envoyé par Practeo Voir le message
                    Hello,

                    La façon la plus simple pour se prémunir d'injection SQL sur le Web (en PHP) est d'utiliser l'interface PDO. D'autant plus que MySQLi est obsolète et ne sera fourni avec les prochaines versions de PHP.

                    Cordialement.
                    Exacte !
                    Toutefois la plupart des erreurs SQL sont liés à la méconnaissance du développeur pour le modèle MVC (modèle, vue, contrôleur).
                    Ils se disent qu'une seule page peut suffire pour afficher, modifier la base de données. Du coup quand il faut faire les MAJ, ils sont perdu - les pauvres petits.
                    ~ Yarflam ~

                    ❉ L'Univers se dirige vers son ultime perfection ❉

                    Commentaire


                    • #11
                      Toutefois la plupart des erreurs SQL sont liés à la méconnaissance du développeur pour le modèle MVC (modèle, vue, contrôleur).
                      Ils se disent qu'une seule page peut suffire pour afficher, modifier la base de données. Du coup quand il faut faire les MAJ, ils sont perdu - les pauvres petits.
                      A ce niveau là, c'est plus de l'igonrance pur est simple des bonnes pratiques de base. En l'occurence la "separation of concerns". ie. L'idée que chaque fonctionnalitée d'un logiciel doit être la plus indépendante des autres possible.
                      C'est ce principe qui guide l'existance des modèles classiques comme les modèles à couches, ou à une échelle plus faible, le MVC, MVP ou le MVVM.

                      A faire du code glouiboulga, on en arrive forcément à avoir rapidement des soucis de sécurité, de performances, d'extensibilité et de maintenabilité au sens large.

                      Une fois de plus, simplement suivre les bonnes pratiques (et un peu d'uml...) pourrait largement améliorer les choses.

                      Dans ce sens, des frameworks structurants comme Symphony apportent un véritable plus au développement PHP, car ils incitent très fortement le développeur à respecter un certain nombre de bonnes pratiques de base.

                      Pour ceux qui s'intéressent au sujet (ok, on a dérivé assez loin des sqli...), je vous conseille les excellents bookins de martin fowler, et la doc de la certif SCEA, qui est vraiment un must (La meilleure doc que j'ai jamais lue sur le sujet !).

                      Tortue 974.
                      Dernière modification par TorTukiTu, 11 novembre 2013, 21h18.
                      OxyGen Software
                      Sécurité, développement, formations, informatique biomédicale
                      [email protected]

                      Commentaire


                      • #12
                        Comme le dit TorTukiTu, le modèle MVC est une chose entièrement différente.
                        Rien n'empêche un développeur Web d'utiliser PDO sans utiliser MVC.

                        Et rien n'oblige un développeur à arrêter de développer en utilisant MySQLi (mise à part le fait que cette interface va bientôt devenir obsolète), car on peut très bien sécuriser ses requêtes avec cette interface. L'utilité de PDO est qu'il gère nativement les injections SQL. Si on utilise correctement PDO bien évidemment...

                        Il faut simplement se rendre compte des risques qu'il y a lors du développement.
                        Ayant aidé différentes personnes lors de développement Web, je peux te dire que ça fait très peur. Il te suffit de parcourir un petit peu les forums de demande d'aide, comme OpenClassroom (ex Site du Zéro), Comment ça Marche ou tout autre site. Il te suffit de voir 3 lignes de leur code pour savoir qu'il y a une possibilité d'injection SQL ou de faille XSS non permanente.

                        Le très grand soucis et la méconnaissance des pseudo-développpeur. Il est tellement simple à notre époque de regarder des tutoriels, de l'apprendre et de le pratiquer. Sauf que ça ne suffit pas, j'ai rarement vu des tutoriels où on traite aussi de la sécurité de l'application.

                        Donc nous avons une personne lambda qui a envie de faire un site Internet. Elle regarde 2-3 tutoriels. Elle sort son site Internet. Mais malheureusement, le code est "à chier" et le site est facilement piratable.

                        Être un développeur Web est un métier, ce n'est pas parce qu'on peut facilement apprendre sur Internet qu'on peut se prétendre développeur web.

                        Commentaire

                        Chargement...
                        X