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 连接配置：
coding-agent
下载
一款AI开发辅助工具，主要用于通过后台进程将编码任务委托给 Codex、Claude Code 或 Pi 智能体。适用场景：（1）构建或创建新功能/应用，（2）审查 PR，适合需要提升相关任务效率的用户。
- 检查
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、最后在定时任务里批量触发——每个环节都得有独立校验，不能指望某一层兜底。
