Kali挖PHP漏洞方法与步骤解析

大家好，今天本人给大家带来文章《Kali挖PHP漏洞步骤详解》，文中内容主要涉及到，如果你对文章方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

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 只是起点，必须人工验证，否则大概率误报。典型验证步骤：

• 用 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 等常见参数名——这些都比换十个扫描器重要。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。