怎样在大型电商系统的搜索栏防御多阶段SQL注入攻击

MyBatis-Plus中防SQL注入需三重设防：1. 查询构造用LambdaQueryWrapper或白名单校验动态字段；2. 参数绑定优先用eq/like等内置方法，禁用字符串拼接和${}；3. 上下文隔离——apply()须用{0}占位符，LIKE模糊查询禁用手动拼%且启用ESCAPE，JDBC连接显式配置allowMultiQueries=false。

直接拼接搜索关键词的 SQL 就是高危入口，哪怕加了简单过滤也扛不住多阶段注入——比如先绕过前端校验，再利用后端日志回显触发二次注入，最后用时间盲注提取敏感字段。必须从查询构造、参数绑定、上下文隔离三处同时设防。

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