核心是识别绕过参数绑定的5类高危写法：Db::raw()、where(...,'exp',...)、order()/group()动态字段、where(字符串/闭包)、数组where键名动态；须逐个验证参数是否可控且未经白名单或类型校验。
排查ThinkPHP 6.2项目的SQL注入风险，核心是识别“绕过参数绑定”的写法。框架本身默认对标准where()、find()等调用做了安全处理，但一旦开发者手动拼接SQL结构（比如字段名、排序方向、表达式），就等于主动关闭了防护开关。
重点搜这5类高危模式
用编辑器或命令行全局搜索以下关键词，逐个确认参数来源是否可控：
-
Db::raw(：如
where('status', Db::raw($_GET['sql']))，直接执行原始SQL片段 -
where(..., 'exp', ...)：第三个参数若含
input()、$_GET或字符串拼接，90%存在漏洞 -
order( 和 group(：如
order(input('sort') . ' DESC')，字段名无法参数化，必须白名单校验 -
where(字符串) 或 where(闭包)：例如
where("id = " . input('id'))或闭包里调用whereRaw()、whereExists() -
数组方式传where条件但键名动态：如
where([input('k') => input('v')])，键名未校验即危险
检查input()的使用上下文
很多漏洞不是出在input()本身，而是它后续怎么被用：
- 搜
input(后紧跟where(、order(、group(、Db::raw(，看有没有跳过类型转换（如没加/d或/s）就直接拼入SQL - 特别注意分页排序、搜索高亮、动态统计这类功能——它们天然需要用户控制字段或表达式，是重灾区
- input('id')不等于安全；input('id/d')才强制转整型，input('name/s')只是字符串类型转换，不防注入
验证器和filter不是万能解药
别依赖validate规则或input()的第三个过滤参数来兜底：
- validate的
alphaNum拦不住onerror=alert(1)，regex规则若没严格限定字符集，仍可能放过恶意内容 - input('x', '', 'htmlspecialchars')只适合输出到HTML，如果之后又做
urldecode()或二次拼接，过滤就失效了 - 真正可靠的做法是在控制器里按用途明确处理：进SQL用
input('id/d')或绑定，输出到页面用htmlspecialchars()
快速定位业务模块
优先审查以下高频风险模块，节省审计时间：
- 后台管理中的列表页：常带自定义排序（
order()）、搜索条件（where()数组键名动态）、统计分组（group()） - API接口中支持“动态字段查询”的功能，例如
fields=name,email然后拼进field()或where() - 搜索高亮逻辑：常通过
highlight字段构造CONCAT()或REPLACE()表达式，易用Db::raw()引入用户输入 - 导出Excel功能：若按用户选择字段生成
field(['a','b',input('custom')])，字段名未白名单校验即危险
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
