综合php项目，防守漏洞怎么识别定位？

本文目录导读：

1. 第一阶段：黑盒探测（建立攻击面地图）
2. 第二阶段：白盒静态审计（核心定位）
3. 第三阶段：动态验证与触发（确认存在性）
4. 第四阶段：辅助工具与全局配置排查
5. 第五阶段：业务逻辑漏洞（特殊定位法）
6. 总结：最快的定位路径（套路）

针对PHP项目的防守漏洞识别与定位,需要一套系统化、层次化的排查思路，单纯的代码审计容易遗漏业务逻辑漏洞，而单纯依赖扫描工具又会产生大量误报。

以下是一套从黑盒（外部视角）到白盒（源码视角）、从静态到动态的完整漏洞定位实战指南：

第一阶段：黑盒探测（建立攻击面地图）

在动手看代码之前,先用工具确定“哪里可能有漏洞”，这能帮你快速缩小范围。

1. 资产指纹与路径扫描

   • 工具：Dirsearch、ffuf、Nuclei。
   • 定位：扫描出隐藏的备份文件（.bak）、源码泄露（.git）、未授权访问的admin目录、旧的接口（/api/v1/old/）。
   • 识别技巧：如果扫出.git，直接用git-dumper拉取源码——这是最高效的定位方式。

2. 参数污染与输入点收集

   • 方法：利用Burp Suite爬虫，或者通过查看前端JS文件，找出所有接收用户输入的地方（GET参数、POST表单、JSON体、Header头）。
   • 重点标记：id、uid、page、file、url、path、order、sort等常见高风险参数名，后续重点看这些。

3. 入口点探针测试（触发报错）

   • 方法：输入单引号或，观察返回结果。
   • 定位：如果页面返回SQL语法错误或原生的PHP警告（如Warning: mysql_fetch_array()），说明此处存在原生写法的SQL查询，且错误报告未关闭，这种地方的漏洞往往比较低级但可直接利用。

第二阶段：白盒静态审计（核心定位）

结合黑盒结果和业务逻辑,深入源码定位问题，使用RIPS、Fortify或PHPStan（配合安全规则）可以输出危险函数列表，但关键是结合业务上下文判断是否可利用。

高危函数特征追踪法（寻找触发点）

追踪以下关键字一旦被用户输入污染,即为漏洞点：

• SQL注入：搜索 mysqli_query、PDO->query、where + 变量拼接。重点看变量是否被单引号包裹（'$id'）即可判断。
• 文件包含：搜索 include、require、file_get_contents。重点看变量是否拼接后缀（.php）以及是否可控路径（如 /uploads/）。
• 命令执行：搜索 exec、system、shell_exec、passthru、proc_open。只要参数拼接了用户输入且无白名单过滤，大概率RCE。
• 文件上传：搜索 move_uploaded_file。重点看后缀校验（是校验扩展名还是MIME类型，是否在服务端用getimagesize校验）。
• 反序列化：搜索 unserialize、__destruct、__wakeup。重点看unserialize的数据是否来自$_COOKIE或$_POST，且是否存在魔法函数。

数据流追踪法（确认污点可达）

找到危险函数后,反向追踪其参数来源。

• 正向追踪：$_GET -> trim() -> addslashes() -> sql query。
  • 如果经过了addslashes和单引号包裹，闭合难度增大，判定为低危或误报。
  • 如果直接$_GET -> sql query，则高危。
• 反向追踪：看到$db->query(sql)，向上看sql从哪里组装来的。
• 特别关注：全局过滤机制，查看common.php或init.php中是否有addslashes或htmlspecialchars的全局魔法引号处理，这决定了所有漏洞的利用难度。

框架与原生代码差异识别

如果是ThinkPHP、Laravel等框架，漏洞定位逻辑不同：

• ThinkPHP：重点看控制器（Controller）中的input()函数，如果使用手动拼接（如Db::query("select * from user where id=" . input('id'))），漏洞极大，框架自带ORM通常安全。
• Laravel：重点看Request::get()和DB查询构造器，重点看是否使用了whereRaw或DB::raw()。

第三阶段：动态验证与触发（确认存在性）

静态发现后,必须动态验证，避免误报。

1. SQL注入触发定位

   • 使用Burp发送 id=1 and 1=2（返回空）与 id=1 and 1=1（返回正常）对比，确认数字型注入。
   • 发送 id=1'，看是否报错，报错信息中是否包含SQL片段。
   • 如果过滤了空格和union，尝试用或十六进制绕过，验证过滤强度。

2. 文件上传绕过验证

   • 直接上传.php被拦截，改为上传.php3、.phtml、.php.（末尾加点）、.php%00.jpg。
   • 上传图片马后,尝试包含该文件（/index.php?page=uploads/1.jpg），验证是否GETSHELL。

3. 重定向与越权验证

   • 修改Cookie中的user_id为其他数值，或者修改JWT中的签名（若无签名验证），查看是否可访问其他用户数据。

第四阶段：辅助工具与全局配置排查

很多漏洞的根源不在具体业务代码,而在配置。

1. 敏感信息泄露（高危信息）

   • 定位：扫描全项目，寻找config.php中的数据库明文密码、Redis密码、云厂商密钥（AccessKey），登录云平台，直接接管服务器。
   • 检查phpinfo()页面是否暴露，且FastCGI端口是否对外开放。

2. 错误处理逻辑（Debug模式）

   • 如果display_errors = On，所有SQL报错、文件路径报错会暴露物理路径，大大降低利用门槛（这就是为什么很多SQL注入是报错注入的原因）。

3. 日志审计（事后回溯）

   • 如果你的目标是寻找已存在的攻击痕迹，直接查看/var/log/apache2/access.log或error.log。
   • 定位特征：搜索包含select、union、../../../../etc/passwd、/proc/self/environ等关键字的访问记录，这些日志指向的请求参数位置，就是被攻击的漏洞点。

第五阶段：业务逻辑漏洞（特殊定位法）

这是纯工具测不出来的,需要人工逻辑分析：

1. 支付/订单逻辑：找接口（如/api/pay.php），重点看金额参数（money、price）是否从客户端传入，是否校验了签名或服务端重算价格。
2. 验证码/密码重置：定位send_code函数，看验证码是否存储在Session中（安全）还是直接存储在Cookie或前端返回的JSON中（危险）。
3. 越权：定位所有涉及查询详情的接口（如user.php?id=100），尝试将ID改为101，如果返回了新用户数据，则存在水平越权（IDOR）。

最快的定位路径（套路）

1. 先看报错 -> 触发报错，看物理路径和源码上下文。
2. 先看上传 -> 搜move_uploaded_file，找上传点，一般最容易getshell。
3. 先看登录 -> 搜select * from user对应代码，看是否存在万能密码或SQL注入。
4. 先看入口 -> 查看index.php或router.php（路由核心），看它如何解析URL，这里经常有文件包含漏洞。
5. 后门查找 -> 在uploads目录、public目录搜索.php后缀文件，查看是否有eval($_POST['x'])，很多项目被植入过Webshell，这就是防守方最容易忽略的漏洞。

一句话核心：找用户可控变量，追踪到危险函数（SQL/文件/命令），结合全局过滤器绕过，即可完成从识别到定位的全过程。