Локальное включение файлов Local File Inclusion относится к классу уязвимостей веб приложений при котором, пользовательский ввод попадает в путь к файлу включаемому сервером. В результате злоумышленник получает возможность читать произвольные файлы операционной системы, а в ряде сценариев переходит к исполнению кода и полному захвату приложения.
Типичная причина LFI отсутствие строгой валидации параметров используемых в конструкциях вида include require или при чтении шаблонов конфигураций и логов. Если разработчик полагается на простые строковые проверки и не учитывает особенности файловой системы, кодировок и особенностей веб сервера открывают широкие возможности для эксплуатации уязвимости.
Основные методы эксплуатации LFI
Базовый сценарий проверки веб приложения заключается в подстановке относительных путей с переходами по каталогам. В простейшем случае GET параметр page допускает значение news.php, но не фильтрует последовательность ../. Пример URL запроса:
https://target.example/index.php?page=../../../../etc/passwd
В случае, если уязвимость присутствует в системе, в ответе система может вернуть содержимое системного файла /etc/passwd что уже нарушает конфиденциальность. На платформах с интерпретацией PHP дополнительно используются обёртки вида php://filter позволяющие получать исходный код скриптов в кодировке base64 и анализировать логику веб приложения.
Следующий уровень опасности уязвимости связан с переходом от чтения файлов к вредоносной эксплуатации кода приложения. Для этого злоумышленник пытается внедрить произвольный PHP фрагмент в лог веб сервера или в файл сессий, а затем подключить его через LFI. Например, если строка логов содержит параметр User Agent, злоумышленник подставляет туда конструкцию с функцией system а после запрашивает включение вредоносного файла.
Инструменты и практические приёмы обнаружения
Начальный этап тестирования LFI выполняется вручную в браузере или через выполнение curl запроса в терминале. Аналитик выявляет параметры похожие на имя файла шаблона языка или модуля и подставляет диагностические значения. Пример:
curl "https://target.example/index.php?page=../../../../etc/passwd"
curl "https://target.example/index.php?page=php://filter/convert.base64-encode/resource=index.php"
Для автоматического перебора используют технику фаззинга запросов. Распространённый инструмент для выполнения этой задачи ffuf. Инструмент входит в базовый набор Kali, Parrot, Arch Linux, или устанавливается в систему из исходников git. Пример инсталляции и использования приложения в системе:
git clone https://github.com/ffuf/ffuf.git
cd ffuf
go build
./ffuf -u "https://target.example/index.php?page=FUZZ" -w wordlists/lfi.txtМаркер FUZZ указывает место подстановки строк из словаря. Уже на этом шаге ffuf покажет коды ответа и размеры страниц для каждого варианта пути. Чтобы отсечь очевидный шум, используют фильтрацию по статусу и авто калибровку
ffuf -u "https://target.example/index.php?page=FUZZ" \
-w /usr/share/wordlists/lfi.txt \
-mc 200 -ac
Ответы с повторяющимся размером и шаблонной страницей ошибки ffuf помечает как фон. Отличающихся по размеру или содержанию запросов ffuf помечает как потенциально уязвимые, затем такие страницы изучаются вручную через браузер или прокси. Для POST запросов команда запуска почти не меняется
ffuf -u https://target.example/download \
-X POST -d "file=FUZZ" \
-H "Content-Type: application/x-www-form-urlencoded" \
-w /usr/share/wordlists/lfi.txt -mc 200 -ac
При необходимости трафик направляют в Burp или ZAP для параллельного анализа использовав опцию прокси
ffuf -u "https://target.example/index.php?page=FUZZ" \
-w /usr/share/wordlists/lfi.txt \
-x http://127.0.0.1:8080 -mc 200 -ac
Число потоков регулируется ключом -t а предельная частота запросов параметром -rate чтобы не перегрузить тестируемый ресурс.
В OWASP ZAP аналогичная функция реализована в модуле Fuzzer. Достаточно выбрать нужный параметр в интерфейсе и прикрепить к нему словарь. Параллельно ZAP может выполнять активное сканирование и выдавать свои находки по LFI в отдельном отчёте.
При таком подходе ffuf, Burp Suite и OWASP ZAP не заменяют друг друга, а образуют связку где быстрое автоматическое покрытие параметров дополняется тщательным разбором ограниченного числа подозрительных ответов, что делает поиск LFI управляемым и автоматизированным процессом.
