{"id":175,"date":"2013-09-02T22:27:20","date_gmt":"2013-09-02T21:27:20","guid":{"rendered":"http:\/\/www.mickael-franc.fr\/blog\/?p=175"},"modified":"2016-03-31T13:54:57","modified_gmt":"2016-03-31T12:54:57","slug":"owasp-injections-sql","status":"publish","type":"post","link":"https:\/\/www.mickael-franc.fr\/blog\/owasp-injections-sql\/","title":{"rendered":"OWASP \/ Injections SQL"},"content":{"rendered":"

\"Injections<\/a>Dans ce premier article de la s\u00e9rie consacr\u00e9e aux failles applicatives<\/a>, j’aborde les injections SQL au travers de l’OWASP.<\/p>\n

Dans la plupart des syst\u00e8mes d’information des \u00ab\u00a0entr\u00e9es utilisateurs\u00a0\u00bb sont permises pour consulter ou alt\u00e9rer des donn\u00e9es issues d’une base quelconque. Cette entr\u00e9e utilisateur est un vecteur d’attaque qu’il faut prendre en consid\u00e9ration lors de la r\u00e9alisation de notre application pour s’affranchir de la menace par injections.
\nUne grande majorit\u00e9 des SI utilise des bases de donn\u00e9es de type relationnelles avec pour langage interpr\u00e9t\u00e9 le SQL. C’est donc sur ces types d’injections que portera cet article.
\n<\/p>\n

Introduction<\/h2>\n

L\u2019OWASP (Open Web Application Security Project) dispose d\u2019un projet de r\u00e9pertorisation des failles les plus couramment utilis\u00e9es par des utilisateurs malintentionn\u00e9s sur Internet. Ce document est accompagn\u00e9 d’une qualification des menaces list\u00e9es et d’une explication sur l’exploitation.<\/p>\n

Ce projet se nomme le \u201cTop Ten\u00a0\u00bb (et sort chaque ann\u00e9e si le classement \u00e9volue), il est disponible \u00e0 cette adresse : https:\/\/www.owasp.org\/index.php\/Category:OWASP_Top_Ten_Project<\/a><\/p>\n

Comme chaque ann\u00e9e depuis un petit moment, les failles d\u2019injections arrivent en premi\u00e8re place.<\/p>\n

Qualification de la menace<\/h2>\n

Nous allons qualifier notre menace en l\u2019illustrant dans le tableau ci-dessous. La premi\u00e8re colonne correspond \u00e0 des informations g\u00e9n\u00e9riques qui nous serviront de crit\u00e8res, la seconde sera notre indicateur de mesure (crit\u00e8re de pond\u00e9ration) et la derni\u00e8re, une explication remani\u00e9e (issue du TopTen). Pour simplifier, il s\u2019agit donc d\u2019un tableau crois\u00e9 entre plusieurs crit\u00e8res dont les vecteurs d\u2019attaques (donn\u00e9es li\u00e9es \u00e0 l\u2019injection SQL) et les risques r\u00e9sultants de ces attaques (d\u00e9figuration du site, corruption du contenu de la base de donn\u00e9es, pertes de donn\u00e9es confidentielles, interruption totale\/partielle de service, etc..).<\/p>\n\n\n\n\n\n\n\n\n
\n

Agent de menace<\/span><\/strong><\/p>\n<\/td>\n

\n

_<\/span><\/p>\n<\/td>\n

\n

Consid\u00e9rer toute personne en mesure de soumettre des donn\u00e9es non fiables au syst\u00e8me, y compris les utilisateurs externes, internes, et les administrateurs.<\/p>\n<\/td>\n<\/tr>\n

\n

Vecteur d\u2019attaque<\/span><\/strong><\/p>\n<\/td>\n

\n

Exploitation Simple<\/span><\/p>\n<\/td>\n

\n

L\u2019attaquant envoie un simple texte exploitant la syntaxe de l\u2019interpr\u00e9teur cibl\u00e9. Presque toute source de donn\u00e9e peut \u00eatre un vecteur d\u2019injection, y compris les sources internes.<\/p>\n<\/td>\n<\/tr>\n

\n

Vraisemblance de la vuln\u00e9rabilit\u00e9<\/span><\/strong><\/p>\n<\/td>\n

\n

Commune<\/span><\/p>\n<\/td>\n

\n

Les failles d\u2019injection ont lieu lorsqu\u2019une application envoie des donn\u00e9es non contr\u00f4l\u00e9es \u00e0 un interpr\u00e9teur. Les failles d\u2019injection sont extr\u00eamement r\u00e9pandues, particuli\u00e8rement dans les codes existants, tr\u00e8s souvent dans les requ\u00eates SQL, LDAP, Xpath, les commandes syst\u00e8mes, les arguments de programme, etc.<\/p>\n<\/td>\n<\/tr>\n

\n

D\u00e9tection de la vuln\u00e9rabilit\u00e9<\/span><\/strong><\/p>\n<\/td>\n

\n

Moyenne<\/span><\/p>\n<\/td>\n

\n

Les failles d\u2019injections sont simples \u00e0 d\u00e9couvrir en examinant le code, mais plus difficile via des tests. Les scanners et fuzzers<\/a> peuvent aider un attaquant \u00e0 les d\u00e9couvrir.<\/p>\n<\/td>\n<\/tr>\n

\n

Impact technique<\/span><\/strong><\/p>\n<\/td>\n

\n

S\u00e9v\u00e8re<\/span><\/p>\n<\/td>\n

\n

Une injection peut mener \u00e0 la perte ou corruption de donn\u00e9es, perte de tra\u00e7abilit\u00e9 ou du d\u00e9ni d\u2019acc\u00e8s. Elle peut mener parfois jusqu\u2019\u00e0 la prise de contr\u00f4le total du serveur.<\/p>\n<\/td>\n<\/tr>\n

\n

Impact m\u00e9tier<\/span><\/strong><\/p>\n<\/td>\n

\n

_<\/span><\/p>\n<\/td>\n

\n

Consid\u00e9rer la valeur m\u00e9tier de la donn\u00e9e affect\u00e9e et de la plateforme ex\u00e9cutant l\u2019interpr\u00e9teur. Toutes les donn\u00e9es peuvent-\u00eatre vol\u00e9es, modifi\u00e9es ou effac\u00e9es. Votre image de marque peut-elle \u00eatre entach\u00e9e ?<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Seuls les privil\u00e8ges de l\u2019utilisateur ex\u00e9cutant la requ\u00eate peuvent brider les tentatives d\u2019un utilisateur malveillant.<\/p>\n

Exemples d\u2019attaques et m\u00e9thode de test<\/h2>\n

Le code pr\u00e9sent\u00e9 par la suite est \u00e0 titre d’exemple, volontairement sensible aux injections, donc non s\u00e9curis\u00e9.<\/p>\n

Null authentication :<\/strong><\/h3>\n

Admettons un formulaire (non prot\u00e9g\u00e9) de connexion sur un site web lambda. La requ\u00eate permettant la validation d\u2019une connexion aura la forme suivante :<\/p>\n

<?php\r\n$query = \"SELECT * FROM utilisateur WHERE login=\".$_POST['login'].\" AND password=\".$_POST[\u2018password\u2019];\r\n<\/code>$result = mysql_query($query) ;\r\nif (count(mysql_fetch_assoc($result)) > 0)\r\necho \u00ab Vous \u00eates connect\u00e9 ! \u00bb;<\/em>\r\n?><\/pre>\n
Alors si l\u2019utilisateur saisit des identifiants erron\u00e9s, la requ\u00eate renverra la valeur \u00ab false \u00bb.<\/p>\n
Que se passerait-il si un utilisateur saisissait dans le champ login\/password :<\/p>\n
blabla\u2019 OR \u20181\u2019=\u20181\r\n<\/code><\/pre>\n
Remarquez que le dernier 1 n\u2019a pas de quote de fermeture, toute la subtilit\u00e9 d\u2019une injection se situe dans un jeu d\u2019ouverture et de fermeture de quotes).<\/p>\n
SELECT * FROM utilisateur WHERE login=\u2018blabla\u2019 OR \u20181\u2019=\u20181\u2019 AND password=\u2018blabla\u2019 OR \u20181\u2019=\u20181\u2019\r\n<\/code><\/pre>\n
Le r\u00e9sultat d\u2019une telle requ\u00eate renverra toujours \u00ab true \u00bb. C\u2019est pourquoi chaque n-uplets de la table utilisateur est retourn\u00e9. La connexion est donc \u00e9tablie avec un utilisateur NULL.<\/p>\n
Si toutefois la condition de connexion \u00e9tait :<\/p>\n
<!?php\r\nif (count(mysql_fetch_assoc($result)) == 1)\r\n<\/code>echo \u00ab Vous \u00eates connect\u00e9 ! \u00bb;<\/em>\r\n?><\/pre>\n
Alors il suffirait de modifier la cha\u00eene saisie dans le champ password par ceci : <\/code><\/p>\n
blabla\u2019 OR \u20181\u2019=\u20181\u2019 LIMIT 1,1 -- \u2018\r\n<\/code><\/pre>\n
Le premier param\u00e8tre de la clause LIMIT \u00e9tant l\u2019offset (l\u2019index d\u2019un \u00e9l\u00e9ment dans un ensemble), il est possible de s\u00e9lectionner n\u2019importe quel utilisateur en base avec cette technique.<\/p>\n
Blind injection :<\/strong><\/h3>\n
Admettons l\u2019url suivante d\u2019un site lambda :<\/p>\n
http:\/\/newspaper.com\/items.php?id=2<\/a><\/p>\n
Le script enverrait la requ\u00eate suivante \u00e0 la base de donn\u00e9es :<\/p>\n
<?php\r\n$query = \"SELECT title, description, body FROM items WHERE id_item=\".$_GET[\u2018id\u2019]\r\n?>\r\n<\/code><\/pre>\n
M\u00eame principe que la pr\u00e9c\u00e9dente requ\u00eate, l\u2019attaquant d\u00e9cide de tester si le site est vuln\u00e9rable :<\/p>\n
En saisissant dans l\u2019url : \u00ab 2 and 1=1 \u00bb, une fois encod\u00e9 cela donnera la cha\u00eene suivante : \u00ab 2+and+1%3D1 \u00bb<\/p>\n
http:\/\/newspaper.com\/items.php?id=2+and+1%3D1<\/a><\/p>\n
Si l\u2019application est vuln\u00e9rable, alors il est probable qu\u2019elle ne retourne rien. Cela signifie que la requ\u00eate a renvoy\u00e9 la valeur \u00ab true \u00bb. C\u2019est-\u00e0-dire que l\u2019injection a probablement fonctionn\u00e9. Ce genre de test permet de v\u00e9rifier si une application est vuln\u00e9rable, il faut distinguer la valeur de retour d\u2019une requ\u00eate SQL.<\/p>\n
Timing attack :<\/strong><\/h3>\n
Autre exemple pour une base de donn\u00e9es MySQL :<\/p>\n
Supposons qu\u2019un pirate ait trouv\u00e9 une faille d\u2019injection SQL sur votre application, il peut tenter une attaque par d\u00e9ni de services (sur votre base de donn\u00e9es).<\/p>\n
SELECT BENCHMARK(5000000,ENCODE(\u2018MSG\u2019, \u2018passe-phrase\u2019));\r\n<\/code><\/pre>\n
Cette requ\u00eate permet d\u2019effectuer 5 000 000 de fois l\u2019encodage de la cha\u00eene de caract\u00e8res \u00ab MSG \u00bb gr\u00e2ce \u00e0 la passe-phrase \u00ab passe-phrase \u00bb.<\/p>\n
Que se passerait-il si cette requ\u00eate \u00e9tait unie avec une autre (reprenons l\u2019exemple pr\u00e9c\u00e9dent) ?<\/p>\n
SELECT * FROM utilisateur WHERE login=\u2018blabla\u2019 OR \u20181\u2019=\u20181\u2019 AND password=\u2018blabla\u2019 OR \u20181\u2019=\u20181\u2019 UNION SELECT BENCHMARK(5000000,ENCODE(\u2018MSG\u2019, \u2018by 5 seconds\u2019));\r\n<\/code><\/pre>\n
En fonction des capacit\u00e9s du serveur de base de donn\u00e9es et de sa charge au cours de l\u2019attaque, le service peut \u00eatre perturb\u00e9 voire indisponible (si l\u2019int\u00e9gralit\u00e9 des ressources sont consomm\u00e9es).<\/p>\n
L\u2019id\u00e9e est bonne, mais MySQL interdit l\u2019union de deux requ\u00eates n\u2019ayant pas le m\u00eame nombre de colonnes. Il s\u2019agit \u00e0 pr\u00e9sent de faire plusieurs tests, jusqu\u2019\u00e0 ce que la requ\u00eate soit ex\u00e9cut\u00e9e. Il faut ajouter dans la clause SELECT de la deuxi\u00e8me requ\u00eate, des attributs \u00ab null \u00bb pour simuler une colonne (l\u2019ordre importe peu dans cet exemple), jusqu\u2019\u00e0 avoir le m\u00eame nombre de colonnes que la table avec laquelle nous voulons unir la n\u00f4tre.<\/p>\n
Supposons donc que la table utilisateur est compos\u00e9e de 3 colonnes (id, login et password), il faut donc ajouter deux fois une fausse dimension \u00ab null \u00bb, la troisi\u00e8me dimension \u00e9tant d\u00e9finie par la fonction BENCHMARK.<\/p>\n
SELECT * FROM utilisateur WHERE login=\u2018blabla\u2019 OR \u20181\u2019=\u20181\u2019 AND password=\u2018blabla\u2019 OR \u20181\u2019=\u20181\u2019 UNION SELECT null, null, BENCHMARK(5000000,ENCODE(\u2018MSG\u2019, \u2018by 5 seconds\u2019)) ;\r\n<\/code><\/pre>\n
Cette fois-ci, la requ\u00eate est valide et ex\u00e9cut\u00e9e.<\/p>\n
Remarque : <\/span>Un test simple pour v\u00e9rifier si un site est vuln\u00e9rable aux injections est de tester avec une single-quote n\u2019importe quel param\u00e8tre (GET, POST, issu des cookies, et si on est d\u00e9veloppeur du site v\u00e9rifier que les donn\u00e9es issues de la base de donn\u00e9es sont bien \u00e9chapp\u00e9es si souhait\u00e9).<\/p>\n
Dernier exemple (avec remplacement de colonnes \u201ccross table\u201d)<\/strong><\/h3>\n
Prenons cette fois-ci le cas d\u2019une consultation d\u2019article disponible depuis l\u2019adresse suivante :<\/p>\n
http:\/\/site-vuln\u00e9rable\/articles\/consulter\/?news_id=<\/a><\/p>\n
Ici, consulter un article quelconque ne nous int\u00e9resse pas, et nous souhaitons r\u00e9cup\u00e9rer les identifiants de un ou encore mieux de tous les utilisateurs.<\/p>\n
Dans notre exemple fictif simplifi\u00e9, la table des news n\u2019aura que 3 colonnes :<\/p>\n