权限隔离是SQL注入第一道防线，需为应用账号配置最小权限（精确到列）、禁用高危操作、使用存储过程+DEFINER机制，并确保权限实时生效且无隐式覆盖。
SQL注入防护不能只靠预处理，权限隔离才是第一道防线
MySQL 中仅用 PREPARE + EXECUTE 或 ORM 的参数化查询，并不能完全规避风险。攻击者一旦拿到一个具备 SELECT 权限的账号，仍可能通过报错、延时、布尔盲注等方式探测结构；若该账号还能执行 INSERT 或 UPDATE，甚至可写入恶意 payload 触发二次利用。真正有效的防护，是让每个应用账号只拥有「刚好够用」的最小权限，并与业务逻辑强绑定。
如何为 Web 应用创建最小权限账号（含 SQL 注入缓解效果）
权限粒度必须精确到库、表、列，且禁用高危操作。例如一个用户登录模块，只需查 users 表的 username 和 password_hash 字段，其他一概不给：
CREATE USER 'web_login'@'10.20.30.%' IDENTIFIED BY 'strong_pwd_2024'; GRANT SELECT (username, password_hash) ON myapp.users TO 'web_login'@'10.20.30.%'; REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, EXECUTE, FILE, PROCESS, SUPER ON *.* FROM 'web_login'@'10.20.30.%'; FLUSH PRIVILEGES;
-
SELECT权限限定在具体字段，避免SELECT *泄露敏感列（如is_admin、api_token） - 显式
REVOKE所有高危权限，尤其FILE（可读写服务器文件）、PROCESS（可查看其他会话 SQL）、SUPER（可绕过大多数限制） - 主机白名单用子网（如
'10.20.30.%'）而非'%'，防止账号被横向复用 - 避免使用
GRANT ... WITH GRANT OPTION，防止权限扩散
为什么存储过程 + DEFINER 权限能降低注入危害
把核心查询逻辑封装进存储过程中，并用低权限账号调用，可天然阻断大部分注入路径。关键点在于：调用者无需表级权限，只依赖存储过程自身的 DEFINER 权限上下文执行。
Shoping购物网源码
下载
该系统采用多层模式开发，这个网站主要展示女装的经营，更易于网站的扩展和后期的维护，同时也根据常用的SQL注入手段做出相应的防御以提高网站的安全性，本网站实现了购物车,产品订单管理，产品展示，等等，后台实现了动态权限的管理，客户管理，订单管理以及商品管理等等，前台页面设计精致，后台便于操作等。实现了无限子类的添加，实现了动态权限的管理，支持一下一个人做的辛苦
DELIMITER $$ CREATE DEFINER = 'dba_secure'@'localhost' PROCEDURE sp_get_user_by_name(IN p_name VARCHAR(64)) READS SQL DATA SQL SECURITY DEFINER BEGIN SELECT id, username, role FROM users WHERE username = p_name; END$$ DELIMITER ; GRANT EXECUTE ON PROCEDURE myapp.sp_get_user_by_name TO 'web_login'@'10.20.30.%';
-
SQL SECURITY DEFINER表示以DEFINER账号权限运行，调用者不需要SELECT权限 - 即使攻击者构造
p_name = "admin' OR '1'='1"，也只能影响WHERE子句中的等值判断——因为参数已作为字符串字面量传入，不会改变语句结构 - 但注意：若过程内拼接了动态 SQL（如
CONCAT('SELECT ... WHERE name = ''', p_name, '''')），依然会中招
权限管理失效的典型场景与排查方式
很多团队配了权限却仍被攻破，问题往往出在权限未实时生效或存在隐式覆盖：
- 忘记执行
FLUSH PRIVILEGES—— 特别是在直接修改mysql.user表后，权限缓存不会自动刷新 - 同一用户存在多个 Host 匹配项（如
'user'@'10.20.30.5'和'user'@'%'），MySQL 按 host 排序取最具体的规则，容易误判实际生效权限 - 使用
root或mysql.sys账号连接应用，等于把整个数据库钥匙挂在代码里 - 权限检查绕过：某些中间件（如 ProxySQL）或连接池（如 HikariCP）配置了 auto-commit=false + 多语句支持（
allowMultiQueries=true），可能让SELECT 1; DROP TABLE users;这类多语句注入得逞
验证当前连接实际权限，直接查 SHOW GRANTS FOR CURRENT_USER();，别信配置文件或文档里的“应该”。权限不是写完就安全，而是每次连接都得重新校验上下文。
