数据库管理员怎么降低SQL注入危害_遵循最小权限原则配置账号-SQL-PHP中文网

最小权限能拦住大部分sql注入，是因为注入只能以应用账号身份执行sql；若该账号仅被授予特定表、字段的有限权限（如select），攻击者便无法跨表查询、读取系统视图或执行高危操作，实际危害大幅受限。

数据库管理员怎么降低sql注入危害_遵循最小权限原则配置账号

只要数据库账号不配成 root 或 sa，绝大多数 SQL 注入攻击连表名都查不到，更别说拖库。

SQL 注入本身不等于“拿到数据库所有权限”。它只是让攻击者借你的应用账号执行任意 SQL。如果这个账号只能查 users 表的 name 和 email 字段，那即使用 UNION SELECT 也只能源源不断吐出这两列——其他表、字段、系统视图、存储过程统统不可见。

真实案例中，90% 的 Web 应用被注入后只泄露了部分用户信息，根本原因就是数据库账号早被限制在 SELECT 权限 + 单个业务库 + 少数几张表。

AI Surge Cloud

AI Surge Cloud是一款面向企业数据科学和 ModelOps 的无代码决策智能平台。

下载

别直接 GRANT ALL ON *.* TO 'app'，按实际调用行为收紧：

纯读接口（如商品列表、用户资料页）→ 只授 SELECT，且限定到具体库和表，例如：GRANT SELECT ON myapp.products TO 'web_app'@'%';
登录验证逻辑 → 如果只查 users 表的 username 和 password_hash，就别给整张表权限，用视图封装：CREATE VIEW login_view AS SELECT username, password_hash FROM users;，再授 SELECT 给这个视图
后台导出功能 → 需要 SELECT 多张表？用角色管理，建 export_role，加权限，再把账号 GRANT export_role TO 'report_user'@'%';
绝对禁止 FILE、EXECUTE、PROCESS、SUPER 这类高危权限，哪怕只给测试环境也不行

权限配得再细，踩错这三点照样白搭：

MySQL 5.7+ 默认启用 sql_mode = ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES，但很多旧项目手动关了。一旦关闭，攻击者可用 SELECT 1,2,3 FROM dual 绕过字段数校验，强行 UNION 出敏感系统表 —— 检查 SELECT @@sql_mode;，确保没关严格模式
PostgreSQL 中，public schema 默认可读。即使账号没显式授权，只要没 REVOKE USAGE ON SCHEMA public FROM PUBLIC;，攻击者就能 SELECT table_name FROM information_schema.tables 扫库 —— 必须显式回收默认权限
账号密码硬编码在配置文件里？哪怕权限再小，一旦服务器被拿 shell，攻击者直接读配置连库。必须用密钥管理服务（如 HashiCorp Vault）或运行时注入凭证，禁止明文存盘

最小权限不是一劳永逸的配置项，而是每次上线新功能前都要重审的 checklist：这个接口到底需要哪几个字段？能不能用视图/角色进一步隔离？有没有残留的 GRANT ALL 历史账号？