不能。SQLiv仅通过搜索引擎语法（如inurl:".php?id="）搜集疑似含SQL注入点的URL列表，不发请求探测、不验证漏洞、不解析源码，需配合sqlmap等工具二次验证。
SQLiv 能不能直接扫 PHP 注入点？
不能。SQLiv 是一个基于 Google、Bing 等搜索引擎的 SQL 注入漏洞“线索发现”工具，它本身不发 HTTP 请求探测 php?id=1 这类参数，也不解析 PHP 源码或执行注入测试。它只做一件事：用特定语法（如 inurl:".php?id="）从搜索引擎结果里扒出可能带注入点的 URL 列表。
所以你看到“SQLiv 扫 PHP 注入”，实际是两步：先用 SQLiv 收集目标 URL，再用 sqlmap 或手工验证是否真能注入。
- SQLiv 输出的是
http://example.com/news.php?id=2这样的链接，不是漏洞确认结果 - 它不识别 PHP 版本、WAF 类型、过滤逻辑，也不处理重定向或 403 封锁
- 如果目标站禁用了搜索引擎收录（
robots.txt或noindex），SQLiv 就完全扫不到
在 Kali 里怎么装和跑 SQLiv？
Kali 默认不预装 SQLiv，需手动安装。注意：原项目（sqliv on GitHub）已归档停更，当前可用的是社区维护分支，推荐用 sqliv-ng（兼容 Python3，修复了 UA 和搜索接口失效问题）。
执行以下命令安装：
立即学习“PHP免费学习笔记（深入）”；
git clone https://github.com/0xInfection/sqliv-ng.git cd sqliv-ng sudo pip3 install -r requirements.txt sudo python3 setup.py install
运行示例（搜含 .php?cat= 的页面）：
sqliv -e google -d ".php?cat=" -t 5
-
-e google：指定搜索引擎，bing有时返回更多老站点 -
-d ".php?cat="：搜索关键词，建议加引号避免 shell 解析错误 -
-t 5：并发线程数，别设太高，否则容易被封 IP 或触发验证码 - 输出结果默认保存在
results.txt，每行一个 URL，可直接喂给 sqlmap
扫出来的 PHP URL 怎么验证是不是真有注入？
别直接拿 SQLiv 结果去跑全量 sqlmap —— 效率低、易被 WAF 拦。先做轻量级筛选：
- 用
curl -I检查 HTTP 状态码，过滤掉 404/503/302 跳转太多的 URL - 用
sqlmap -u "http://x.com/a.php?id=1" --batch --level=1 --risk=1 -v 1快速试探：只测 GET 参数、不做深度检测、输出精简 - 若返回
[INFO] heuristic (basic) test shows that GET parameter 'id' might be injectable，再加--technique=BEU或--dump - 遇到 Cloudflare 或百度云加速，加
--random-agent和--delay=2降低触发阈值
特别注意：很多“PHP 注入点”其实是伪静态（如 /article/123 实际由 PHP 处理），SQLiv 无法识别这类路径，得靠目录扫描（gobuster -u http://x.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt）补漏。
为什么扫了一堆 PHP 链接却一个可注入的都没有？
这是常态，不是工具问题。真实环境中，90% 以上的公开 PHP URL 已经：开了 WAF、参数被 intval() 强转、用了 PDO 预处理、或根本没接数据库。SQLiv 只放大“可能性”，不保证“可行性”。
容易被忽略的关键点：
- SQLiv 的关键词必须匹配真实参数名，比如
id、cat、page，但现代 CMS 常用post_id、entry等，得自己构造词库 - Google 搜索限制严格，
site:*.cn inurl:.php?这类指令现在基本无效，得换cache:或用shodan查暴露的 Apache 日志 - 有些 PHP 页面虽有
?id=，但后端用的是 Redis 或文件读取，跟 SQL 完全无关——得看响应体是否含 MySQL 报错、mysql_fetch等特征
真正有效的 PHP 注入挖掘，从来不是靠一个工具扫完就收工，而是把 SQLiv 当成情报入口，后面必须接响应分析、WAF 识别、源码片段比对这些动作。
