SQL安全扫描工具通过规则匹配、语法解析和上下文分析识别注入等风险，核心是检测用户输入未经处理的拼接行为，需人工验证与针对性修复。
SQL安全扫描工具不是直接“看”SQL语句，而是通过规则匹配、语法解析和上下文分析，识别出可能引发注入、越权、敏感信息泄露等风险的SQL写法。关键不在于语句是否复杂，而在于是否将用户输入未经处理拼接到SQL中。
识别高危SQL模式：拼接是最大隐患
工具重点检测以下典型危险写法：
- 字符串拼接 + 用户参数：如red">"SELECT * FROM user WHERE id = " + request.getParameter("id")，未使用预编译或转义
- 动态表名/字段名拼接：如"SELECT * FROM " + tableName + " WHERE status=1"，无法用参数化防护
- 内联注释或特殊符号混用：如"id=1 OR 1=1 -- "、"id=1; DROP TABLE user"等明显攻击载荷
- WHERE子句中无类型校验的数字型参数：如"WHERE age = " + inputAge，传入"18 OR 1=1"即可绕过
关注执行环境与上下文：同一SQL在不同位置风险不同
工具会结合代码调用链判断风险等级：
- 从HTTP请求参数、Cookie、Header直接流入SQL，风险极高
- 经由内部服务校验后再使用（如白名单过滤、正则匹配），风险降低甚至可忽略
- 出现在日志记录、调试输出中的SQL片段，虽不执行但可能泄露结构，被标记为信息泄露风险
- 硬编码SQL且无变量插入，通常不报风险，除非含敏感字（如"password"、"ssn"）
验证发现结果：别只信扫描报告
自动扫描会有误报和漏报，需人工交叉验证：
- 检查对应SQL是否真被用户可控输入影响——跟踪参数来源，确认是否经过过滤/类型转换
- 复现疑似漏洞：用' OR '1'='1、1 UNION SELECT 1,2,3等典型payload测试响应
- 查看数据库权限配置：即使存在拼接，若应用账号仅能查单表且无union权限，实际危害有限
- 对比ORM框架行为：MyBatis的${}属于拼接，#{}默认安全；Hibernate的原生SQL需单独审查
修复优先级建议：从执行面切入更有效
不必强求100%消除所有告警，聚焦真正可利用路径：
- 所有Statement.execute() / executeQuery()调用点，必须改用PreparedStatement
- 动态表名/字段名场景，改用白名单校验（如if (!Arrays.asList("user","order").contains(tableName)) throw ...）
- 对已上线系统，可在WAF或网关层加SQL注入规则拦截，作为临时缓解
- 日志中打印SQL时，确保脱敏——隐藏参数值、替换敏感字段名为[REDACTED]
