Les runtimes de langage exposent des wrappers de flux : des pseudo-protocoles qui permettent aux fonctions de fichier ordinaires d'opérer sur des choses qui ne sont pas de simples fichiers. PHP est de loin la cible la plus riche, avec php://, phar://, data://, zip://, et d'autres. Lorsqu'une application passe une entrée influencée par l'attaquant à une fonction de fichier (include, fopen, file_get_contents, getimagesize, copy), ces wrappers transforment ce qui ressemble à une lecture de fichier en divulgation de source, désérialisation ou exécution de code. C'est un problème de couche runtime car la capacité provient du moteur, non de la logique propre à l'application.
Pourquoi c'est important#
Un bug de traitement de chemin qui ne serait autrement qu'une lecture de fichier local limitée devient bien plus lorsque les wrappers sont disponibles :
php://filterlit et transforme le contenu des fichiers, en extrayant le code source, et des filtres chaînés peuvent synthétiser du PHP exécutable à partir d'aucun fichier.phar://désérialise les métadonnées d'archive dès qu'une fonction de fichier touche le chemin, atteignant l'injection d'objet sans appel àunserialize().data://etphp://inputfournissent du contenu contrôlé par l'attaquant directement à uninclude(les deux requièrentallow_url_include=On) ; lorsque ce réglage est désactivé, les chaînesphp://filteratteignent toujours l'exécution de code sans dépendance de configuration.
Pages#
- Wrapper php filter : lire la source et des fichiers arbitraires avec
php://filteret les filtres de conversion. - Chaînes de filtres vers RCE : synthétiser un payload PHP purement par des filtres de conversion chaînés.
- Désérialisation phar : déclencher une injection d'objet via
phar://lors des opérations de fichier. - Wrappers data et input :
data://,php://inputetexpect://pour l'inclusion et l'exécution directes.
Références#
- PHP manual: supported protocols and wrappers
- PortSwigger Web Security Academy: File path traversal, LFI