fimap 扫描前须手动验证目标是否存在动态 include 行为，仅当确认基础 LFI 可能性存在时再使用；优先用 -u 单 URL 模式而非失效的 -g 模式；报 PHP 版本未知不影响扫描，关键看 [+] Found possible LFI 输出；需手工补测 data://、phar:// 等 fimap 未覆盖协议，并结合上下文深入利用。
用 fimap 扫描 PHP 文件包含漏洞前，先确认目标是否真有 include/require 类动态加载行为
fimap 不是“扫到参数就报洞”的傻瓜工具，它依赖目标 PHP 脚本实际存在动态文件加载逻辑。如果目标用的是硬编码路径、或参数根本没进 include 函数，fimap 的 payload 就会 404 或返回原始页面，误报率极高。
建议手动验证：在 URL 中传入类似 ?file=php://filter/read=convert.base64-encode/resource=/etc/passwd，看是否回显 base64 内容；或者尝试 ?page=../../../../etc/passwd 看是否读取成功。只有确认基础 LFI 可能性存在，再上 fimap 才有意义。
fimap 的 -u 和 -g 模式区别很大，别混用
-u 是单 URL 模式，适合你已知一个带参数的入口（如 index.php?page=home），fimap 会自动 fuzz 参数值并检测各种包含协议和路径遍历变体；-g 是 Google dork 模式，靠搜索引擎找疑似脆弱 URL，但 Kali 默认不配 Google API key，且现在多数 dork 已失效，返回结果杂乱，容易漏掉真实入口。
实操建议：
- 优先用
fimap -u "http://target.com/index.php?page=test"，确保 URL 中参数值为可替换的占位符（如test） - 加
-m启用多线程（默认 5，可设为-m 10），但别超过 20，否则易被 WAF 拦或触发服务端限流 - 避免用
-g，除非你有自建的敏感目录字典或历史爬虫结果
fimap 报 [!] Could not determine remote PHP version 不代表扫描失败
这个提示只是说明 fimap 无法通过响应头或错误页面推断 PHP 版本（比如目标禁用了 expose_php，或 Nginx 隐藏了版本），但它仍会继续发送 payload 并比对响应差异来判断漏洞。真正关键的是看最后的 [+] Found possible LFI in parameter 'file' 这类输出。
常见干扰项：
- 目标返回 500 但内容为空 → 可能是 PHP fatal error 被屏蔽，换
--force强制继续 - 所有 payload 返回 200 但内容一致 → 检查是否参数根本未被解析（如 Apache 没启用 mod_php，或脚本里压根没调用
include） - 遇到 WAF（如 Cloudflare、ModSecurity）→ fimap 默认 UA 和 payload 特征明显，建议加
--user-agent "Mozilla/5.0"和--delay 1降速
别只盯着 php://filter，fimap 对 data:// 和 phar:// 的检测很弱
fimap 主要覆盖传统路径遍历和 php://filter 读取源码，但它对 PHP 5.6+ 支持的 data://text/plain;base64,... 协议、以及需要配合反序列化的 phar:// 利用几乎不检测。这些往往才是绕过 WAF 或读取无扩展名配置文件的关键。
所以：
立即学习“PHP免费学习笔记（深入）”；
- 扫完 fimap 后，手动补测：
?file=data://text/plain;base64,PD9waHAgcGhpcGluZm8oKTsgPz4=（base64 解码后是） - 若发现
.phar文件上传点，后续得换ffuf或手写脚本爆破phar://xxx路径，fimap 做不了这事 - 遇到
allow_url_include=Off时，fimap 的绝大多数 payload 失效，此时应转向 SSRF 或本地日志包含等其他利用链
/var/log/apache2/access.log，也不会自动把 phpinfo() 页面里的临时文件路径拼成 phar:// 链。 
