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 注入防护从来不是二选一的选择题。一个没配好权限的完美参数化查询，就像给金库装了指纹锁却忘了关大门；而一个高权限账号配上一堆过滤函数，等于在雷区里穿拖鞋走路。最危险的疏忽，往往发生在“以为某一层足够牢靠”的那一刻。
