MySQL权限配置是SQL注入的最后一道闸门，即使代码层失守，严格权限也能限制攻击者查、删、导能力；业务账号仅授CRUD权限，禁用DROP/ALTER/CREATE/FILE/EXECUTE，限制登录IP，定期审计账号，并配合strict模式、secure_file_priv等服务端配置及错误信息管控。
MySQL权限配置是SQL注入的最后一道闸门
即使代码层完全失守（比如误用了字符串拼接），严格的权限配置也能让攻击者“查不到、删不了、导不出”。它不防注入发生，但能大幅压缩注入成功后的危害范围。
- 业务账号只授予
SELECT、INSERT、UPDATE、DELETE，禁用DROP、ALTER、CREATE、FILE、EXECUTE—— 这些权限一旦开放，报错注入或UNION SELECT LOAD_FILE()就可能直接读取服务器文件 - 限制登录主机，例如创建账号时用
'app_user'@'192.168.10.%'而非'app_user'@'%'，防止攻击者从任意IP连入尝试提权 - 定期运行
SELECT user, host, account_locked FROM mysql.user;检查是否存在长期未用或权限过宽的账号
为什么预处理语句不能替代权限控制？
因为预处理语句只解决“参数被当代码执行”的问题，但对“动态表名”“动态列名”“ORDER BY 字段”等场景完全无效 —— 这些地方必须靠白名单校验+权限兜底。
- 比如分表查询：
"SELECT * FROM log_202512 WHERE uid = ?"中的log_202512是用户传入的月份，无法用?占位，只能靠正则匹配^log_\d{6}$+ 数据库账号无权访问其他表 - 再如排序字段：
ORDER BY ?在绝大多数驱动中不被支持（会报错），必须用白名单限定为['created_at', 'score', 'name']，否则攻击者可填入id; DROP TABLE users; - 如果账号还拥有
FILE权限，即便用了PreparedStatement，攻击者仍可通过报错注入触发SELECT ... INTO OUTFILE写入 Webshell
my.cnf 里这几个配置项直接影响注入后果
服务端配置不是“锦上添花”，而是决定攻击者能否拿到错误信息、读写文件、甚至绕过路径限制的关键开关。
-
sql_mode = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION：开启严格模式后，非法数据（如超长字符串）会报错而非静默截断，减少因数据异常导致的逻辑绕过 -
secure_file_priv = /var/lib/mysql-files/：强制所有LOAD DATA INFILE和SELECT ... INTO OUTFILE只能在该目录下操作，哪怕注入成功也无法写到 Web 目录 -
skip_symbolic_links = ON：禁止符号链接，防止攻击者用../etc/passwd类路径绕过secure_file_priv限制
错误信息屏蔽不是“藏起来就安全了”
前端显示“系统繁忙”只是表象；真正要防的是数据库把结构、版本、路径等敏感信息吐进日志，又被攻击者通过日志路径猜测或 SSRF 泄露出去。
- PHP 中关掉
display_errors = Off，同时确保log_errors = On，让错误进日志而非页面 - MySQL 错误日志里若出现
Unknown column 'xxx' in 'field list'，说明攻击者正在探测字段名 —— 这类日志需接入 SIEM 实时告警 - 不要依赖应用层 try-catch 吞掉所有异常，尤其避免在 catch 块里拼接原始 SQL 或堆栈返回给前端
权限配置和 SQL 注入防护从来不是二选一的选择题。一个没配好权限的完美参数化查询，就像给金库装了指纹锁却忘了关大门；而一个高权限账号配上一堆过滤函数，等于在雷区里穿拖鞋走路。最危险的疏忽，往往发生在“以为某一层足够牢靠”的那一刻。
