L'écriture d'un script PHP ne nécessite pas de logiciel particulier, il est possible d'écrire un code PHP avec Notepad. Cependant, je recommande le très bon éditeur Notepad++ qui effectue une coloration syntaxique du code en temps réel.

Le serveur sur lequel sera hébergé le code doit obligatoirement avoir l'interpréteur PHP pour fonctionner. La plupart du temps, PHP est un module de l'application serveur Apache. Vous pouvez tester vos scripts PHP en local sur votre machine en installant Apache et PHP. Si vous êtes sous Windows, vous pouvez par exemple installer EasyPHP qui est très simple d'installation et contient Apache, PHP et MySQL. Sous Linux, Apache et PHP sont généralement déjà installés.

Premier exemple

Comme tout premier exemple qui se respecte, nous allons programmer un Hello World.
Pour cela, ouvrez Notepad++, puis cliquez sur Fichier >> Nouveau. Enregistrez le fichier vide dans le dossier de votre choix sous le nom "hello_world.php". Un fichier PHP doit forcément avoir l'extension ".php" pour pouvoir être interprété par le serveur.

Tout code PHP doit être délimité par des balises <?php et ?>. Elles indiquent le début et la fin du code à exécuter. Vous pourrez parfois voir la balise ouvrante <? au lieu de <?php, mais il est toutefois recommander de n'utiliser que <?php

Pour afficher le texte brut "Hello World", nous allons utiliser la commande echo qui sert à envoyer du texte ou code HTML dans la page. Comme dans presque tous les langages, chaque ligne de code doit obligatoirement de terminer par un point virgule.

Voici donc le contenu de notre fichier :

On va maintenant écrire notre Hello World dans du code HTML, en respectant les standards :

C'est un langage serveur, qui s'exécute donc sur le serveur du site. Un script PHP n'est pas compilé, il est interprété à chaque chargement de la page. Il sert généralement à afficher du code (X)HTML qui sera traité par le navigateur du client, mais peut aussi créer et afficher des images (png, jpg, gif...), pdf, ...etc.

J'écrirai bientôt des tutoriels pour apprendre le PHP et le Javascript, ainsi que des articles plus poussés sur certaines astuces et techniques en programmation.

Sommaire

1. Notions sur les expressions régulières
2. Principe de base de l'URL Rewriting et intérêts
3. Risques et exploitation

Introduction

Imaginez que vous êtes un script-kiddie à la recherche de failles à exploiter sur un site Web. Vous visitez quelques pages, et là, malheur, vous ne tombez que sur des pages ayant l'extension HTML... Le HTML est réputé comme "infaillible" puisqu'en effet, n'étant pas un langage de génération dynamique de pages, il ne permet aucun traitement de données. Pour autant, peut-on conclure de manière générale qu'un site comportant des pages possédant l'extension .html n'est pas vulnérable ?

La réponse est non. En effet, les serveurs HTTP comme Apache permettent aisément au webmaster de manipuler d'URL de leurs pages, et de les transformer. On peut ainsi demander à Apache de transformer les URL tapées par le visiteur afin d'exécuter une page dynamique de manière cachée. Cela s'appelle l'URL Rewriting.

1. Notions sur les expressions régulières

Pour bien comprendre le mécanisme d'URL Rewriting il est nécessaire de connaître les expresisons régulières. Si vous connaissez déja le domaine en les ayant manipulées en PHP ou en Perl, vous pouvez sauter cette partie.

Tout d'abord, qu'est-ce qu'une expresison régulière ? Il faut voir une expression régulière (en abrégé "regex") comme un modèle ("pattern" en anglais) permettant de décrire un ensemble de chaînes de caractères.

Voyons tout de suite un exemple. Imaginons que vous souhaitez rechercher dans votre disque dur les fichiers dont le nom comporte un "e" et finit par ".txt". Que taper dans la boîte de recherche ? Vous aimeriez bien qu'un caractère "joker" existe, qui permettrait de décrire 'nimporte quoi". Par exemple, avoir à taper "*e*.txt", en supposant que l'étoile * soit ce caractère joker. En fait, ce que vous venez de taper est une forme d'expression régulière ! Pour la suite, vous pouvez oublier cet exemple, car l'étoile aura une autre signification.

Plus généralement, une expresison régulière est une suite de caractères, qui peuvent être normaux ou spéciaux. Les caractères normaux ne désignent rien de particulier, à par eux-mêmes. C'est le cas des lettres et des chiffres. Viennent ensuite les caractères spéciaux, qui comprennent par exmeple des signes de ponctuation. Ces caractères ne désignent pas eux-même mais ont un comportement différent, que nous allons voir.

• Le point . signifie "nimporte quel caractère".
• L'étoile signifie "le caractère ou la régex précédent(e) répété(e) de 0 à plusieurs fois". Par exmeple la regex "a*" signifie "une suite de 0 ou plusieurs a", et la regex ".*" signifie "une suite de 0 ou plusieurs caractères".
• Le plus + est presque comme l'étoile, au détail près que la suite doit commporter au moins une occurence. C'est à dire que "a+" correspond en fait à une suite de 1 ou plusieurs a, et donc est équivalent à "aa*".
• Les crochets [ et ] définissent ce que l'on appelle une classe. Prenons une exemple : la regex "[a-z]" désigne un caractère entre a et z (une lettre minuscule, donc). L'utilisation du tiret n'est pas obligatoire, on peut par exemple construire la regex "[adj]" qui correpondra à un caractère : soit a, soit d, soit j. Et on peut combiner : "[a-z0-9]" désignera une lettre minuscule ou un chiffre.
• le chapeau ^ correspond au début de ligne, et le dollar $ à la fin de ligne.
• Les parenthèses ( et ) autour d'une regex permettent de capturer le contenu qui correspond à cette regex. Le contenu est stocké dans une variable appelée $1. Si il existe plusieurs parenthèses dans une même regex, alors les variables $2, $3, etc. seront utilisées.
• les accolades { et } définissent une répétition. On utilise la virgule pour donner les bornes de l'intervalle de répétition. Par exemple, la regex ".{2,5}" correspond à une suite de 2 à 5 caractères quelqconques.
• L'antislash \ permet de déspécialiser un caractère spécial. Par exemple, la regex "\.*" correspond à une suite de 0 ou plusieurs étoiles.

Maintenant que vous avez compris les bases des regex, saurez-vous à qui correspond cette regex : "[a-z0-9]@[a-z0-9]\.[a-z0-9]{1,4}" ?

Réponse : c'est une adresse e-mail ! En effet, "[a-z0-9]" correspond à un caractère alphanumérique, le @ n'a pas de signification particulière et reste donc un arobase, "\." correspond à un point (déspécialisé par le \) et ce qui figure derrière est une suite de 1 à 4 caractères alphanumériques. C'est bien une adresse e-mail... à la différence près que les majuscules ne seront pas prises en compte ici, je vous l'accorde... Et si vous revenez à l'exemple du début, à savoir trouver des noms de fichiers comportant un e et finissant par .txt, la regex correspondante est en fait : ".*e.*\.txt" (on laisse la possibilité d'avoir des caractères avant et après le e).

Petite parenthèse : si vous voulez faire du traîtement de chaînes de caractères (appelé aussi parsing), les expressions régulières sont un excellent moyen de faire ! Elles sont compactes et puissantes, ce qui est très rentable quand on écrit du code. D'ailleurs, si vous aimez les expressions régulières, vous aimerez le langage Perl, puisqu'il est basé dessus !

2. Principe de base de l'URL Rewriting et intérêts

L'URL Rewriting est permise par un module d'Apache (mod_rewrite) qui permet la réécriture d'URL à la volée. La configuration de l'URL Rewriting se fait dans un fichier .htaccess, placé én général à la racine du site Web concerné. Voici un exemple de fichier qui définit quelques règles d'URL Rewriting :

La première option active le module et est donc absolument nécessaire. Les lignes d'en dessous définsisent les règles, c'est à dire les conditions sous lesquelles l'URL sera réécrite ou pas. Une règle commence par la directive "RewriteRule", suivie d'une regex (d'où l'utilité du 1er chapitre) qui décrit le modèle d'URL à réécrire, suivie de l'URL réécrite, et terminée par une option. Prenons l'exemple de la 2ème règle, la plus simple. Elle dit simplement que si le visiteur tente d'accéder à la page "index.html", alors le serveur lui renverra la page index.php. La dernière ligne dit que si le visiteur tente d'ouvrir une URL composée d'une suite de lettres terminées par ".html", le serveur affichera la page "index.php?page=$1" en remlplaçant $1 par la suite que l'utilisateur aura tapée.

Il faut bien comprendre que ce mécanisme est totalement invisible pour le visiteur, qui croit surfer sur un site en HTML alors qu'en fait la génération des pages est dynamique (ici en PHP). Enormément de sites utilisent (ou semblent utiliser) ce mécanisme, comme par exemple le site du Monde, le Site du Zero, beaucoup de blogues, et... GITS (pour la version 2 :p).

Quel est l'avantage d'utiliser un tel système ? En fait, il y en a plusieurs. Premièrement, cela permet de masquer à l'utilisateur le fait que le site soit en PHP, il sera donc moins tenté de tester les failles dessus. De plus, les URL sont plus "jolies", plus parlantes, plus facilement mémorisables. Cela permet aussi de booster son référencement dans les moteurs de recherche, car les moteurs ont beaucoup de mal à indéxer des pages dynamiques avec des URL comportant beaucoup de paramètres à rallonge. Cela permet aussi de définir plusieurs URL pointant vers une seule, vu qu'il y a des regex. Ainsi, on peut définir dans une URL des parties "flexibles", c'est à dire que le visiteur peut modifier sans perdre l'accès à la page. On peut donc y glisser des mots-clés, ce qui booste encore plus le référencement...

3. Risques et exploitation

Mais certains webmasters sans beaucoup de connaissances dans le domaine de la sécurité laissent des failles sur leur site et s'en remettent à l'URL Rewriting pour les masquer, espérant que cela sera suffisant. Malheureusement, cela ne l'est pas toujours... Imaginez que vous tombez sur l'URL "http://site.com/article2.html" puis sur une autre "http://site.com/article8.html", et ainsi de suite. On peut soupçonner l'utilisation de l'URL Rewriting... Si l'on fait varier le nombre situé derrière "article", on peut voir ce que cela donne. La page réécrite (cachée) pourrait ressembler à http://site.com/article.php?id=$1 avec $1 le nombre en question. A partir de là, il faut utiliser les techniques habituelles de recherche de failles : faire varier le paramètre, tenter d'insérer des lettres, des caractèes spéciaux, pourquoi pas des balises (qui a dit XSS ? :p), etc. Il n'est même pas nécessaire de connaître le nom du paramètre, puisque si la regex est assez permissive, elle réécrira la chaîne tapée en paramètre de la page. Ainsi, si l'on teste une injection SQL : http://site.com/article1%20and1=2.html deviendra quelque chose du style http://site.com/article.php?id=1%20and1=2 et le résultat de la page nous informera du succès ou non de l'injection.

Ceci était dans le cas où l'expression régulière définie dans la règle était assez permissive, c'est à dire qu'elle n'imposait pas au visiteur de taper un nombre. Elle aurait pu être du type "(.+)\.html". Maintenant, imaginons que le webmaster a voulu restreindre la réécriture en mettant une regex plus restrictive comme "([0-9]+)\.html" qui n'accepte que les nombres. Là, il n'y a pas de technique pour bypasser cette protection (vu que filtrer est bien le but d'un filtre...) ! Mais il ne faut pas perdre de vue le fait que si on connaît le nom de la page PHP qui contient le script (ici article.php), et qu'elle comporte une faille, alors rien ne nous empêche de l'exploiter. L'URL Rewriting n'est en faite génante dans ce cas que si l'URL de cette page est inconnue...

Conclusion

Nous sommes déjà à la fin de cet article... J'espère que vous n'êes pas trop décus ! En fait, ce qu'il faut retenir est que le mécanisme d'URL Rewriting ne comporte pas en lui-même de failles, mais il masque juste des éventuelles failles déja existantes dans le script de la page. Il faur savoir que cela existe, car ce mécanisme est de plus en plus utilisé, vu les avantages qu'il offre.

Concernant l'exploitation de failles, si les règles de réécriture sont permissives, l'exploitation de ces failles se fait sans problèmes, mais si elles ne le sont pas, et que l'on ne connaît pas le nom de la page originale, l'exploitation est déjà plus dure (il faut y aller en testant...).

Cet article a été rédigé par Trancefusion et provient de http://www.ghostsinthestack.org/article-18-url-rewriting.html . Il est diffusé sous licence Creative Commons By-Nc-Sa 2.0 .

Sommaire

1. Exemples - Principe de base
   1. Include()
   2. La faille
2. Techniques d'exploitation
   1. Méthode classique : Inclusion d'une backdoor
   2. Variante : Technique du null byte
   3. Inclusion d'un fichier sensible
3. Des idées de backdoors
   1. Afficher la source
   2. Lister les dossiers
   3. Modifier un fichier pour implanter uen bakcdoor permanente
   4. Ajouter un accès
4. Détecter une faille include
5. Corriger une faille include

1. Exemples - Principe de base

1.i. Include()

La faille Include touche comme son nom l'indique les fonctions du type include(). Ce type de fonction (comme require(), include(), include_once()) a pour objectif d'inclure un fichier et d'exécuter son contenu sur le serveur.

Imaginez par exemple que vous disposez d'un site avec une centaine de pages. Sur ce site, un certain nombre d'éléments sont fixes, dans le sens où ils ne changent pas quelque soient les pages ; par exemple le menu, le haut et le bas de page, etc. Si jamais vous voulez modifier ne serait-ce qu'une entrée dans le menu, vous allez devoir modifier le menu de chaque page afin que tous les menus de toutes les pages correspondent. Soit une centaine de pages à éditer à chaque mise à jour, aussi petite soit-elle...
Ne vous suicidez pas tout de suite ! Car justement, la fonction include() est là pour ça. Elle va vous permettre de n'avoir qu'une seule page à modifier, et toutes les pages de votre site l'inclueront. Comment faire ? Vous créez un fichier menu.php dans lequel vous placez votre menu, puis dans chaque page PHP vous placez un appel include('menu.php') à l'endroit où le menu doit apparaître. Sympa, non ?

1.ii. La faille

Rappelez-vous bien qu'Include() fait deux choses : tout d'abord elle "rapatrie" le code contenu dans le fichier passé en paramètre, puis elle l'exécute. C'est justement l'exécution de ce code, liée à une autre subtilité, qui va constituer la faille.

En effet, imaginez l'appel suivant sur une page index.php :

Ce bout de code regarde si la variable "page" est contenue dans l'URL, et si c'est le cas, elle inclut le fichier de même nom que le contenu de la variable. Sinon, elle inclut une page par défaut. Par exemple, si vous appelez :

Le script incluera (et exécutera) la page "test.php". Jusqu'ici, rien de bien compliqué.

Maintenant, plaçons nous dans la peau d'un visiteur malveillant. Imaginons qu'il se soit rendu compte de la présence d'un appel à'Include() par un quelconque moyen, et qu'il peut contrôler (comme c'est le cas ici) le paramètre passé. S'il appelle la page :

Alors Google s'affichera sur le site ! En effet, une subtilité d'include() permet d'inclure des pages ne se trouvant pas sur le même serveur que la page appelante !

A présent, le visiteur peut inclure n'importe quelle page. Elle sera de toute façon exécutée sur le serveur. Dans ce cas, il peut très bien placer une page PHP qu'il a fait lui même sur son serveur personnel, et l'inclure ! Imaginez que cette page en question soit une backdoor... L'inclusion se fera de la même manière, et il disposera d'une backdoor sur le site vulnérable ! Il pourra alors lister tous les fichiers, les éditer, en créer, accéder à la base de données, etc... Nous y reviendrons en temps voulu.

2. Techniques d'exploitation

2.i. Méthode classique : Inclusion d'une backdoor

La technique de base est celle que nous avons abordée dans le paragraphe précédent, à savoir l'inclusion d'une backdoor en PHP. Nous allons maintenant voir quelques détails techniques.

Tout d'abord, nous supposons que la faille a été détectée, et qu'elle permette l'inclusion de n'importe quelle page (avec n'importe quelle extension). Nous supposons également que nous disposons d'une backdoor. Comme n'importe quelle backdoor peut être utilisée, nous pouvons nous contenter juste pour tester d'une simple page contenant <? echo "Hello World"; ?>. La variable vulnérable peut avoir n'importe quel nom, aussi nous continuerons de l'appeler "page" afin de simplifier.

Maintenant, il ne nous reste plus qu'à placer notre backdoor sur notre serveur préféré, et à l'inclure... Mais il ne faut pas oublier un détail crucial ! En effet, si jamais notre backdoor a pour extension .php et si nous la plaçons sur notre serveur qui exécute le PHP, puis que nous tentons de l'inclure sur le serveur vulnérable, elle sera exécutée non pas par le serveur vulnérable, mais par le serveur qui l'héberge (le notre !). Il y a donc deux solutions :

• Soit nous renommons notre backdoor avec une extension non exécutée, par exemple .txt.
• Soit nous plaçons notre backdoor sur un serveur n'exécutant pas le PHP. C'est assez rare, mais ça existe par exemple certains serveurs de pages perso gratuites comme Orange). une autre solution est d'utiliser un serveur FTP, qui autorise un accès en anonyme. Créer le sien n'est pas dur ; certains logiciels gratuits et libres permettant de le faire assez facilement.

Quelque soit la solution choisie, nous appelons http://notre-serveur.com/backdoor.txt l'URL de notre backdoor (si elle est sur un serveur FTP, remplacez évidemment http:// par ftp:// et indiquez le login/pass de manière habituelle).

Et voila ! Nous pouvons donc appeler la page vulnérable de cette manière :

Et nous verrons notre backdoor s'afficher.

2.ii. Variante : Technique du null byte

Maintenant que nous savons exploiter une include() de façon simple, corsons la situation. Imaginons que le code vulnérable est désormais celui-ci :

Ici, l'extension ".php" est automatiquement rajoutée à la variable. Cela force donc noter backdoor à avoir une extension .php. Nous devons donc, en théorie, nous trouver un serveur n'exécutant pas PHP pour placer notre backdoor, sinon cela ne marchera pas.

Finalement, il existe une solution pour contourner ce problème : la technique de l'octet nul (null byte en Anglais). Cela consiste à rajouter l'extension voulue de notre backdoor (.txt en l'occurence) et à placer un caractère spécial qui va perturber la fonction. Ce caractère est le zéro ASCII. Il n'est pas représentable sur cette page :) Comme nous allons le passer dans l'URL, il va falloir l'encoder. Son encodage sera donc "%00" puisque dans une URL, %xx désigne le caractère de valeur ASCII xx en héxadécimal.

En résumé, il faudra donc inclure :

Mais au fait, pourquoi ctete technique marche-t-elle ? Tout simplement parce que la fonction include() va être traitée (entre autres) par une fonction programmée en langage C. Et en C, on désigne la fin d'une chaîne de caractères par un octet null (\x00 en notation classique). Dans le dernier exemple, le paramètre de la fonction sera : "http://notre-serveur.com/backdoor.txt\x00.php" puisque ".php" est rajouté automatiquement à la fin. Mais comme \x00 indique la fin de la chaîne de caractère, tout le reste sera tronqué !

Attention, selon les cas cette technique ne marche pas toujours. Cela dépend de la configuration su serveur et des vérifications faites dans le script. Mais rappelons que de toute façon, il suffit de mettre la page sur un serveur n'exécutant pas le PHP pour que cela marche...

Remarque importante : Dans le cas ou une chaîne de caractères est rajoutée après la variable, on utilise la technique du null byte. Mais si jamais une chaîne est placée avant, il n'y a (à ma connaissance) aucune technique permettant de bypasser cette protection.

2.iii. Inclusion d'un fichier sensible

Jusqu'ici nous n'avons cherché qu'à inclure notre propre page. Mais il est tout à fait possible, avec cette faille, d'inclure un fichier se trouvant sur le serveur vulnérable ! Et d'ailleurs, c'est quelque fois la seule possibilité, car certaines protections désactivent la possibilité d'inclure du code situé sur un autre serveur.

Il est donc faisable d'inclure un fichier contenant des informations sensibles comme des mots de passe. Par exemple, un fichier .htaccess, .htpasswd, ou carrément le fichier /etc/passwd ou même /etc/shadow si les droits le permettent. Mais un serveur ne tourne que très rarement en root, donc ne vous faites pas d'illusion. (Pour ceux qui l'ignorent, le fichier /etc/shadow n'est lisible que par le root)

Note : Il est possible de récupérer des .htpasswd car bien qu'Apache s'en serve pour limiter les accès à un répertoire, il ignore cette protection lorsqu'il s'agit de faire des include() !

En pratique, on essaye de repérer au préalable des zones protégées par des .htpasswd, et on tente de deviner dans quel répertoire ils se trouvent, en testant successivement des paramètres comme "../.htpasswd" ou "../../.htpasswd" ou encore "../dossier/.htpasswd". Là encore, tout dépend de la configuration du serveur.

Ce type de fichier n'est pas le seul que l'on puisse récupérer. On peut tout à fait tenter de récupérer des hashs MD5 ou même des fichiers contenant des mots de passes en clair si le webmaster en a caché...

Une fois les fichiers de mot de passes récupérés, vous pouvez les cracker avec un programme adéquat. Par exemple, Cain, ou John The Ripper. Si vous avez cracké un .htpasswd, vous pourrez alors accéder aux dossiers protégés, et si vous avez cracké un /etc/passwd (ou /etc/shadow) vous aurez le couple user/pass nécessaire pour vous loguer si vous découvrez un accès SSH sur la machine.

3. Des idées de backdoors

Nous avons fait le tour des techniques courantes d'exploitation. Revenons un peu aux backdoors et voyons les possibilités qu'elles nous offrent. Les quelques idées qui suivent devraient vous permettre d'enrichir vos propres backdoors ;)

3.i. Afficher la source

Une des premières choses intéressantes à faire est sûrement d'afficher la source de la page vulnérable (et des autres pages). Cela permet en effet de lire en clair le code PHP des pages et de détecter les éventuelles procédures de sécurité utilsées. Pour lister la source d'ue page, on utilise généralement un appel à show_source('page.php');.

C'est aussi dans la source que l'on peut trouver plein d'infos utiles comme par exemple des commentaires contenant des mot de passes, ou même des variables gérant l'accès à une base SQL.

3.ii. Lister les dossiers

Afficher l'arborescence du site est également très intéressent. Cela permet de se repérer et d'avoir une vison claire de tous les dossiers, et éventuellement de détecter des fichiers sensibles cachés (du style admin.php ou config.php). Plusieurs techniques existent pour lister le contenu d'un dossier. Je vous ramène au manuel PHP pour en savoir plus car faire un inventaire de toutes les fonctions sortirait largement du cadre de cet article.

3.iii. Modifier un fichier pour implanter une bakcdoor permanente

Cette technique est sans doute une arme ultime en ce qui concerne l'exploitation des failles Include(). Elle consiste à utiliser la backdoor pour modifier un fichier PHP utilisé par le site, et y introduire du code malveillant, qui sera donc exécuté à chaque visite du site touché.

Les applictaions sont illimités. Par exemple, si le site dispose d'un accès par login/pass avec formulaire, on peut compromettre la procédure servant à authentifier les personnes ayant tapé leurs identifiants. Il suffit d'y introduire un appel à la fonction mail() qui nous enverra par mail les codes d'accès de chaque visiteur qui se logue sur le site ! Cela permet entre autres de bypasser le fait que les mots de passes soient stockés en crypté dans une base de données, puisqu'il suffira d'attendre qu'un utilisateur se connecte pour recevoir ses identifiants en clair par mail... Combinée au SE cette technique peut faire très mal...

La condition requise pour utiliser ctete technique est que l'accès en écriture soit possible sur les fichiers voulus, ce qui n'est pas toujours le cas. De plus, il ne faut pas que l'administrateur se rende compte que ses fichiers ont été modifiés, et également qu'il ne fasse pas trop souvent de mise à jour. En effet, s'il met à jour le fichier compromis, la backdoor disparaîtra aussi avec lui.

Encore une fois, les fonctions permettant de modifier les fichiers se trouvent dans la doc PHP, qui est très bien faite et qui contient plein d'exemples.

Note : Une variante consisterait à uploader un fichier PHP sur le serveur et à l'inclure dans toutes les pages... Peut etre plus discret. A voir...

3.iv. Ajouter un accès

Il est également possible de rajouter une entrée dans la base de données. Cela revient à rajouter un utilisateur supplémentaire (aec les droits maximums si possible), et pourra permettre au hacker de revenir plus tard sur le site uniquement en rentrant les codes d'accès qu'il aura choisi.

Pour ce faire, l'utilisation des fonctions spécifiques à MySQL comme mysql_query() est recommandé.

Là aussi, le webmaster ne devra pas s'aperçevoir de la présence de cet utilisateur supplémentaire, sinon il risque de le supprimer.

Je pense que vous avons vu les principales choses qu'il est possible de réaliser avec une backdoor. Je publierai peut-être dans quelques temps une backdoor afin d'illustrer la théorie que nous venons de voir.

4. Détecter une faille include

Après avoir vu comment exploiter une faille include, voyons un peu comment en détecter la présence.

Cela se fait de manière assez simple. Il suffit, comme lors de chaque audit sécuritaire, de modifier tous les paramètres possibles de l'URL et d'observer le résultat. Le but est de faire planter le script en tentant d'inclure une page qui n'existe pas. L'erreur résultante produira un warning PHP de ce type :

Avec [PARAMETRE_INCORRECT] la page qu'on a tenté d'inclure mais qui n'existe pas, [URL_DE_LA_PAGE] l'URL de la page, [NUMERO_DE_LIGNE] le numéro de la ligne où se trouve l'include() fautive.

Par conséquent, si vous détectez un message de ce type sur un site, il y a de fortes chances qu'une faille include soit présente... Voici un exemple ; vous tentez d'appeler la page "sdg" avec index.php?page=sdg, et vous obtenez :

Alors vous pouvez supposer que index.php comporte include($_GET['page']); à la ligne 2.

Bien entendu, la variable fautive ne s'appelle pas toujours "page", aussi devez-vous tester toutes les variables présentes.

Au passage, remarquez que la présence d'une faille include entraine (dans 90% des cas) la présence d'une faille XSS. En effet, on voit apparaître dans le Warning ce que l'on a plaçé dans la variable "page" de l'URL... on peut donc contrôler l'affichage de la page en y insérant un script JavaScript ou tout autre contenu malveillant...

5. Corriger une faille include

Il existe plusieurs façons de corriger la faille.

Premièrement, il faut s'assurer que les pages que l'on inclut sont bien sur notre serveur et non sur un autre. Pour se faire, on peut avoir recours à la fonction file_exists('nom_de_fichier') qui renvoit vrai si le fichier existe sur NOTRE serveur, faux sinon.

Mais cette précaution seule ne suffit pas, puisqu'un attaquant pourra toujours inclure des fichiers .htpasswd ou autre fichiers sensibles. C'est pourquoi je vous conseille fortement de vous constituer un tableau contenant toutes les pages dont l'inclusion est autorisée, et juste avant de fair une inclusion, vous vérifiez la présence de cette page dans le tableau. Pour automatiser tout cela, il est préférable de recoder une fonction "include_secure($page)" qui fait ce travail de manière systématique pour vous. Par exemple :

Et voiçi un exemple de page qui utilise la fonction :

Ainsi, un appel à test.php?page=aaaaa échouera, tandis qu'un appel à test.php?page=print.php marchera.

Voila un exemple complet de sécurisation. Ici, plus besoin du file_exists(), puisque nous avons indiqué nous-même les pages autorisées.

Conclusion

Comme vous pouvez vous en douter, la faille include() est exploitable par beaucoup de méthodes. Tout dépend de votre imagination et de ce que vous souhaitez faire.

Bien que très puissante, elle est encore présente sur un nombre considérable de sites web. Petit à petit, les webmasters prennent conscience de sa gravité et la corrigent... mais pas toujours de la bonne façon, ce qui fait que la faille est toujours là. J'espère qu'après avoir lu ceci, certains webmasters réfléchiront et agiront en conséquence afin d'en finir définitivement avec cette faille.

Cet article a été rédigé par Trancefusion et provient de http://www.ghostsinthestack.org/article-16-la-faille-include.html . Il est diffusé sous licence Creative Commons By-Nc-Sa 2.0 .

Sommaire

1. Exemple - Principe de base
2. Récupération du nombre de champs, leur nom, leur type
3. Construction d'un exploit

Introduction

Pour ne répéter que ce qui est dit dans le résumé, nous allons nous intéresser aux injections SQL en aveugle. Ici, pas question d'afficher directement les informations, puisque la nature même du script ne le permet pas, vu qu'il retourne seulement deux types de réponse. Maglré cette difficulté supplémentaire, nous allons voir comment procéder, en utilisant au maximum le langage SQL ainsi que tout ce qu'il met à disposition.

ATTENTION toutefois : les injections SQL dépendent en général du type de serveur sur lequel vous les testez. Ici, pour simplifier, nous prendrons le cas de MySQL. Plus tard, nous verrons comment détecter le type de serveur sur lequel nous sommes : le SQL fingerprinting.

Avertissement : cet article necessite la lecture préalable du premier qui introduit les injections SQL. Je ne vais donc donner que les grandes lignes. Il est tout a fait possible que les injections à réaliser en pratique nécessitent par exemple de mettre un début de commentaire (/*) juste après afin d'éliminer des parties parasistes de la reqiête originale. Tout dépend de la configuration dans laquelle vous vous trouvez.

1. Récupération de la version du serveur

Connaître le numéro de la version du serveur est une étape fondamentale et quasiment obligatoire. En effet, selon ce numéro, certaines instucttions ne seront pas disponibles. C'est le cas d'UNION, disponible uniquement à partir des versions 4 de MySQL. A travers cet exemple nous poserons les principes de base ce qui nous permettra d'accélérer par la suite.

Le but est donc de récupérer la version du serveur, qui est contenue dans la variable @@version. Un exemple :

Maintenant, plaçons nous dans le cadre d'une attaque aveugle. Le but va être, en utilisant des essais successifs, de trouver cette version sans avoir aucun affichage. Ici, nous nous contenterons de la version "majeure", c'est à dire 4 ; c'est celle qui importe le plus. Nous devons trouver une condition binaire permettant de nous rensigner. Testons :

En bleu, la requête originale et en vert ce que l'on a rentré. Si l'on a obtenu uen erreur, c'est que la version du serveur est inférieure à 3, sinon elle est supérieure. Testons avec 4 !

Vous avez compris le principe... Dès qu'une erreur survient, c'est que la version est entre les deux derniers numéros testés.

Si jamais nous avions voulu obtenir la version complète, il aurait fallu utiliser SUBSTRING comme ceci :

Nous reviendrons sur SUBSTRING après, mais sachez qu'elle permet d'obtenir une sous-chaîne d'une chaîne.

2. Récupération du nombre de champs, leur nom, leur type

Maintenant, l'objectf va être de "faire parler" le serveur afin qu'il nous donne des informations intéressentes.

Si nous voulons découvrir le nom des tables ou des champs, il peut être intéressent d'utilsier UNION afin de décupler la puissance de nos requêtes. Mais pour utiliser UNION, la version du serveur MySQL doit être supérieure ou égale à 4. Vous savez comment faire pour la récupérer, maintenant.

Deuxième condition pour utiliser UNION : il faut que les tables que l'on croise (que l'on unit) aient exactement le même nombre de champs. Troisième et dernière condition : ces champs doivent avoir le même type.

A partir de cela, on comprend que nous allons devoir obtenir d'une part le nombre des champs et d'autre part leurs type.

Pour récupérer le nombre de champs, c'est assez simple. On peut utiliser l'opérateur GROUP BY qui permet de regrouper les enregistrements retournés par le script. Même s'il n'y en a qu'un, cela est un critère permettant de trouver le nombre de champs et même leur noms. En effet, GROUP BY peut s'utiliser soit avec le nom du champ, dans ce cas il générera une erreur si le nom est incorrect ; soit avec le numéro du champ. Notez que l'opérateur ORDER BY a uns syntaxe similaire mais un comportement différent, puisqu'il permet de tier les enregistrements. Un exemple pour comprendre :

Il faut bien entendu remplacer les variables précédées d'un '$' par ce que vous voulez tester. On remarque que si le nombre après GROUP BY est supérieur au nombre de champs dans la requête, cela renvoit faux (plante, en fait). On peut donc maintenant voir le nombre de champs.

Pour tester leur noms, il suffit de mettre le nom à tester derrière GROUP BY. Par contre, ici, on ne pourra pas procéder par essais successifs lettre par lettre car on ne peut pas appliquer SUBSTRING sur le nom du champ lui-même, uniquement sur son contenu. Il faut donc utiliser la force brute pure et dure ce qui peut prendre du temps. Mais souvent, on peut se limiter à essayer "id", "login", "date", "auteur", "password", etc. c'est à dire des noms probables pour des champs.

Concernant le type des champs, on peut insérer différents types de contenus comme du texte (le plus souvent entre guillemets) pour tester si le champ est censé contenir du texte ou nom. Le gros problème de cette technique ets que bien souvent les guillemets sont échappées par les magic_quotes ou une fonction lamda de filtrage du site. Il faut donc utiliser tout ce que nous propose MySQL dans la rubrique "chaînes de caractères". Je pense notemment à la fonction char(ascii) qui retourne un caractère en fonction de son code ascii, et évite d'utiliser les moindres guillemets. La fonction concat(str1, str2, ... concatène des caractères ou des sous-chaînes pour former une chaîne. Pour plus d'infos, je vous ramène à la doc officielle (citée tout en bas).

3. Construction d'un exploit

A présent, passons à la pratique. Imaginons un script tout bete vulnérable à une injection SQL. Lorsque nous l'appelons avec l'URL http://site.com/script.php?id=1 , il fonctionne et affiche ce qui suit. (Au passage, je remercie Geo pour l'idée du script car je manquais d'inspiration :))

Si on change id en mettant 2 on obtient :

En mettant 3 on obtient :

Et si l'on met un caractère comme 'a' on obtient une erreur du style :

Bien, le script est apparamment vulnérable. Il doit être censé afficher la correspondance entre deux champs d'une table qui semblent être un utilisateur et ce qu'il aime. La requête doit être du type :

Mais nous, nous voulons leur mot de passe ! Comment l'obtenir ?

En fait, ici, nous avons le choix. Nous avons en effet deux solutions pour exploiter la faille. La première et peut-être la plus immédiate est d'effectuer une injection SQL à l'aveuglette, qui consiste à découvrir le mot de passe petit à petit. Mais il est également possible d'exploiter la faille avec une injection SQL classique qui permettra d'obtenir le mot de passe en un coup. Cette solution peut utiliser les mots-clés UNION et ORDER BY de MySQL. Pourquoi donc a-t-on le choix ? Tout simplement parce qu'ici, le script affiche le résultat de la requête, donc si l'on parvient à détourner la requête on pourra afficher ce qu'il nous plait. Si le script avait juste fait une vérification sur le contenu de la base sans l'afficher, la deuxième solution n'aurait pas été possible. Comme le thème de cet article est l'exploitation en aveugle, voyons donc cette première solution.

Il faut déja obtenir le nom du champ correspondant. Là, pas de secret, il faut y aller en bruteforcant. On teste "pass", "password", "motdepasse", etc. Et con croise les doigts :). Pour la suite, on considérera que le champ s'appelle "pass".

La technique utilisée ici va être de modifier la clause WHERE de la requête. Si la requête plante, la clause est fausse, sinon elle est vraie. Nous allons donc construire un bruteforceur... "intelligent". En effet, nous n'allons sûrement pas tester tous les mots de passe possibles, mais utiliser le fait qu'il y a une faille, et s'en servir :p. Nous allons tout d'abord récupérer la longueur du pass de l'admin. Puis nous testerons carcatère par caractère en utilisant la fonction SUBSTRING() de MySQL qui permet d'isoler une sous-chaîne ou caractère d'une chaîne.

Pour trouver la longueur, on appelle le script comme ceci :

En faisant varier $i, on trouvera la longueur du pass assez rapidement. Dès que la page affichera "admin aime les poissons", cela voudra dire que la longueur sera égale à $i. Les adeptes de l'optimisation peuvent utiliser la dichotomie avec les opérateurs > et < pour accélérer la recherche.

Une fois que l'on a la longueur, on utilise l'astuce de SUBSTRING en appelant le script de cette façon :

Cette fois ci, on fait varier $i pour se déplacer dans le mot de passe et bruteforcer le $ieme caractère, et on fait varier $code qui est le code ascii à tester pour ce $ieme caractère. Encore une fois, dès que "admin aime les poissons" apparait, c'est bon. On obtient le mot de passe final quand $i atteint la longueur du mot de passe trouvé précédemment.

Voici un script qui réalise le travail en PHP. (Je sais, ce n'est pas terrible comme langage pour ce type d'exploit, je compte le refaire en Perl :))

Au bout de quelques minutes on obtient le pass... le plus souvent en crypté, si l'admin a été intelligent. Mais le decryptage ne fait pas partie de cet article... à vous de vous armer des outils adéquats, d'une bonne wordlist... et de patience :). Si c'est du MD5, allez faire un tour sur Wikipédia à l'article MD5, le bas de page est bien fourni en liens vers des petits tools qui "inversent" les hashs MD5 à l'aide de tables.

Références

• Blind SQL Injection
• Article de The Hackademy sur les injections
• IT Security by girls - un blog très instructif sur la sécurité en général
• SQL Injections White Paper
• SQL Injections
• Liste de liens sur les injections
• Fonctions MySQL sur les chaînes de caractères
• Article MD5 sur Wikipedia

Sommaire

1. Exemple - Principe de base
2. Bypasser un formulaire d'authentification
3. Correction
4. Obtenir des infos - Exemples d'injections plus poussées
   1. Obtenir un mot de passe
   2. Autres exemples

1. Exemple - Principe de base

Le principe de base qui explique la présence d'une faille d'injection SQL est très simple. Observons ce code pour comprendre :

Bien qu'un peu long, ce code montre un exemple complet de page. Quel est son rôle ? C'est un moteur de recherche dans des articles, tout simplement. La vulnérabilité se situe dans le code en rouge. En effet, la requête effectuée est la suivante :

En vert se trouve le contenu encadré par des guillements simples ; c'est ce que va rechercher le script dans la table des articles, à l'aide de l'opérateur LIKE. En effet, LIKE utilisé avec le caractère '%' permet de chercher du contenu qui "ressemble" à ce qui est tapé par l'utilisateur, car le % est interprété par LIKE comme "n'importe quelle chaîne de caractères". C'est un peu comme une expression régulière ; si vous recherchez "%un%", vous pourrez obtenir n'importe quelle chaîne de caractère contenant "un", comme "une", "lune", et "brun".

Mais cet opérateur ne constitue pas une faille. La vulnérabilité est due au fait que l'entrée $_POST["rech"] n'est pas filtrée. Car nous pouvons imaginer qu'un utilisateur rentre cette chaîne : "n'importe quoi". A ce moment là, la requête devient :

Et l'on remarque très vite le problème qui va se poser : une erreur de syntaxe due au guillement, que mysql intermprète comme la fin de la chaîne de caractères. La requête ne sera pas exécutée, et le visiteur obtiendra :

Maintenant, imaginons un visiteur plus expérimenté, et qui connaît ce type de faille. Il teste une première fois le script en rentrant "n'importe quoi", le script plante et lui affiche la reqête fautive. Ensuite, voici ce qu'il pourraît rentrer dans le formulaire :

La requête devient donc :

Ici, le script ne plantera pas ; il n'y a aucune erreur de syntaxe. Le script ressortira la liste de tous les articles, puisque la condition 'a%' = 'a%' est toujours réalisée.

Ceci était un exemple de détournement de requête, mais il n'est pas très utile. Cependant, il est tout à fait possible de détourner le script afin d'obtenir des renseignements utiles sur le serveur. C'est ce que nous allons bientôt voir.

2. Bypasser un formulaire d'authentification

Laissons cet exemple de côté et penchons-nous plutôt sur un deuxième :

Ceci est un exemple très basique de formulaire de zone admin. Et non sécurisé... Mis à part qu'il soit vulnérable à une XSS, il l'est également pour les injections SQL. En effet, si nous rentrons ceci :

La requête en rouge devient

Ainsi, on peut se loguer sans connaître l'utilsiateur et le mot de passe, puisque la consition 'a'='a' est toujours vérifiée.

On se rend donc compte que les injections SQL peuvent devenir très dangereuses si l'administrateur a une politique de sécurité négligente, ou s'il n'en a pas du tout...

3. Correction

Si vous êtes webmaster, cela vous intéressera sûrement de savoir comment corriger ce type de failles. En réalité, c'est très simple, encore faut-il prendre le temps de se documenter à ce sujet...

Le premier réflexe que l'on peut avoir est de se dire "les guillements sont à proscrire, ce sont eux les causes de ce type de failles", et donc de coder un script qui enlève tous les guillements ou qui les échappe en rajouttant un antishash devant. On peut donc utiliser la fonction addslashes() ou bien utiliser les options magic_quotes_gpc et magic_quotes_runtime qui le font en parmanence pour nous. Ainsi, ce code est sécurisé :

La fonction que nous avons codé, secure(), ajouttera des antislashes si nécessaire devant tous les ', ce qui les rendra interprétés par mysql non en tant que fin de chaîne mais comme des simples caractères. Elle utilise la fonction mysql_real_escape_string(), conçue spécialement pour éviter ce type de failles.

Mais le problème de ce genre de solution apparaît très clairement lorsque nous voulons effectuer des requêtes faisant intervenir des nombres :

En effet, ici, il sera toujours possible de faire des injections SQL car il n'y a pas de guillemets encadrant le nombre (ici, $_POST["idarticle"]). On peut très bien taper "0 OR 1=1" afin de lister tous les articles. Même si c'est inutile, cela permet quand même de prouver l'existence de la faille.

On en conclut que même si une fonction de sécurisation des guillements est présente, qu'elle soit automatique ou non (magic_quotes), il y a toujours un risque. Pour l'éliminer définitivement, il faut donc faire :

On a rajouté des guillements simples encadrant le nombre, ce qui ne gène en rien Mysql. Et cela rend le script sécurisé...

Pour résumer, la solution pour se protéger des injections SQL est simple : il ne faut jamais faire confiance à l'utilisateur. Ne jamais le sous-estimer et penser qu'il n'est pas informé. Il faut alors filtrer tout ce que peut rentrer l'utilisateur avant de faire quoi que ce soit.

De plus, vous ne devez jamais laisser paraître les erreurs SQL sur votre site, car une personne malveillante peut faire planter le script volontairement afin de recueuillir des informations sur le nom des champs et des tables du serveur. C'est pour cela qu'il vaut mieux retourner un code d'erreur si une fonction échoue, plutôt que d'affiacher la requête. D'ailleurs, ici, cet affichage provoque une vulnérabilité de type XSS, car l'utilisateur malin qui injectera du javascript dans le champ fera d'une part échouer l'interaction avec la base, et d'autre part afficher son code...

4. Obtenir des infos - Exemples d'injections plus poussées

Maintenant, nous allons introduire l'exploitation de ces failles de manière avancée à travers quelques exemples. Ne perdez pas de vue le fait que ces exemples ne sont pas des cas réels ; ici, nous voulons juste montrer l'étendue de ces failles. Dans un autre articles, les "Blind Injections SQL", nous verrons concrètement comment l'on se débrouille en réalité. Je vous conseille donc de vous repporter à cet article pour obtenir des cas plus concrets.

4.i. Obtenir un mot de passe

Tout d'abord, reprenons le premier exemple, le moteur de recherche. Ce script très mal conçu affiche la requête lorsqu'il plante, donc nous allons tirer parti de cet affichage pour noter le nom des tables et des champs. Pour le deuxième exemple, nous pouvons aussi faire planter le script en mettant un guillement, ce qui nous révèle le nom de la table "membres", et des deux champs "login" et "pass", assez explicites. A présent, essayons de récupérer le login et le pass de l'admin. Nous voulons afficher ces informations. Il nous faut donc trouver un script sur le site vulnérable qui en affiche. Par exemple, le moteur de recherche affiche les articles. A l'attaque ! Voici ce que nous pouvons rentrer dans le champ :

Notez que UNION n'est disponible que depuis MySQL 4. La requête devient :

Le # représente pour MySQL un commentaire ! Remarquez que l'on peut aussi utiliser '/*'. Par conséquent, tout ce qui est après sera ignoré. La requête sélectionne donc tous les articles et ajoute (rôle du mot clé UNION) tous ces résultats à la liste des administrateurs et leur mot de passe. Notez l'astuce consistant à renomer à l'aide de AS les champs afin de réussir l'UNION. De plus, si vous croisez une table A de n champs avec une table B, B devra forcément avoir elle aussi n champs, qui devront avoir le même type. C'est pour cela que l'on sélectionne trois champs dans chaque partie de la requête. Cela peut donc produire cet affichage :

On a donc les mots de passe des deux admins, et le comble c'est qu'ils sont codés en clair !

4.ii. Autres exemples

Imaginons maintenant que nous disposons du nom d'une table et d'un champ dans cette table. Nous voulons obtenir le nom d'un champ et d'une autre table où l'on pourrait trouver des informations utiles.

La méthode à utiliser est de la divination pure et dure ;-). On peut essayer ainsi les tables "articles", "membres", "admin", "users", etc. et les champs corespondants "login", "password", "pass", etc. Mais comment tester justement ces champs et ces noms de tables ? Nous allons utiliser par exemple cette requête :

Deviner le nom d'une table

En blanc, la requête initiale, en vert, ce que l'on rentre et en bleu le commentaire. On remarque que l'on n'a fait que dupliquer la requête en ajoutant juste ",membres" dans le nom des tables à interroger. La requête va donc planter si jamais "membres" n'est pas le nom d'une table existante, et afficher des articles dans le cas contraire. Il faut donc remplacer "membres" par le nom de la table à tester.

Encore une fois, je le rappelle, tous ces exemples ne sont pas ceux que l'on utiliserait dans la réalité puisqu'ils necessitent de connaître pas mal de renseignements sur la base. Repportez-vous aux Blind SQL Injections.

Deviner le nom d'un champ dans une table connue

Nous connaissons le nom de la table (membres), nous voulons savoir le nom des champ. Nous testons :

"champatester" est le champ dont nous voulons vérifier la présence. Si la requête réussit, il existe, sinon, il n'existe pas.

Deviner un mot de passe

Dans certains cas il arrive que le contenu d'un champ soit accesible mais non affiché. C'est le cas par exemple de notre formulaire de zone admin : on ne peut pas directement afficher le mot de passe. Il faut donc procéder par essais successifs :

A croiser bien sûr avec une injection SQL. Si la session d'admin s'ouvre, c'est que son mot de passe commence par un 'a'. Sinon, on essaye avec 'b', puis ainsi de suite. On remonte les caractères jusqu'à trouver le mot de passe complet.

Si l'on veut connaître le nombre de caractères du mot de passe, on peut utiliser l'opérateur LENGTH() comme ceci :

Les méthodes que nous venons de voir se font par bruteforcing, puisqu'elles ne nous permettent pas d'obtenir les informations de manière directe, mais simplement de savoir si l'on a bon ou faux. L'opérateur AS est très pratiques dans ces situations puisqu'il permet de renomer un champ temporairement pour la requête, donc de croiser deux champs différents.

SHOW et GRANT : obtenir tout ce que l'on veut (?)

Les deux opérateurs ultimes dont nous aurions besoin sont GRANT et SHOW. Ils permettent de lister la structure complète de la base, des tables, lister les utilisateurs, leurs privilèges et leur mot de passe. Le seul problème majeur est qu'il est impossible de les utiliser en les croisant avec SELECT. Impossible donc d'y avoir accès dans les exemples que nous venons de voir.

Les petits malins auront envie d'utiliser le point virgule afin d'effectuer deux requêtes l'une après l'autre, mais un autre problème nous en empêche : mysql_query(). Cette fonction interagit entre PHP et MySQL mais ne peut permettre que d'effectuer UNE SEULE requête à la fois. Le point virgule est donc à bannir. Et GRANT/SHOW par la même occasion... sauf si c'est une autre fonction qui est utilsée, et qui permet ce genre de choses !

Ainsi, vous sere peut-être déçu mais il est impossible d'utiliser un opérateur tel que UPDATE, DROP, ou INSERT si la requête commence par SELECT. A moins, comme nous l'avons dit, que la fonction utilisée le permette.

Obtenir la version du serveur

Nous pouvons utiliser les variables spécifiques à chaque serveur SQL. Pour MYSQL, la variable @@version contient le nom de la version du serveur. Ainsi, SELECT @@version affiche cette version. Il faut bien entendu exploiter une injection afin de pouvoir utiliser cette commande. Pour les autres serveurs, c'est une autre variable. Il suffit de chercher un peu dans les documentations pour les trouver.

Créer un fichier

La directive INTO OUTFILE [nom_fichier] croisée avec SELECT permet de créer un fichier contenant les informations de SELECT demandées. On peut donc imaginer un scénario où vous exploitez tout d'abord une injection SQL se situant dans une requête INSERT ce qui vous permet d'écrire du code dans la base, puis vous exploitez une deuxième injection dans SELECT afin de créer un fichier contenant le code que vous avez écrit dans la base. Si c'était du code PHP, une backdoor par exemple, ou un simple script d'une ligne contenant une faille Include, vous obtiendrez un accès supplémentaire sur le serveur.

Cependant, il faut déja obtenir l'url vers laquelle écrire le fichier, car si vous écrivez à la racine du serveur, cela peut d'une part sembler louche, d'autre part ne pas être accessible sur le serveur... En effet, si votre fichier écrit se trouve avant le répertoire "www" d'Apache, c'est fichu...

Utiliser un fichier pour effectuer des opérations

Il est possible d'utiliser LOAD DATA INFILE [nom_fichier] pour lire un fichier et effectuer les opérations SQL décries à l'intérieur. C'est le complément de INTO OUTFILE. Le seul problème, c'est que LOAD n'est pas compatible avec SELECT, donc inutilisable dans la grande majorité des cas.

Conclusion

Vous l'aurez compris, les injections SQL dépassent complétement le cas d'école avec ' or ''='. Il y en a des tonnes, plus ou moins adaptées à ce que l'on veut faire. Les seuls limites sont celles du langage SQL, qui nous empêche parfois de croiser des requêtes pourtant bien pratiques... Dans un second article sur les injections SQL dites "blind", ou "à l'aveuglette", nous exploiterons à fond le langage SQL afin de faire révéler aux scripts vulnérables des informations cruciales.

Le but de cet article n'était bien entendu pas d'inciter les gens à exploiter des failles sur des sites existants, mais surtout de comprendre le fonctionnement de ce type de failles, afin de mieux savoir s'en protéger, par exemple.

Références

Cet article a été écrit en grande partie à l'aide de mes connaissances, mais voici quelques liens qui vous permettront d'approfondir le sujet :

• The Hackademy - Injections SQL
• Manuel de référence PHP - Très utile pour la sécurisation des scripts

Première année de fac de Sciences 

Licence d'informatique 

Premier emploi 

Informaticien confirmé 

Administrateur système 

Apprenti Hacker 

Hacker expérimenté 

Hacker confirmé 

Hacker gourou 

Manager débutant 

Manager expérimenté 

Manager confirmé 

Président Directeur Général