{"id":2864,"date":"2024-01-28T11:41:00","date_gmt":"2024-01-28T10:41:00","guid":{"rendered":"\/?p=2864"},"modified":"2024-01-28T11:41:00","modified_gmt":"2024-01-28T10:41:00","slug":"combattre-les-attaques-par-injection-sql","status":"publish","type":"post","link":"https:\/\/nlion.fr\/blog\/combattre-les-attaques-par-injection-sql\/","title":{"rendered":"Combattre les attaques par injection SQL sur vos applications web"},"content":{"rendered":"\n

Les attaques par injection SQL demeurent une menace constante pour la s\u00e9curit\u00e9 des applications web PHP. C’est une technique de piratage courante utilis\u00e9e par les cybercriminels pour acc\u00e9der \u00e0 votre base de donn\u00e9es et en modifier les informations. Pour contrer efficacement cette menace, il est crucial d’adopter des pratiques de codage s\u00e9curis\u00e9 et d’utiliser des techniques avanc\u00e9es pour prot\u00e9ger les bases de donn\u00e9es contre les intrusions malveillantes. <\/p>\n\n\n

\n
\"Nicolas<\/figure>\n<\/div>\n\n\n\n\n\n\n

Une m\u00e9thode simple est d’utiliser la fonction htmlentities<\/code>. <\/p>\n\n\n\n

Mais htmlentities<\/code> n’est pas suffisant pour pr\u00e9venir les attaques par injection SQL. htmlentities<\/code> est une fonction qui convertit les caract\u00e8res sp\u00e9ciaux en entit\u00e9s HTML \u00e9quivalentes, mais elle n’est pas con\u00e7ue sp\u00e9cifiquement pour s\u00e9curiser les requ\u00eates SQL contre les injections.<\/p>\n\n\n\n

L’utilisation de htmlentities<\/code> peut aider \u00e0 \u00e9chapper certains caract\u00e8res sp\u00e9ciaux dans les donn\u00e9es entrantes et \u00e0 pr\u00e9venir les attaques XSS (Cross-Site Scripting), qui visent \u00e0 injecter du code JavaScript malveillant dans les pages web. Cependant, cela ne prot\u00e8ge pas contre les attaques par injection SQL, qui exploitent les failles dans la fa\u00e7on dont les requ\u00eates SQL sont construites et ex\u00e9cut\u00e9es.<\/p>\n\n\n\n

Comprendre l’injection SQL<\/strong><\/p>\n\n\n\n

L’injection SQL est une technique d’attaque dans laquelle des pirates exploitent les failles de s\u00e9curit\u00e9 des applications web pour injecter du code SQL malveillant. Cette injection peut permettre aux attaquants d’acc\u00e9der, de modifier ou m\u00eame de supprimer des donn\u00e9es dans la base de donn\u00e9es, compromettant ainsi gravement la s\u00e9curit\u00e9 et l’int\u00e9grit\u00e9 du syst\u00e8me.<\/p>\n\n\n\n

Exemple simple<\/strong><\/p>\n\n\n\n

Supposons qu’une application web ait un formulaire de connexion o\u00f9 les utilisateurs saisissent leur nom d’utilisateur et leur mot de passe pour se connecter. Voici un exemple de requ\u00eate SQL pour v\u00e9rifier les informations de connexion :<\/p>\n\n\n\n

SELECT * FROM utilisateurs WHERE nom_utilisateur = 'utilisateur' AND mot_de_passe = 'motdepasse';<\/code><\/p>\n\n\n\n

Si cette requ\u00eate est mal construite et vuln\u00e9rable \u00e0 une injection SQL, un attaquant pourrait saisir une entr\u00e9e sp\u00e9cialement con\u00e7ue dans le champ du nom d’utilisateur pour modifier le comportement de la requ\u00eate. Par exemple, l’attaquant pourrait saisir ' OR '1'='1<\/code> comme nom d’utilisateur. La requ\u00eate modifi\u00e9e ressemblerait \u00e0 ceci :<\/p>\n\n\n\n

SELECT * FROM utilisateurs WHERE nom_utilisateur = '' OR '1'='1' AND mot_de_passe = 'motdepasse';<\/code><\/p>\n\n\n\n

Dans ce cas, '1'='1'<\/code> est une condition qui sera toujours vraie, ce qui signifie que la requ\u00eate renverra toutes les lignes de la table des utilisateurs, contournant ainsi le processus de v\u00e9rification du mot de passe. L’attaquant pourrait alors potentiellement acc\u00e9der \u00e0 n’importe quel compte utilisateur sans avoir \u00e0 fournir de mot de passe valide.<\/p>\n\n\n\n

Il est important de noter que ce n’est qu’un exemple simplifi\u00e9 et que les injections SQL peuvent \u00eatre beaucoup plus complexes dans la pratique. C’est pourquoi il est essentiel pour les d\u00e9veloppeurs de s\u00e9curiser correctement leurs applications en utilisant des techniques telles que les requ\u00eates pr\u00e9par\u00e9es, l’\u00e9chappement des caract\u00e8res sp\u00e9ciaux et la validation des entr\u00e9es utilisateur pour pr\u00e9venir de telles attaques.<\/p>\n\n\n\n

Solutions avanc\u00e9es en PHP pour contrer l’injection SQL<\/strong><\/p>\n\n\n\n

    \n
  1. PDO et les requ\u00eates pr\u00e9par\u00e9es :<\/strong> PHP Data Objects (PDO) est une extension PHP qui fournit une interface de base de donn\u00e9es uniforme pour travailler avec diff\u00e9rentes bases de donn\u00e9es. Les requ\u00eates pr\u00e9par\u00e9es sont des requ\u00eates SQL o\u00f9 les param\u00e8tres sont remplac\u00e9s par des marqueurs de param\u00e8tres. Ces marqueurs sont ensuite li\u00e9s \u00e0 des valeurs sp\u00e9cifiques, ce qui emp\u00eache l’ex\u00e9cution de code SQL malveillant. Les requ\u00eates pr\u00e9par\u00e9es avec PDO offrent une protection automatique contre l’injection SQL, car les valeurs des param\u00e8tres sont trait\u00e9es comme des donn\u00e9es brutes et non comme du code SQL.<\/li>\n<\/ol>\n\n\n\n

    Exemple avec PDO et les requ\u00eates pr\u00e9par\u00e9es :<\/p>\n\n\n\n

    $pdo = new PDO(\"mysql:host=localhost;dbname=ma_base_de_donnees\", \"utilisateur\", \"mot_de_passe\"); $stmt = $pdo->prepare(\"SELECT * FROM utilisateurs WHERE nom = :nom\"); $stmt->execute(array(':nom' => $nom)); $resultats = $stmt->fetchAll();<\/code><\/p>\n\n\n\n

      \n
    1. Escaping des caract\u00e8res sp\u00e9ciaux :<\/strong> En plus de htmlentities<\/code>, PHP offre \u00e9galement des fonctions comme mysqli_real_escape_string()<\/code> pour \u00e9chapper les caract\u00e8res sp\u00e9ciaux dans les cha\u00eenes de caract\u00e8res avant de les inclure dans une requ\u00eate SQL. Cependant, l’utilisation de cette m\u00e9thode n\u00e9cessite une certaine prudence car elle peut \u00eatre sujette \u00e0 des erreurs si elle est mal utilis\u00e9e.<\/li>\n<\/ol>\n\n\n\n

      Exemple d’utilisation de mysqli_real_escape_string()<\/code> :<\/p>\n\n\n\n

      $nom = mysqli_real_escape_string($connexion, $nom); $sql = \"SELECT * FROM utilisateurs WHERE nom = '$nom'\"; $resultat = mysqli_query($connexion, $sql);<\/code><\/p>\n\n\n\n

        \n
      1. Filtrage et validation des donn\u00e9es :<\/strong> Il est recommand\u00e9 de filtrer et de valider toutes les donn\u00e9es entrantes avant de les utiliser dans des requ\u00eates SQL. PHP propose des fonctions telles que filter_input()<\/code> et filter_var()<\/code> pour valider et filtrer les entr\u00e9es utilisateur selon diff\u00e9rents crit\u00e8res (par exemple, filtrer les entr\u00e9es en tant que cha\u00eenes, entiers, adresses email, etc.).<\/li>\n<\/ol>\n\n\n\n

        Exemple d’utilisation de filter_input()<\/code> :<\/p>\n\n\n\n

        $nom = filter_input(INPUT_POST, 'nom', FILTER_SANITIZE_STRING); $sql = \"SELECT * FROM utilisateurs WHERE nom = '$nom'\"; $resultat = mysqli_query($connexion, $sql);<\/code><\/p>\n\n\n\n

        Conclusion<\/strong><\/p>\n\n\n\n

        Les attaques par injection SQL sont une menace s\u00e9rieuse pour la s\u00e9curit\u00e9 des applications web PHP. En utilisant des techniques avanc\u00e9es telles que les requ\u00eates pr\u00e9par\u00e9es avec PDO, l’\u00e9chappement des caract\u00e8res sp\u00e9ciaux et le filtrage des donn\u00e9es, les d\u00e9veloppeurs peuvent renforcer consid\u00e9rablement la s\u00e9curit\u00e9 de leurs applications contre ces attaques malveillantes. Cependant, il est important de se rappeler que la s\u00e9curit\u00e9 est un processus continu, et les d\u00e9veloppeurs doivent rester vigilants et tenir compte des derni\u00e8res bonnes pratiques de s\u00e9curit\u00e9 pour prot\u00e9ger leurs applications contre les menaces \u00e9mergentes.<\/p>\n","protected":false},"excerpt":{"rendered":"

        Les attaques par injection SQL demeurent une menace constante pour la s\u00e9curit\u00e9 des applications web PHP. C’est une technique de piratage courante utilis\u00e9e par les cybercriminels pour acc\u00e9der \u00e0 votre…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-2864","post","type-post","status-publish","format-standard","hentry","category-securite-informatique"],"_links":{"self":[{"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/posts\/2864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/comments?post=2864"}],"version-history":[{"count":0,"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/posts\/2864\/revisions"}],"wp:attachment":[{"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/media?parent=2864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/categories?post=2864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nlion.fr\/blog\/wp-json\/wp\/v2\/tags?post=2864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}