Jcpraud at 19:02, 12 January 2015

2015-01-12T19:02:45Z

Jcpraud at 18:59, 12 January 2015

2015-01-12T18:59:21Z

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Une vulnérabilité d'inclusion de fichier permet à un attaquant d'inclure un fichier, usuellement en eploitant un mécan..."

2015-01-12T18:49:10Z

Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Une vulnérabilité d'inclusion de fichier permet à un attaquant d'inclure un fichier, usuellement en eploitant un mécan..."

New page

{{Template:OWASP Testing Guide v4}}
== Sommaire ==

Une vulnérabilité d'inclusion de fichier permet à un attaquant d'inclure un fichier, usuellement en eploitant un mécanisme d'inclusion dynamique de fichier implémenté dans l'application visée. La vulnérabilité survient à cause d'entrées utilisateur utilisées sans validation correcte.

Cela peut entraîner une impact comme l'affichage du contenu du fichier, mais selon lé criticité, cela peut aussi causer :

* L'exécution de code sur le serveur web
* L'exécution de code côté client, comme du JavaScript, qui peut permettre d'autres attaques comme le cross site scripting (XSS)
* Un déni de service (DOS)
* Des fuites d'informations sensibles

L'inclusion de fichiers locaux (aussi connue sous le nom de LFI : '''Local File Inclusion''') est le processus par lequel on va inclure des fichiers déjà présents sur le serveur, en exploitant des procédures d'inclusion vulnérables implémentée par l'application. Cette vulnérabilité advient, par exemple, lorsqu'une page reçoit en entrée le chemin d'un fichier devant être inclus et que cette entrée n'est pas validée correctement, autorisant l'injection de caractères permettant de changer de répertoire (tels que point-point-slash). Bien que la plupart de nos exemples soient en PHP, c'est une vulnérabilité commune à d'autres technologies comme JSP, ASP, etc.

== Comment tester ==

Comme les LFI adviennent quand des chemins passés à des instructions "include" ne sont pas correctement validés, dans un approche en boite noire, il faudra rechercher les scripts qui prennent des noms de fichiers en paramètres.

Considérons l'exemple suivant :

<pre>
http://vulnerable_host/preview.php?file=example.html
</pre>

Cela semble être l'endroit parfait pour tenter un LFI. Si un attaquant a assez de chance, et que le script inclut directement le paramètre au lieu de sélectionner la page dans un tableau, il est possible d'inclure arbitrairement tout fichier du serveur.

Une preuve de concept typique est de charger le fichier des mots de passe :
<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd
</pre>

Si les conditions mentionnées plus haut sont réunies, un attaquant verra quelque chose ressemblant à :
<pre>
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...
</pre>

Très souvent, même quand de telles vulnérabilités existent, leurr exploitation est un peu plus complexe. Considérons le morceau de code suivant :
<pre>
<?php “include/”.include($_GET['filename'].“.php”); ?>
</pre>

Dans ce cas, un simple remplacement du nom du fichier ne fonctionnera pas puisque le suffixe '.php' est ajouté. Pour contourner cela, on utilise une technique avec des terminateurs octets nuls. Comme %00 indique la fin de la chaîne, tout caractère suivant cet octet spécial sera ignoré. Ainsi, la requête suivante retournera aussi la liste des attributs basiques des utilisateurs :

<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
</pre>

== Références ==

* Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
* Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion

== Remédiation ==

La solution la plus efficace pour éliminer les vulnérabilités d'inclusion de fichier est d'éviter de passer des entrées utilisateurs à toute API de système de fichiers. Si ce n'est pas possible, l'application peut maintenir une liste blanche de fichiers pouvant être inclus dans la page, et utiliser un identifiant (par exemple l'index) pour accéder au fichier sélectionné. Toute requête contenant un identifiant invalide devra être rejetée, ainsi il n'y aura pas de surface d'attaque permettant aux utilisateurs malicieux de manipuler le chemin.

← Older revision		Revision as of 19:02, 12 January 2015
Line 18:		Line 18:
	== Comment tester ==		== Comment tester ==

−	Comme les LFI adviennent quand des chemins passés à des instructions "include" ne sont pas correctement validés, dans un approche en boite noire, il faudra rechercher les scripts qui prennent des noms de fichiers en paramètres.	+	Comme les LFI adviennent quand des chemins passés à des instructions "include" ne sont pas correctement validés, dans une approche en boite noire, il faudra rechercher les scripts qui prennent des noms de fichiers en paramètres.

← Older revision		Revision as of 18:59, 12 January 2015
Line 5:		Line 5:


−	Cela peut entraîner ~~une~~ impact ~~comme~~ l'affichage du contenu du fichier, mais selon lé criticité, cela peut aussi causer :	+	Cela peut entraîner comme impact l'affichage du contenu du fichier, mais selon la criticité, cela peut aussi causer :

	* L'exécution de code sur le serveur web		* L'exécution de code sur le serveur web

4.8.12.1 Tester l'inclusion de fichiers locaux - Revision history

Jcpraud at 19:02, 12 January 2015

Jcpraud at 18:59, 12 January 2015

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Une vulnérabilité d'inclusion de fichier permet à un attaquant d'inclure un fichier, usuellement en eploitant un mécan..."