如何解决SQL中跨库查询的注入风险
先说一个核心判断：跨库查询本身不导致SQL注入，风险源于字符串拼接用户输入；权限限制无法防御注入，必须结合参数化与库/表名白名单校验，并按租户隔离数据库连接。
跨库查询本身不引入注入，拼接才危险
很多人一听到“跨库查询”，就下意识地联想到安全漏洞。其实，像 SELECT * FROM db1.users JOIN db2.orders 这样的语法本身是合法的，数据库执行起来毫无问题。真正的风险源头在哪儿？在于开发时图省事，用字符串拼接的方式，把用户输入的库名、表名直接“塞”进了SQL语句里。这就好比把大门的钥匙交给了陌生人。一旦攻击者控制了拼接的内容，他完全可以把一个普通的 db1，替换成 db1; DROP DATABASE db2; -- 这样的恶意字符串。所以，危险的不是跨库这个动作，而是实现它的方式。
为什么不能靠账号权限“堵住”注入漏洞
那么，给数据库账号严格限制权限，只允许它访问 db1 和 db2，总该安全了吧？这个想法很普遍，但存在误区。权限限制确实能阻止这个账号去删除 db3，但它对SQL注入攻击本身几乎无效。只要注入的语句在账号被允许的库范围内执行成功，攻击目的就已经达成了。不妨看几个典型场景：
- 攻击者输入库名
db1; SELECT * FROM db2.sensitive_data WHERE '1'='1。如果后端不做任何处理，直接使用"SELECT * FROM " + user_input + ".users"进行拼接，数据库很可能会将其当作多条语句执行（这取决于驱动和配置）。 - 即使数据库禁用了多语句执行，攻击者依然可以构造如
db1` UNION SELECT password FROM db2.users --这样的Payload，利用反引号等方式绕过限制，实现数据窃取。 - 权限划分得再细，也拦不住一个合法的
SELECT语句从它已被授权的库中拖走全部数据。因此，把安全完全寄托在权限上，相当于只锁了卧室门，却忘了客厅的窗户还敞开着。
必须用参数化 + 白名单双保险
既然权限靠不住，那该怎么办？答案是组合拳。对于普通的查询条件，使用 #{}（MyBatis） 或 PreparedStatement 进行参数化绑定，这已经是行业共识。但问题在于，在跨库查询的场景下，库名、表名这类标识符本身是无法被参数化的。这时候，就必须引入第二道防线：白名单校验。
- 所有在业务中可能被用到的库名、表名，必须预先定义在代码或配置文件中，例如一个数组：
["db1", "db2", "reporting_db"]。运行时，只判断用户输入是否在这个白名单内，绝不接受任何任意的字符串。 - 如果业务上需要动态选择数据库（比如根据用户类型），这个映射关系应该由后端的业务逻辑来决定，而不是由前端直接传递一个库名过来。
- 在MySQL中，用反引号包裹库名、表名是个好习惯，比如
SELECT * FROM `db1`.users。但这只是为了防止与关键字冲突，它本身并不具备防注入的功能，千万别混淆。 - 在使用DBea ver这类数据库工具时，如果用到
${db_name}这样的变量替换，务必确认工具已启用“安全模式”，或者后端已经做了严格的白名单过滤。否则，${}就等同于在代码里裸奔，风险极高。
最容易被忽略的一点：连接池与用户上下文隔离
前面讲的都是代码层面的防御，但还有一个架构层面的盲点，极易被团队忽略。很多团队认为，配置一个权限最小的只读账号就万事大吉了。然而在生产环境中，为了性能，应用通常会使用数据库连接池。问题来了：不同租户的请求可能会复用同一个物理连接。一旦某个请求因为漏洞导致注入成功，后续的语句就可能复用这个被“污染”的连接上下文，从而实现越权访问其他租户的数据。
这才是关键所在。真正有效的纵深防御，必须包含以下措施：
- 按租户或核心业务域分配独立的数据库账号，每个账号的权限必须精确到库、表，甚至具体的操作类型（SELECT, INSERT等）。
- 连接池需要按账号维度进行隔离。例如，为不同权限的账号创建独立的
DataSource实例，避免连接交叉复用，从根本上切断上下文污染的可能。 - 严格禁止在应用层通过拼接SQL来执行
USE db_name这样的数据库切换命令。这种显式的切换行为，是注入攻击最喜欢劫持的目标之一。
说到底，安全是一个系统工程。解决跨库查询的注入风险，需要从代码编写习惯、防御机制设计，一直考虑到运行时架构，缺一不可。
