Ceci est une ancienne révision du document !
Deuxième défi : Inclusion distante de fichiers
1 Objectif
Le but de cette première série de questions est de travailler sur des inclusions distantes afin de faire exécuter sur le serveur cible un code malveillant hébergé sur le serveur web du pirate. C’est la machine kali qui contient burpsuite qui fera office de serveur web malveillant.
2 À vous de jouer
Les questions suivantes se traitent en suivant les étapes décrites dans le dossier documentaire.
Travail à faire 3 Injection distante
Pour tester une injection distante, un mode opératoire est proposé sur l’application Mutillidae via la fourniture d’un script.
- Q1. Positionner le niveau de sécurité à 0 puis démarrer le serveur web apache présent sur la machine kali via la commande service apache2 start.
- Q2. Tester l’injection d’un lien externe (google par exemple ou une autre ressource locale si votre maquette n’a pas d’accès à internet).
- Q3. Créer le script proposé par Mutillidae sur la page suivante : Hints and Videos⇒ Remote File Inclusion
Déplacer ce script sur le serveur web du pirate puis tester son fonctionnement local.
Q4. Tester l’injection distante de ce script depuis l’application Mutillidae via l’url suivant qu’il faut adapter : (http://mutillidae et http://[ATTACKING SERVER IP ADDRESS])
Qu’observe t-on ?
Travail à faire 4 Codage sécurisé et analyse du code source
Le but de cette deuxième partie est de tester à nouveau l’attaque après activation du codage sécurisé et de comprendre le codage mis en place pour sécuriser la page.
Q1. Tester les niveaux de sécurité 1 et 5 et confirmer le comportement observé lors de l’injection locale.
Q2. Consulter le manuel PHP afin d’expliquer le rôle de la fonction preg_match présente dans le code sécurisé.
Prolongement possible :
Reprendre une application existante et mettre en place le niveau de sécurité 5.
i Contre-mesures
Les injections locales ou distantes ont lieu lorsqu’une application inclut dans une page un flux ou un fichier qui est défini via une entrée utilisateur. Ce flux doit être vérifié avant d’être exécuté.
Pour se prémunir des attaques par injection de fichiers, il n’y a pas d’autre manière que de filtrer et valider les entrées utilisateurs. Il ne faut jamais inclure ou exécuter directement une entrée utilisateur. Pour le cas des injections distantes, il est possible de désactiver les directives “allow_url_open” et “allow_url_include” à “Off” si leur utilisation n’est pas nécessaire. Un mécanisme de liste blanche ou de liste noire de caractères interdits ou autorisés peut être mis en place. Cette vulnérabilité est de moins en moins présente dans les applications récentes qui sont basées majoritairement sur des framework robustes.