如何防御SQL注入攻击_严格控制应用连接池账号权限-SQL-PHP中文网

仅靠参数化查询不足以防止横向越权，因高权限账号可绕过sql拼接路径执行敏感操作；必须遵循最小权限原则，按模块、表、操作粒度显式授权，并严控连接池配置中的权限陷阱。

如何防御sql注入攻击_严格控制应用连接池账号权限

为什么只靠参数化查询还不够

参数化查询能拦住大部分拼接 SQL 的漏洞，但挡不住权限过大带来的横向越权。比如应用用 root 账号连数据库，即使所有查询都用了 PreparedStatement，攻击者一旦通过其他漏洞（如反序列化、XXE）拿到应用执行上下文，就能直接调用 SELECT * FROM mysql.user 或写入 INTO OUTFILE —— 这些不走业务 SQL 拼接路径。

连接池账号必须遵循最小权限原则

应用连接池配置的数据库账号，只应拥有当前模块必需的表级读写权限，且禁止授予 GRANT OPTION、FILE、PROCESS、SUPER 等高危权限。

Web 前端服务账号：仅允许对 users、orders 表执行 SELECT、INSERT、UPDATE（不含 DELETE）
后台任务账号：若只需清理过期日志，只授 DELETE ON logs.* WHERE created_at 类似能力（通过存储过程封装，而非开放 DELETE 权限）
绝对禁止在生产环境使用 CREATE USER、DROP TABLE、SHOW DATABASES 权限

MySQL 中如何安全创建连接池账号

别用 GRANT ALL PRIVILEGES ON *.* TO 'app' —— 这等于把锁孔交出去还附送万能钥匙。应该按库、按表、按操作粒度显式授权。

CREATE USER 'app_rw'@'10.20.%.%' IDENTIFIED BY 'strong-pass-2024';
GRANT SELECT, INSERT, UPDATE ON myapp.users TO 'app_rw'@'10.20.%.%';
GRANT SELECT, INSERT ON myapp.orders TO 'app_rw'@'10.20.%.%';
FLUSH PRIVILEGES;

注意：IP 段限制（如 '10.20.%.%'）比 '%' 更安全；密码必须启用强策略；账号名避免含 admin、root 等暗示高权的词。

连接池配置里容易被忽略的权限陷阱

很多团队改了数据库账号权限，却忘了连接池本身可能开启危险特性。比如 HikariCP 的 connection-init-sql、Druid 的 initConnectionSqls，如果配了 SET sql_mode='' 或 SET autocommit=1 之外的语句，可能绕过权限限制触发执行。