服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 去年做代码安全审计，SpotBugs 报了一个 SQL_INJECTION 告警，定位过去一看： <select id="listOrders" resultType="Order"> SELECT * FROM orders WHERE status = #{status} ORDER BY ${sortColumn} ${sortOrder} </select> 开发同事很委屈："WHERE 条件我全部用的 #{} 预编译啊，注入不了！"我问他：如果 sortColumn 传入 (CASE WHEN (SELECT 1=1) THEN id ELSE status END)，这条 SQL 会发生什么？他愣住了。 测试一下：请求带上 sortColumn=(CASE WHEN (substr(database(),1,1)='p') THEN id ELSE create_time END)，接口返回的排序结果不一样——攻击者可以通过排序结果的变化，一个字符一个字符把数据库名、表名、数据全部拖走。这就是经典的 ORDER BY 注入，也是绝大多数 My....

前两天群里有人发了个截图，他们公司一个后台管理系统被人拖了库。查了半天，问题出在一段 MyBatis 的动态排序代码上。那哥们特别委屈："我没拼字符串啊，我用的是 MyBatis，框架不是自带防注入吗？" 我一看代码，${orderBy} 赫然在目。他以为 MyBatis 是银弹，实际上 $ 和 # 差了一个安全分水岭。 今天聊的这个话题，但凡写过 Java Web 项目的人都会遇到。但很多人对 SQL 注入的认知停留在"用了 MyBatis 就安全了"，这个想法比注入本身还危险。 一句话搞懂：# 和 $ 到底差在哪 先别急着看方案，把这个最基础的概念弄明白。 MyBatis 里写 SQL，有两种方式塞参数： -- 方式一：#{} SELECT * FROM user WHERE name = #{name} -- 方式二：${} SELECT * FROM user WHERE name = '${name}' 区别在哪？#{} 走预编译，${} 是字符串拼接。 用 #{} 的时候，MyBatis 会把 SQL 发给数据库之前，先把参数位置用 ? 占位，参数值单独传给数据库。数....