Introduction : Qu’est-ce que l’injection SQLInjection SQL

Article à destination des développeurs web et administrateurs de sites.

Une injection SQL est comme son nom l’indique une injection ou insertion de code SQL via des données transmises depuis un site web. Une injection réussie et correctement exploitée permet de récupérer des informations sensibles d’une base de données ou encore de modifier/supprimer/ajouter des données. D’une manière générale, toutes les actions liées à une base de données sont possibles. Habituellement ce type d’injection concerne PHP avec une base SQL mais d’autres langages comme ASP peuvent aussi être concernés.

Ce type d’injection survient habituellement quand les données des utilisateurs sont utilisées sans être filtrées ou vérifiées.

Que peut-on faire exactement avec une injection SQL ?

Habituellement le pirate cherchera à récupérer des informations sensibles de votre base de données.

Même si vous connaissez vos visiteurs ou ne pensez pas connaître un utilisateur capable d’attaquer votre site, il faut savoir qu’un pirate cherchera simplement des sites vulnérables à l’aide de ce que l’on appelle un Dork Google. Un Dork est un mot-clé très précis contenant un modèle qui permet de récupérer de sites éventuellement faillibles.

Il n’y a pas de raisons légitimes d’afficher tous les dorks possibles ici et d’ailleurs ils sont très nombreux, sachez simplement qu’on peut rechercher une page précise qui pourrait correspondre à une page faillible de votre site.

Par se connecter sur une telle page, la requête SQL que l’on place sur notre site ressemble généralement à quelque chose comme :

"SELECT id FROM users WHERE name = 'Admin' AND password = '".$_POST["password"]."'"

On sélectionne donc l’identifiant de l’utilisateur dont le nom est Admin et dont le mot de passe correspondant à celui envoyé par l’utilisateur qui veut se connecter.

C’est à ne JAMAIS faire, car si on poste :

' OR '1'='1

en tant que mot de passe on obtient la requête suivante :

"SELECT id FROM users WHERE name = 'Admin' AND password = '' OR '1'='1'"

Ce qui donne, traduit en français : "Sélectionner l’identifiant de l’utilisateur dont le nom est admin et dont le mot de passe est vide OU 1 est égal à 1"

Ainsi le mot de passe ne sera pas vide mais 1 est égal à 1 donc l’accès est autorisé, l’identifiant est bien sélectionné.

C’est l’exemple très classique dont on parle souvent en cours de bases de données.

Comment savoir si mon site est faillible ?

On peut chercher les problèmes à partir de nos codes sources directement mais aussi, et plus simplement, en ajoutant un

'

à la fin d’une url faillible. Si une erreur apparaît sur votre site du type, c’est qu’il y a potentiellement un souci :

Erreur dans l'exécution de la requête 'SELECT * FROM galerie WHERE id = 2''. Message de MySQL : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1

L’erreur apparaît sur le site car " id=2' " est directement utilisé pour former la requête alors que " ' " est un caractère spécial de SQL. Ce qui provoque donc une erreur de syntaxe.

Cette erreur nous indique donc que les données entrées par les utilisateurs ne sont pas vérifiées du côté serveur, et qu’il y a donc de fortes chances qu’on puisse aller plus loin.

Je ne vais pas ici continuer jusqu’au bout mais sachez qu’ensuite le pirate pourra récupérer les noms des tables et à afficher leur contenu. Les mots de passe (de la table admin par exemple) apparaîtront généralement chiffrés sur le site. C’est notamment pour cela qu’il faut absolument chiffrer les mots de passe des utilisateurs dans les bases de données.

L’autre façon de savoir si son site est faillible est de scanner son code source.

Il existe deux façons de scanner un code source : la façon manuelle et la façon automatique.

La façon manuelle consiste, comme son nom l’indique, à rechercher nos morceaux de code qui communiquent avec la base de données et s’assurer qu’ils soient robustes (voir plus bas dans l’article).

La façon automatique consiste à analyser son code avec un outil. OWASP propose une liste d’outils de ce genre :

https://www.owasp.org/index.php/Source_Code_Analysis_Tools

Blind SQL injection (injection SQL à l’aveugle)

Comme son nom l’indique, l’injection SQL « à l’aveugle » consiste à exploiter un site faillible de la même manière que celle qu’on a vu, à cela près que le résultat (les messages d’erreur) ne sont pas affichés sur la page.

Là encore des outils complets sont utilisés pour automatiser tout cela. Notamment si une entreprise fait appel à une équipe de hackers éthiques pour tester la sécurité de leur systèmes sans avoir à fournir le code source.

Comment s’en prémunir

Venons-en au point essentiel, se prémunir des attaques par injection SQL.

Si on reprend l’exemple du début :

"SELECT id FROM users WHERE name = 'Admin' AND password = '".$_POST["password"]."'"

On utilise ici ce que l’utilisateur envoie directement dans la requête.

Donc la première chose à faire est d’éviter (d’échapper) les caractères spéciaux à l’aide de mysqli_real_escape_string() :

"SELECT id FROM users WHERE name = 'Admin' AND password = '".mysqli_real_escape_string($_POST["password"])."'"

Les fonctions addslashes() et magic_quotes_gpc() sont aussi utilisées mais ne protègent pas aussi bien que mysqli_real_escape_string().

Un moyen qui tend à se généraliser mais impacte légèrement les performances est l’utilisation des commandes préparées

Les procédures stockées nécessitent plus de connaissances mais peuvent aussi être utilisées. L’identification restera bien protégée à l’intérieur de la procédure et ne pourra plus être détournée.

Enfin, il faut préférer l’utilisation de comptes utilisateurs à accès limité pour empêcher la modification ou suppression d’éléments de la base de données. Et éventuellement vérifier les données avec des expressions régulières ou utiliser des tableaux contenant tous les résultats possibles.

Envie d’en apprendre plus sur les failles web ?

Cette faille et bien d’autres est vue en détail dans mon cours vidéo sur les tests d’intrusion web.

Nous allons parler des fondamentaux : fonctionnement d’HTTP, d’HTTPs, de DNS et de l’architecture web de manière générale.

Nous allons également mettre en place un laboratoire de test avec des machines virtuelles pour héberger et scanner nos sites vulnérables afin d’apprendre sans rien casser.

Nous allons bien sûr parler de toutes les failles web (XSS, CSRF, SQL, LFI, RFI, …etc) en suivant le Top 10 OWASP mais aussi de tout ce qui gravite autour de la sécurité web : dénis de service, mauvaises configurations, données personnelles, reconnaissance, etc…
Impatient de commencer avec vous, je vous propose de rejoindre le cours dès maintenant: https://cyberini.com/cours/hacking-ethique-tests-intrusion-web/

24 Commentaires. En écrire un nouveau

  • Moi je ne trouve pas de site faillible tu n’aurais pas un site ?

    Répondre
  • LeHackerDesBois
    6 avril 2014 8 h 11 min

    merci pour ces renseignements je go direct verifier si mon site est securiser. meme si je n’ai pas tout compris =)

    Répondre
  • Bonjour et merci pour votre article. Depuis quelques jours mon site est victime de hacker. j’ai vérifié les injections SQL j’ai pas l’impression qu’il y ai un probleme a ce niveau la… Je ne trouve pas la faille !

    Est-ce vous pourriez m’aider svp ?

    Le site : http://www.olivale.com

    Merci beaucoup pour votre aide, je ne sais plus quoi faire !
    Bonne journée.

    Répondre
  • Pourriez-vous m’indiqué vers qui me tourner svp ? ca peux plus continuer 🙁
    Merci

    Répondre
  • Salut, d’abord je tiens à vous remercie pour votre dangerosité.

    Pourriez-vous me dire pourquoi ça ne marche pas si on mit  » ‘ or ‘0’=’0 « , ou une autre valeur à la place de « 0 » au lieu de  » ‘ or ‘1’=’1  » svp?.

    Selon l’explication et logiquement 0 est égal à 0 alors ça doit marcher non ?

    J e vous remercie par avance pour votre repose.

    Répondre
    • Salut, me remercier pour ma dangerosité semble un peu étrange mais merci quand même. Il y a beaucoup de variations possibles je ne dis pas qu’il y a juste 1=1 qui fonctionne

      Répondre
  • « On sélectionne donc l’id de l’utilisateur dont le nom ET Admin et dont le mot de passe correspondant à celui envoyé par l’utilisateur qui veut se connecter. » = est
    Ceci etait un message du correcteur orthographique 😛 (oui je sais je n’ai pas mis d’accent a « etait » et pas non plus sur mon « a », mais je suis en qwerty…)

    Répondre
  • Bonsoir,

    Article super intéressant. Je retiens son dernier paragraphe qui me semble être d’une importance capitale en matière de sécurisation, je cite:

    « Enfin, il faut préférer l’utilisation de comptes utilisateurs à accès limité pour empêcher la modification ou suppression d’éléments de la base de données. Et éventuellement vérifier les données avec des expressions régulières ou utiliser des tableaux contenant tous les résultats possibles. »

    Ce principe de limitation des droits utilisateurs sur une base de données reste valable pour tout type de serveur et d’environnement, surtout lorsqu’il s’agit notamment de sécuriser une infrastructure réseau toute entière ! LoL! 🙂

    Répondre
  • Bonjours !

    Merci, déjà, de nous faire partager votre expérience !

    Le principe d’une injection SQL est donc dans le champ du mot de passe de demander au site si 1=1, et la réponse positive du site (bête comme il est) nous permet de se connecter selon le lien de redirection en cas de réponse positive ?

    Je ne suis pas sur de mon raisonnement et préfère vous demander !

    Ce serait pas mal que vous créiez un tout petit site à notre disposition pour nous entraîner ;).

    Mais si je comprend bien en modifiant le code on peut aussi avoir d’autre résultats moins éthique comme un payement par carte bancaire en confirmant l’achat et même le numéro de carte … Et dans cette optique tous les sites « pro » se sont prémunis de cette faille, alors pourquoi certains sur des forums ne jurent encore que par la sainte relique InjectionSQL ?

    Merci, Daegars.

    Répondre
    • Bonjour,
      Alors ce n’est pas le fait de demander si 1=1 qui pose problème, mais le fait de pouvoir exécuter dans la base de données des requêtes SQL. Les conséquences de cette possibilité de communication avec la base de données sont effectivement nombreuses, dont l’utilisation de la commande avec 1=1 qui permet de ne pas avoir à utiliser le mot de passe. J’ai fait un exemple pour bien comprendre sur la page suivante : https://www.leblogduhacker.fr/sandbox
      Tous les sites, « pro » ou non devraient être prémunis de cette faille, mais l’erreur est humaine et c’est justement pour cela qu’il est utile de faire de la prévention et d’indiquer comment résoudre ce problème.

      Répondre
      • Bonjour Michel,
        Pour l’instant je n’ai jamais eu à me pencher sur ce genre de failles. La problématique des failles « injections sql » n’est finalement pas due à une mauvaise sécurité de la base de données mais plutôt à un ou plusieurs scripts mal sécurisés en amont.

        La mise en oeuvre de tels scripts requiert des connaissances pointues dans le domaine de la sécurité d’un système d’information, ce qui bien évidemment complique la tâche de sécurisation d’une base de données pour des « Administrateurs » n’ayant pas les compétences requises. Attention, je ne fais aucun jugement à ce niveau. Moi-même j’ai été confronté à un manque de connaissance au niveau des scripts Java, notamment dans le cadre d’un déploiement de centralisateur de logs au sein d’une grosse infra réseau/systèmes. Lorsque l’on s’attaque à du filtrage hyper pointu de logs applicatifs par exemple, c’est balaise mais passionnant ! 🙂

        L’un des gros inconvénient de ce type de « technique de sécurisation » est qu’elle nécessite énormément de ressources systèmes et une supervision drastique de l’ensemble de l’infrastructure réseau et systèmes, ce qui la rend peu abordable à de toute petite structure et système d’information.

        Répondre
        • Bonjour Diki,
          Oui, ce sont bien les façons d’accéder à une base de données qui présentent des faiblesses. Je ne dirais pas que créer du code sécurisé demande des connaissances vraiment pointues (dans ce cas du moins) mais qu’il y a des bonnes pratiques de développement à appliquer, notamment lorsque l’on traite des « entrées utilisateur ».
          Et effectivement la sécurité est souvent un « poids » dans le sens où elle demande des connaissances, du budget, et d’autres ressources que tu cites très bien. Seulement, même en mettant tout cela en place, on risque de se faire pirater, alors qu’en est-il si l’on ne fait rien…

          Répondre
  • HOUNTON Wilfried
    20 octobre 2016 18 h 28 min

    Vraiment intéressant

    Répondre
  • Bonjour et merci pour cet article. Je me demande juste pourquoi ne pas faire un SELECT * from users; pour ensuite faire des actions en local ?

    Répondre
  • Bonjour Michel,

    Je suis votre cours sur le Hacking ethique et alors j’ai remarqué une injection SQL depuis une page Web de mon modem alors comment s’en prémunir ?

    J’ai regarder la page de code de la page web en question et alors depuis la page de code il est écrit comment se connecter au modem,
    ceci dit pour la personne qui ne connaît pas le code WIFI c’est impossible de se connecter à distance bref du coup je n’ai pas les droits pour changer le code d’accés du modem,
    J’ai même le bouton service qui ne fonctionne pu !

    du coup depuis OWASP j’ai trouvé une faille SQL et j’aimerai savoir comment la corriger,

    Dans l’attente d’une réponse que j’espère favorable de votre part je vous accorde mes respects,

    Cordialement.

    Dorian ROSSE.

    Répondre
    • Bonjour Dorian,
      Content de vous trouver parmi les étudiants du cours ! 🙂
      Je ne sais pas de quel modem il s’agit exactement, il s’agit probablement de la page de connexion ou d’aide à la connexion au modem. Vous devriez pouvoir accéder à votre modem depuis un ordinateur connecté à celui-ci, par contre je ne saurais vous dire où la page est stockée physiquement. Car il faudrait effectivement y accéder pour pouvoir éditer et corriger le code source. Vous trouverez sans doute de l’aide dans le manuel de la box et/ou sur un site officiel. Bonne continuation.

      Répondre
  • Svp comment me proteger contre sqlmap

    Répondre

Laisser un commentaire

Menu
More in Hacking Éthique, Failles Web
virus facebook
Comment un pirate peut hacker votre compte Facebook et comment vous en protéger

Article régulièrement mis à jour Mieux comprendre comment se protéger Note générale pour tous ceux (ou celles) qui seraient tombé(e)s ici en voulant hacker un...

Close