Se protéger de l’injection SQL
Introduction : Qu’est-ce que l’injection 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/
