SQL注入数据库角色权限审计

SQL注入攻击可以直接绕过登录验证，直接获取数据库管理员权限。攻击者通过构造恶意SQL语句，就能执行任意数据库操作，包括创建用户、修改权限、删除数据等。最危险的是，攻击者可以利用系统存储过程如xp_cmdshell直接获取服务器系统权限。

一、SQL注入如何直接威胁数据库角色权限

当应用程序未对用户输入进行严格过滤时，攻击者可以在输入框中插入SQL代码片段。例如，一个简单的登录验证漏洞：

SELECT * FROM users WHERE username = 'admin' AND password = '123456'

攻击者输入用户名：admin'--，SQL语句变为：

SELECT * FROM users WHERE username = 'admin'--' AND password = '123456'

“--”后面的语句被注释掉，攻击者无需密码即可登录管理员账户。但这只是开始，真正的威胁在于权限提升。

二、利用UNION查询直接读取系统权限表

通过UNION查询，攻击者可以读取数据库中的系统表，获取所有用户和角色信息。以MySQL为例：

SELECT id, name FROM products WHERE id = 1 UNION SELECT user, host FROM mysql.user

这条语句会返回产品信息的同时，直接暴露MySQL的所有用户账户。如果数据库用户具有读取mysql.user表的权限，攻击者就能获得完整的用户列表，包括密码哈希值。

三、直接执行权限修改语句

如果数据库连接账户权限过高，攻击者可以直接添加管理员账户。SQL Server中：

EXEC sp_addlogin 'hacker', 'password123'
EXEC sp_addsrvrolemember 'hacker', 'sysadmin'

这两条语句创建一个新登录账户“hacker”，并将其加入sysadmin角色，获得最高权限。在MySQL中：

GRANT ALL PRIVILEGES ON *.* TO 'attacker'@'%' IDENTIFIED BY 'pwd' WITH GRANT OPTION

这条语句创建一个可以从任何主机访问的超级用户。

四、通过系统存储过程获取服务器控制权

SQL Server的xp_cmdshell扩展存储过程允许执行操作系统命令。如果数据库服务以高权限运行，攻击者可以：

EXEC xp_cmdshell 'net user backdoor Password123! /add'
EXEC xp_cmdshell 'net localgroup administrators backdoor /add'

这两条命令直接在Windows服务器上创建管理员账户。在PostgreSQL中，如果安装了不受限的语言扩展：

CREATE OR REPLACE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6', 'system' LANGUAGE C STRICT;
SELECT system('whoami > /tmp/test');

这允许执行任意系统命令。

五、数据库角色权限审计的四个关键步骤

1. 识别所有数据库账户及其权限。使用数据库内置命令：

-- SQL Server
SELECT name, type_desc, is_disabled FROM sys.server_principals
-- MySQL
SELECT user, host, authentication_string FROM mysql.user

2. 检查角色成员关系。特别关注sysadmin、db_owner、root等特权角色：

-- SQL Server
SELECT member.name AS Member, role.name AS Role 
FROM sys.server_role_members 
JOIN sys.server_principals AS member ON member.principal_id = member_principal_id
JOIN sys.server_principals AS role ON role.principal_id = role_principal_id

3. 审计应用程序使用的数据库账户权限。确保应用程序账户只有最小必要权限，绝不能使用sa或root账户。

4. 检查存储过程和扩展功能权限。禁用危险的系统存储过程：

EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'xp_cmdshell', 0
RECONFIGURE

六、防止SQL注入权限提升的七条实战规则

1. 应用程序必须使用参数化查询或预编译语句，永远不要拼接SQL字符串。例如在Java中使用PreparedStatement：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, username);
stmt.setString(2, password);

2. 为每个应用程序创建专用数据库账户，遵循最小权限原则。只授予特定数据库的读写权限，而不是整个实例。

3. 定期审计数据库角色和权限分配，移除不必要的特权账户。建立自动化审计脚本，每周运行一次。

4. 禁用或删除危险的系统存储过程和扩展功能。特别是xp_cmdshell、sp_OACreate等可以执行系统命令的功能。

5. 对数据库错误信息进行封装，避免泄露数据库结构。生产环境应返回通用错误信息，而不是详细的SQL错误。

6. 对所有数据库连接进行加密，防止中间人攻击获取凭据。使用TLS/SSL加密数据库连接字符串。

7. 实施Web应用防火墙(WAF)规则，拦截常见的SQL注入攻击模式。但WAF只是第二道防线，不能替代安全的代码。

七、自动化权限审计脚本示例

以下是一个SQL Server权限审计脚本，可定期运行以监控权限变化：

-- 检查所有登录账户及其权限
SELECT 
    login.name AS LoginName,
    login.type_desc AS LoginType,
    perm.permission_name AS Permission,
    perm.state_desc AS PermissionState,
    obj.name AS ObjectName
FROM sys.server_principals login
LEFT JOIN sys.server_permissions perm ON perm.grantee_principal_id = login.principal_id
LEFT JOIN sys.objects obj ON obj.object_id = perm.major_id
WHERE login.type IN ('S', 'U', 'G') -- SQL用户、Windows用户、Windows组
ORDER BY login.name, perm.permission_name;

-- 检查数据库级别权限
SELECT 
    user.name AS UserName,
    role.name AS RoleName,
    perm.permission_name AS Permission
FROM sys.database_principals user
LEFT JOIN sys.database_role_members rm ON rm.member_principal_id = user.principal_id
LEFT JOIN sys.database_principals role ON role.principal_id = rm.role_principal_id
LEFT JOIN sys.database_permissions perm ON perm.grantee_principal_id = user.principal_id
WHERE user.type IN ('S', 'U', 'G')
ORDER BY user.name;

八、深度防御：三层权限隔离架构

真正的安全需要架构层面的设计。建议采用三层权限隔离：

第一层：Web应用账户。只能通过存储过程访问数据，不能直接访问表。权限仅限于执行特定的存储过程。

第二层：业务逻辑账户。用于后台任务和数据维护，具有有限的表操作权限，但不能访问系统表。

第三层：管理账户。只有DBA可以使用，需要多重认证。所有管理操作都需要审计日志。

这种架构确保即使发生SQL注入，攻击者也只能获得最低权限账户的控制权，无法直接威胁整个数据库系统。

九、应急响应：发现权限异常后的处理流程

1. 立即隔离受影响的系统，阻止进一步的数据库访问。

2. 审查数据库日志，确定攻击时间和使用的注入点。

3. 检查所有账户的最近修改记录，特别关注权限变更：

-- SQL Server 2008及以上版本
SELECT 
    target_name,
    action_id,
    session_id,
    database_name,
    object_name,
    statement
FROM sys.fn_get_audit_file('C:\Audit\*.sqlaudit', DEFAULT, DEFAULT)
WHERE action_id IN ('AU', 'AL') -- 授权和取消授权操作
ORDER BY event_time DESC;

4. 重置所有数据库账户密码，特别是特权账户。

5. 修复应用程序中的SQL注入漏洞，重新部署代码。

6. 恢复数据后，进行全面安全测试，确认漏洞已修复。

SQL注入对数据库角色权限的威胁是真实且严重的，但通过严格的权限管理、代码安全实践和定期审计，可以构建有效的防御体系。关键是将数据库权限视为最重要的安全资产之一，实施最小权限原则，并持续监控权限变更。安全不是一次性的配置，而是需要持续维护的过程。

SQL注入数据库角色权限审计

服务指南

帮助中心