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%意味着正在准备证书提权。
