SQL注入直接威胁DBA权限控制体系,因其使攻击者能以应用账号身份执行任意SQL;若该账号权限过高(如db_owner),等同于将数据库管理权交予攻击者,而SQL Server仅依据登录名和执行上下文判定合法性,无法区分正常语句与恶意拼接。

SQL注入为何直接威胁DBA的权限控制体系
因为SQL注入不是应用层的“别人的问题”——一旦攻击者通过Web接口拿到数据库连接凭据,就能以该账号身份执行任意语句。而DBA若未限制应用账号权限,app_user可能拥有db_owner角色,等于把钥匙连同锁匠工具一起交给了陌生人。
更关键的是:SQL Server不会区分“这是ORM生成的语句”还是“这是黑客拼出来的恶意查询”,它只认登录名和执行上下文。所以SELECT * FROM sys.dm_exec_sessions看到的全是合法登录、合法会话,但里面混着EXEC sp_executesql N'SELECT * FROM users WHERE id = 1; DROP TABLE orders;'这种组合拳。
如何用Extended Events捕获高权限账号的可疑SQL执行
不能依赖sys.fn_get_audit_file或默认跟踪——它们要么缺失参数值,要么早已停用。必须主动部署轻量级Extended Events会话,聚焦三类行为:
- 执行含危险关键字的批处理:
UNION SELECT、XP_CMDSHELL、WAITFOR DELAY、sp_configure - 调用动态执行函数:
sp_executesql、EXEC(@sql)(注意捕获sql_text字段内容) - 访问敏感元数据:
sys.server_principals、sys.database_permissions、sys.certificates
示例创建语句(仅监控app_admin账号):
CREATE EVENT SESSION [Capture_High_Risk_SQL] ON SERVER
ADD EVENT sqlserver.sql_batch_completed(
WHERE ([username] = N'app_admin')
AND ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text], N'%UNION%SELECT%') = 1
OR [sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text], N'%XP_%') = 1))
ADD TARGET package0.event_file(SET filename=N'C:\XEvents\HighRiskSQL.xel');
审计日志里哪些字段最容易被忽略但最关键
很多人只看event_name和sql_text,却漏掉三个决定性字段:
-
session_id:单次会话中连续执行多条语句时,仅靠sql_text无法还原攻击链,必须用session_id串联 -
client_hostname和client_app_name:识别是否来自预期应用服务器,还是陌生IP+sqlcmd.exe或Microsoft SQL Server Management Studio -
is_system:为1表示系统内部调用(如统计信息更新),为0才代表用户发起——过滤掉它,才能避免噪音淹没真实攻击
特别注意:sql_text在Extended Events中可能被截断,务必检查sqlserver.sql_text事件的max_length配置,默认是128字符,远不够捕获完整payload。
为什么定期比实时更重要——DBA要盯住“静默提权”窗口期
真正的风险不在第一次OR 1=1,而在攻击者拿到低权限后,用几天时间反复试探:SELECT IS_SRVROLEMEMBER('sysadmin') → SELECT * FROM sys.server_role_members → EXEC master..xp_cmdshell 'whoami'。这些操作不报错、不阻断、不触发告警,但每一步都在扩大控制面。
所以DBA必须每周导出sys.dm_exec_query_stats中由高权限账号执行的、execution_count > 50且last_execution_time集中在非业务时段的语句,人工比对是否出现新面孔——比如某应用账号突然开始查sys.certificates,这几乎100%意味着正在准备证书提权。











