lfi_scanner 是一个基于 Python 的轻量级参数级路径遍历探测工具，不能直接挖出 PHP LFI 漏洞；它通过发送如 ../../../../etc/passwd 类 payload，依据响应长度、状态码或关键词变化推测 LFI 存在性，不执行代码、不解析响应内容真伪，也不处理 php://filter 等编码绕过。
lfi_scanner 是什么，它能直接挖出 PHP LFI 漏洞吗
lfi_scanner 是一个基于 Python 的轻量级工具，主要做「参数级路径遍历探测」，不是全自动漏洞利用器。它不会执行任意 PHP 代码、不解析响应内容是否真包含文件（比如 /etc/passwd），而是靠发送构造的 ../../../../etc/passwd 类 payload，再比对响应长度/状态码/关键词变化来推测是否存在 LFI。它不分析 PHP 代码逻辑，也不处理 php://filter 或 data:// 等编码绕过——这些得手动跟进。
怎么装和跑 lfi_scanner（Kali 默认没预装）
它不在 Kali 官方源里，得手动克隆安装：
git clone https://github.com/kurobeats/lfi-scanner.git cd lfi-scanner pip3 install -r requirements.txt
运行前确认目标存在可测参数（比如 http://target.com/page.php?page=about），然后执行：
python3 lfi-scanner.py -u "http://target.com/page.php?page=about" -w /usr/share/wordlists/seclists/Fuzzing/LFI-LFISuite-paths-kali.txt
-
-u必须带完整 URL 和原始参数值（不能只写page.php?page=） -
-w推荐用 SecLists 里的LFI-LFISuite-paths-kali.txt，比默认字典覆盖更全 - 如果目标用了 WAF 或反爬，加
--delay 2降速，否则容易被封 IP 或返回 403 - 它默认只输出疑似结果（status code 变化或响应体长度突变），不自动验证是否真能读取
/etc/passwd
扫出来“疑似 LFI”后，怎么手动验证是不是真洞
工具标红的 URL 只是起点，必须人工验证，否则大概率误报。典型验证步骤：
立即学习“PHP免费学习笔记（深入）”；
- 用 curl 手动发：
curl "http://target.com/page.php?page=../../../../etc/passwd"，看是否返回系统用户列表 - 试编码绕过：
curl "http://target.com/page.php?page=..%2f..%2f..%2f..%2fetc%2fpasswd"（URL 编码）、?page=....//....//....//etc/passwd（双斜杠混淆） - 检查是否支持伪协议：
?page=php://filter/convert.base64-encode/resource=/etc/passwd，返回 base64 再解码确认 - 注意响应里是否有 PHP warning（如
Warning: include(): Failed opening '...' for inclusion），这类提示说明 include() 被调用，但路径没拼对——反而说明存在 LFI 可控点
为什么扫不到真实 LFI？常见卡点在哪
很多情况下 lfi_scanner 会漏报，不是工具问题，而是 PHP 层面做了限制：
- PHP 配置禁用了远程文件包含：
allow_url_include = Off（不影响本地包含，但影响后续 RCE 尝试） - 用了
basename()、str_replace()过滤点号和斜杠，导致../被删或替换为空 - 参数值被强制加了固定后缀，比如
include($_GET['page'] . '.php');，此时扫/etc/passwd会去包含/etc/passwd.php，自然失败 - Web 服务器（如 Nginx）配置了
location ~ \.php$规则，但没限制..路径，而 PHP-FPM 实际收到的 PATH_INFO 仍含上级目录——这种需要结合 Nginx 日志或 FastCGI 参数调试，lfi_scanner无法感知
真正卡住的地方往往不在扫描器本身，而在你有没有去看响应头里的 X-Powered-By、有没有抓包确认服务端是否真的收到了 payload、有没有试过把 page 换成 file view inc 等常见参数名——这些都比换十个扫描器重要。
