{"id":35985,"date":"2020-01-14T00:42:12","date_gmt":"2020-01-14T08:42:12","guid":{"rendered":"https:\/\/staging.kinsta.site\/?p=62827"},"modified":"2022-07-18T09:09:22","modified_gmt":"2022-07-18T08:09:22","slug":"injections-sql","status":"publish","type":"post","link":"https:\/\/staging.kinsta.site\/fr\/blog\/injections-sql\/","title":{"rendered":"Injections SQL : Un guide de d\u00e9butant pour les utilisateurs de WordPress"},"content":{"rendered":"

SQL (Structured Query Language) est un langage qui nous permet d’interagir avec des 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

L’injection SQL, ou SQLi, est une attaque sur une application web en compromettant sa base de donn\u00e9es par des d\u00e9clarations SQL malveillantes.<\/p>\n

Comme il s’agit d’une attaque courante, essayons d’en apprendre davantage sur ce que c’est, comment cela se produit et comment s’en d\u00e9fendre.<\/p>\n

Pr\u00eats ? Plongeons dedans !<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Qu’est-ce que l’injection SQL ?<\/h2>\n

L’injection SQL, ou SQLi, est un type d’attaque sur une application web qui permet \u00e0 un attaquant d’ins\u00e9rer des instructions SQL malveillantes dans l’application web, pouvant potentiellement acc\u00e9der \u00e0 des donn\u00e9es sensibles dans la base de donn\u00e9es ou d\u00e9truire ces donn\u00e9es.l’injection SQL a \u00e9t\u00e9 d\u00e9couverte pour la premi\u00e8re fois par Jeff Forristal en 1998.<\/p>\n

Au cours des deux d\u00e9cennies qui ont suivi sa d\u00e9couverte, l’injection SQL a toujours \u00e9t\u00e9 la principale priorit\u00e9 de d\u00e9veloppeurs web<\/a> lors de la conception d’applications.<\/p>\n

Barclaycard a estim\u00e9 en 2012 que 97 % des violations de donn\u00e9es commencent par une attaque par injection SQL<\/a>. L’injection SQL est encore tr\u00e8s r\u00e9pandue aujourd’hui et la gravit\u00e9 des attaques par injection dans une application Web est largement reconnue. C’est l’un des top 10 des risques de s\u00e9curit\u00e9 des applications Web les plus critiques<\/a> selon l’OWASP.<\/p>\n

Comment fonctionne la vuln\u00e9rabilit\u00e9 d’injection SQL ?<\/h2>\n

Une vuln\u00e9rabilit\u00e9 par injection SQL donne \u00e0 un attaquant un acc\u00e8s complet \u00e0 la base de donn\u00e9es de votre application par l’utilisation d’instructions SQL malveillantes.<\/p>\n

Dans cette section, nous partageons un exemple de ce \u00e0 quoi ressemble une 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 prenez l’entr\u00e9e utilisateur \u00e0 travers un formulaire, disons un formulaire de connexion<\/a>. Vous interrogez ensuite votre base de donn\u00e9es avec les champs soumis par l’utilisateur pour les authentifier. La structure de la requ\u00eate vers votre base de donn\u00e9es est quelque chose comme \u00e7a :<\/p>\n

select * from user_table\nwhere\u00a0username = 'sdaityari'\nand\u00a0password = 'mypassword';\n<\/code><\/pre>\n
Pour plus de simplicit\u00e9, supposons que vous stockiez vos mots de passe en clair. Il est toutefois bon de saler vos mots de passe<\/a> et ensuite les hacher. Ensuite, 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
\/\/ Connect to SQL database\n$db_query = \"select * from user_table where\nusername = '\".$user.\"'\nAND password = '\".$password.\"';\";\n\/\/ Execute query\n<\/code><\/pre>\n
Si quelqu’un saisit la valeur \u00ab\u00a0admin’;-\u00a0\u00bb dans le champ du nom d’utilisateur, la requ\u00eate SQL r\u00e9sultante que la variable $db_query g\u00e9n\u00e8re sera la suivante :<\/p>\n
select * from user_table where\nusername = 'admin';--' and password = 'mypassword'\n<\/code><\/pre>\n
\u00c0 quoi sert cette requ\u00eate ?<\/p>\n
Un commentaire en SQL commence par un double tiret (–). La requ\u00eate r\u00e9sultante ne filtre que par le nom d’utilisateur sans tenir compte du mot de passe. S’il n’y avait pas de s\u00e9curit\u00e9 en place pour \u00e9viter cela, on vous accorderait simplement un acc\u00e8s administratif \u00e0 l’application Web en utilisant cette astuce.<\/p>\n
Alternativement, une attaque bool\u00e9enne peut aussi \u00eatre utilis\u00e9e dans cet exemple pour obtenir un acc\u00e8s. Si un attaquant saisi \u00ab\u00a0password\u2019 or 1=1;-\u00a0\u00bb dans le champ du mot de passe, la requ\u00eate r\u00e9sultante serait la suivante :<\/p>\n
select * from user_table where\nusername = 'admin' and\npassword = 'password' or 1=1;--';\n<\/code><\/pre>\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 la requ\u00eate de la base de donn\u00e9es, un attaquant peut utiliser la commande show tables, commande pour afficher les tables de la base de donn\u00e9es, puis faire tomber s\u00e9lectivement les tables s’il le souhaite.<\/p>\n
\"Un
Un dessin anim\u00e9 sur l’injection SQL (source d’image : XKCD<\/a>)<\/figcaption><\/figure>\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\u00a0Robert\u2019); DROP TABLE Students; \u2013\u00a0\u00bb.<\/p>\n
Types d’injection SQL<\/h2>\n
Maintenant que vous connaissez les bases d’une vuln\u00e9rabilit\u00e9 d’injection SQL, explorons les diff\u00e9rents types d’attaques d’injection SQL et la raison derri\u00e8re chacune d’entre elles.<\/p>\n
Injection SQL In-Band<\/h3>\n
L’injection SQL In-Band 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 ainsi que de rassembler les r\u00e9sultats. Nous discuterons de deux formes d’attaques par injection SQL en bande :<\/p>\n
Attaque bas\u00e9e sur des erreurs<\/h4>\n
Un attaquant utilise une technique d’injection SQL bas\u00e9e sur les erreurs lors des phases initiales de son attaque. L’id\u00e9e derri\u00e8re une injection SQL bas\u00e9e sur les erreurs est d’obtenir plus d’informations sur la structure de la base de donn\u00e9es et les noms des tables que l’application web suit. Par exemple, un message d’erreur peut contenir le nom de la table inclus dans la requ\u00eate et les noms des colonnes de la table. Ces donn\u00e9es peuvent ensuite \u00eatre utilis\u00e9es pour cr\u00e9er de nouvelles attaques.<\/p>\n
Attaque bas\u00e9e sur l\u2019union<\/h4>\n
Dans cette m\u00e9thode, un attaquant utilisant l’union SQL se joint pour afficher les r\u00e9sultats d’une table diff\u00e9rente. Par exemple, si un attaquant est sur une page de recherche<\/a> il peut ajouter les r\u00e9sultats d’un autre tableau.<\/p>\n
select title, link from post_table\nwhere id < 10\nunion\nselect username, password\nfrom user_table; --;\n<\/code><\/pre>\n
Injection SQL Inf\u00e9rentielle (Injection SQL aveugle)<\/h3>\n
M\u00eame si un attaquant g\u00e9n\u00e8re une erreur dans la requ\u00eate SQL, la r\u00e9ponse de la requ\u00eate peut ne pas \u00eatre transmise directement \u00e0 la page Web. Dans ce cas, l’agresseur doit approfondir ses recherches.<\/p>\n
Dans cette forme d’injection SQL, l’attaquant envoie diverses requ\u00eates \u00e0 la base de donn\u00e9es pour \u00e9valuer comment l’application analyse ces r\u00e9ponses. Une injection SQL inf\u00e9rentielle est parfois aussi connue sous le nom d’injection SQL aveugle<\/strong>. Nous allons examiner deux types d’injections SQL inf\u00e9rentielles ci-dessous : l’injection SQL bool\u00e9enne et l’injection SQL bas\u00e9e sur le temp.<\/p>\n
Attaque bool\u00e9enne<\/h4>\n
Si une requ\u00eate SQL aboutit \u00e0 une erreur qui n’a pas \u00e9t\u00e9 trait\u00e9e en interne dans l’application, la page Web r\u00e9sultante peut lancer 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