先说几个核心判断
在大型电商系统的搜索栏，SQL注入从来不是单点问题。直接拼接搜索关键词的接口，哪怕加了看似严密的过滤，也扛不住多阶段攻击——比如先绕过前端校验，再利用后端日志回显触发二次注入，最后通过时间盲注提取敏感字段。这种攻击链路的核心在于：攻击者把搜索栏当跳板，先探库结构、再埋持久化payload、最后在定时任务里批量触发。这就要求我们的防御必须从查询构造、参数绑定、上下文隔离三个维度同时设防，不能指望任何单一层面兜底。
MyBatis-Plus 的 QueryWrapper 不等于自动免疫
很多人误以为用了 QueryWrapper 就万事大吉，但漏洞往往出在“动态条件拼接”的细节里：
- 错误写法：
queryWrapper.like("name", "%" + keyword + "%")——keyword仍参与字符串拼接，' OR SLEEP(5)--会原样进入SQL执行 - 正确做法：用
queryWrapper.like("name", keyword)，让 MyBatis-Plus 内部走预编译；若需前后模糊匹配，改用queryWrapper.apply("name LIKE CONCAT('%', ?, '%')", keyword)，确保?占位符被JDBC驱动识别为参数 - 特别要注意
apply()中的SQL片段必须是固定结构，绝不能混入用户输入，否则又退回到拼接风险
搜索接口必须禁用堆叠查询与多语句执行
MySQL默认允许 ; 分隔多条语句，而攻击者在搜索框输入 iphone'; DROP TABLE products-- 可能直接删表——这和是否用 MyBatis 无关，关键在于JDBC连接配置：
- 检查
jdbc:mysql://URL 是否包含allowMultiQueries=false（默认为false，但显式声明更稳妥） - Spring Boot 的
application.yml中确认：spring.datasource.hikari.data-source-properties: allowMultiQueries=false - PostgreSQL 用户需要确认
pgjdbc版本 ≥ 42.2.24，旧版本存在allowEncodingChanges绕过漏洞
对 LIKE 模糊搜索做上下文感知转义
LIKE 是少数允许通配符参与参数化却仍需额外处理的场景。JDBC 的 PreparedStatement 不会自动转义 % 和 _，它们在参数值中仍具通配语义：
- 如果业务允许用户搜“以 iphone 开头”，应限制为
name LIKE ? ESCAPE ''，然后对keyword中的%、_、做预处理 - 更安全的做法是统一走全文检索（Elasticsearch / MySQL 5.6+ 的
FULLTEXT），把模糊逻辑交给专用引擎，避免在 SQL 层暴露LIKE接口 - 绝对不要用
replaceAll("%", "%")这类粗暴替换——攻击者可输ip%hone绕过，必须用正则或StringEscapeUtils.escapeSql()（Apache Commons Text 1.10+）
日志与错误响应必须剥离原始 SQL
多阶段注入最危险的一环在于“二次注入”：恶意输入先存入数据库（如商品标题 admin'--），后续后台导出报表时再拼接查询，触发执行。防御的关键不是拦住输入，而是切断回显链路：
- 所有日志记录禁止打印完整 SQL，可用
logger.debug("search executed for user {}, keyword length: {}", userId, keyword.length()) - HTTP 错误响应体禁用数据库错误详情（如
MySQLSyntaxErrorException堆栈），Spring Boot 中设置server.error.include-message=never - 监控告警需捕获
SQLException中的 SQL 状态码（如 MySQL 的45000自定义错误、HY000通用错误），而非依赖错误消息文本
真正难防的不是单次 ' OR 1=1，而是攻击者把搜索栏当跳板，先探库结构、再埋持久化 payload、最后在定时任务里批量触发——每个环节都得有独立校验，不能指望某一层兜底。
