大型电商系统搜索栏如何防御多阶段SQL注入攻击

先说几个核心判断

在大型电商系统的搜索栏，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、最后在定时任务里批量触发——每个环节都得有独立校验，不能指望某一层兜底。