mysql中对数据库执行SQL注入防护与权限设置

sql注入防护需应用层参数化查询与数据库侧配置协同：启用STRICT_TRANS_TABLES等sql_mode、限制secure_file_priv、禁用LOCAL INFILE、最小权限授权、启用audit_log审计、强制TLS加密及密码策略。

sql注入防护：别只靠预处理，还得看连接层配置

mysql本身不直接“拦截”SQL注入，防护核心在应用层使用参数化查询，但数据库侧配置能堵住不少旁路攻击。比如攻击者绕过应用直连数据库执行恶意语句时，sql_mode 和 secure_file_priv 就是第一道防线。

• sql_mode 建议启用 STRICT_TRANS_TABLES 和 NO_AUTO_CREATE_USER，避免隐式类型转换导致的条件绕过（如 '1' = 1 被宽松解析成真）
• secure_file_priv 必须设为非空目录（如 /var/lib/mysql-files/），否则攻击者可能用 LOAD DATA INFILE 或 select ... INTO OUTFILE 读写任意文件
• 禁用 LOCAL INFILE：启动 mysqld 时加 --local-infile=0，或运行时执行 SET GLOBAL local_infile = OFF（需 SUPER 权限）

最小权限原则：给应用账号只配 SELECT/INSERT 等具体 DML 权限

别让 Web 应用账号拥有 GRANT OPTION、DROP、CREATE 或对 mysql 系统库的访问权——这些不是业务必需，却是提权关键。

• 建专用账号，按模块分库授权：CREATE USER 'app_report'@'10.20.%' IDENTIFIED BY 'strong-pass-2024';
• 只授必要表的权限：GRANT SELECT, INSERT ON finance_db.invoice TO 'app_report'@'10.20.%';
• 显式拒绝高危操作：REVOKE FILE, PROCESS, SUPER ON *.* FROM 'app_report'@'10.20.%';（注意：REVOKE 不会报错即使权限原本未授予）
• 避免用 GRANT ... ON *.* —— 即使是测试环境，也容易漏掉新库的权限收敛

敏感操作审计：靠 general_log 不现实，改用 audit_log 插件

general_log 会严重拖慢性能且日志无结构，生产环境必须关；真正可用的是 MySQL Enterprise Audit 插件（社区版不可用），或 Percona Server / mariadb 的等效替代方案。

• Percona Server 可启用 audit_log：安装后设置 audit_log_policy = ALL，它会记录所有语句及客户端 IP、用户、时间戳
• 重点过滤含 union SELECT、CONCAT(、char(、LOAD_FILE( 的日志行——这些是手工注入常见特征
• 日志路径需独立挂载且仅 root 可读：audit_log_file = /var/log/mysql/audit.log，配合 logrotate 限制大小

INSTALL PLUGIN audit_log SONAME 'audit_log.so'; SET GLOBAL audit_log_policy = 'LOGINS,QUERIES'; SET GLOBAL audit_log_exclude_accounts = 'monitor_user@%';

密码与连接加固：TLS 不是可选项，而是 SQL 注入后果扩大的放大器

没开 TLS 时，明文传输的账号密码 + 注入后的数据回传，等于把钥匙和保险箱一起快递给攻击者。而弱密码 + 允许远程任意 IP 登录，会让注入得手后横向移动毫无阻力。

• 强制 TLS：创建用户时指定 require X509 或至少 REQUIRE ssl，并验证 SHOW VARIABLES LIKE 'have_ssl'; 返回 YES
• 限制登录来源：CREATE USER 'api_app'@'172.16.5.12' IDENTIFIED BY '...';，禁用 '%' 通配主机（除非用跳板机代理）
• 密码策略：启用 validate_password 插件，设 validate_password.Length = 12、validate_password.mixed_case_count = 2
• 定期轮换凭据：用 ALTER USER 'app_rw'@'10.20.%' IDENTIFIED BY 'new-secret-2024Q3';，旧密码立即失效

实际中最容易被忽略的是：应用连接池复用账号时，权限变更不会自动生效，必须重启连接池或等待连接超时重建；而 audit_log 默认不记录空密码登录或认证失败事件——这两处恰好是暴力破解+注入组合攻击的盲区。