数据库权限如何防注入

本文目录导读：

1. 核心原则：遵循最小权限原则
2. 限制特定危险操作
3. 从数据库连接层面加固
4. 数据库配置层面的加固
5. 对比不同数据库的特有权限
6. 防御思路优先级

数据库权限防注入的核心思路是最小权限原则和分层防御，即使SQL注入漏洞存在,攻击者也无法利用有限的数据库权限读取或破坏敏感数据。

以下是从数据库权限层面进行防御的具体措施：

核心原则：遵循最小权限原则

这是最根本、最重要的一条，应用程序连接数据库所使用的账户，其权限应该只限于它能用到的、最少的、刚够用的权限。

• 避免使用高权限账户：

  • 不要用 root、sa（SQL Server）、SYSTEM（Oracle）等超级管理员账户连接应用程序。
  • 攻击者一旦通过注入控制了高权限账户,可以执行任何操作。

• 具体权限配置（以MySQL为例）：

  • 只读账户（Report / Read-Only）： 仅授予 SELECT 权限，用于生成报表、数据展示等。
  • 读写账户（常规 CRUD）： 授予 SELECT, INSERT, UPDATE, DELETE。绝对不要授予 DROP, ALTER, CREATE, INDEX, GRANT 等DDL（数据定义语言）权限。
  • 管理账户（DBA）： 仅在数据库服务器本地维护时使用。

  -- 错误示例：授予了不应该的全局权限
  GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%';
  -- 正确示例：仅授予特定数据库的必要权限
  GRANT SELECT, INSERT, UPDATE, DELETE ON my_database.* TO 'app_user'@'web_server_ip';
  -- 或者对于仅查询用户
  GRANT SELECT ON my_database.* TO 'readonly_user'@'web_server_ip';

限制特定危险操作

除了基本权限,还需要对特定高危操作进行限制：

• 限制 FILE 权限： 该权限允许使用 LOAD_FILE() 读取服务器上的任何文件（如 /etc/passwd）或 INTO OUTFILE 写入Webshell。应用程序账户绝对不应拥有此权限。
• 限制 EXECUTE 权限： 如果数据库有存储过程（Stored Procedure），特别是xp_cmdshell（SQL Server）或UTL_FILE（Oracle），需要严格限制执行权限，仅在极少数必要情况，并为特定存储过程授权,而非全局。
• 限制 GRANT 权限： 应用程序账户不能拥有授权给其他用户的权限,防止攻击者通过注入为自己创建后门账户。

从数据库连接层面加固

• 使用连接白名单：
  • 在数据库服务器上配置防火墙或访问控制列表，只允许应用服务器的IP地址连接到数据库。
  • 拒绝来自公网IP或未知来源的连接。
• 存储过程与函数： 使用存储过程封装SQL逻辑，只授予用户执行存储过程的权限，而不授予底层表的直接查询权限，这样，应用只能通过已定义的接口操作数据,无法直接执行任意SQL。
• 视图（View）： 如果应用需要访问多表或限制某些字段，可以创建视图，然后只授予用户 SELECT 视图的权限,而不是底层表。

数据库配置层面的加固

• 禁止或限制动态SQL： 在存储过程中尽量避免拼接SQL字符串,使用参数化查询。
• 禁用危险特性：
  • SQL Server： 禁用或删除 xp_cmdshell（sp_configure 'xp_cmdshell', 0; RECONFIGURE;）。
  • MySQL： 设置 local-infile=0 禁用 LOAD DATA LOCAL INFILE。
• 审计日志（Audit Logging）： 开启数据库审计日志，记录所有失败的登录、DDL操作、以及敏感表的DML操作，这虽然不能防止注入,但能及时发现和追溯。

对比不同数据库的特有权限

防御思路优先级

1. 最基础（代码层）： 使用参数化查询（Prepared Statement），这是阻止SQL注入的根本，权限控制是第二道防线。
2. 最重要（权限层）： 最小权限原则，应用账户只拥有“增删改查”的权限,绝无DDL或文件操作权限。
3. 最有力（网络层）： IP白名单,只允许特定IP连接数据库。
4. 最兜底（配置层）： 禁用危险功能,开启审计日志。

数据库权限防注入无法阻止注入发生（这是应用代码的责任），但可以极大限制漏洞被利用后造成的破坏范围，即使发生了 ' OR 1=1 -- 这样的注入，如果用户只有 SELECT 权限，攻击者最多只能查询数据，无法删除表、无法写入后门文件、无法执行系统命令。