ash查不到sql注入语句的直接痕迹，因其仅记录sql_id、执行计划哈希值、等待事件等元信息，不存完整sql_text；可疑注入需通过异常行为模式识别，如同一sql_id短时间内高并发、多用户id执行、执行计划频繁变更等。
ASH里查不到SQL注入语句的直接痕迹
ASH（V$ACTIVE_SESSION_HISTORY）本身不记录SQL文本全貌，只存sql_id、sql_plan_hash_value、等待事件、绑定变量类型等元信息。攻击者构造的恶意SQL（比如admin' OR '1'='1）一旦被解析执行，就和合法查询一样走硬解析/软解析流程，最终只留下一个sql_id。你不会在sql_text列看到原始payload——那字段压根不存在于该视图。
真正能间接暴露异常的，是行为模式：
- 同一
sql_id在极短时间内出现大量不同user_id的执行（比如非业务账号高频调用） - 频繁触发
cursor: pin S wait on X或library cache lock——说明SQL文本变异快、硬解析多 - 大量会话卡在
SQL*Net message from client后立刻切到db file sequential read，且sql_id对应执行计划不稳定（plan_hash_value频繁变）
怎么定位疑似注入的sql_id
关键不是搜“单引号”或“OR 1=1”，而是找违反业务规律的SQL行为。以下查询可快速筛出可疑目标：
SELECT sql_id, COUNT(*) execs, COUNT(DISTINCT user_id) users,
MIN(sample_time) first_seen, MAX(sample_time) last_seen
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/24 -- 近1小时
AND event NOT IN ('SQL*Net message from client', 'rdbms ipc message')
GROUP BY sql_id
HAVING COUNT(DISTINCT user_id) > 5 AND COUNT(*) > 20
ORDER BY execs DESC;
说明：
-
COUNT(DISTINCT user_id) > 5：排除前台应用固定账号（如APP_USER）的正常查询 -
COUNT(*) > 20：过滤低频噪声 - 去掉
SQL*Net message from client这类空闲等待，聚焦真实执行
拿到可疑sql_id后，再查v$sql确认其sql_text是否含动态拼接特征（如多个WHERE条件用||拼接、大量TO_CHAR转换数字为字符串）。
为什么不能直接用username过滤ASH数据
V$ACTIVE_SESSION_HISTORY视图里没有username字段，只有user_id。如果你写WHERE username = 'ATTACKER'，Oracle会报错或静默返回空——因为该列根本不存在。常见错误操作：
- 误以为
dba_users的username能直连ASH视图（必须JOIN，且user_id可能为NULL） - 在
ASH_REPORT_HTML函数里传username参数（官方函数不支持，会被忽略） - 依赖AWR报告里的“Top Users”页签判断——那是汇总统计，无法追溯单条注入语句的会话路径
正确做法：先查SELECT user_id FROM dba_users WHERE username = 'SCOTT'，再用该user_id去过滤v$active_session_history，但要注意user_id会被复用，需结合sample_time范围锁定。
结合AWR看注入行为的时间分布
ASH是秒级采样，适合抓瞬时异常；AWR快照则能暴露趋势。如果发现某sql_id在多个连续AWR快照中都出现在“SQL ordered by Executions”榜首，且其Buffer Gets/Exec值波动剧烈（比如从100跳到10000），大概率是注入点被反复试探。
检查命令：
SELECT snap_id, begin_interval_time, executions_delta, buffer_gets_delta,
(buffer_gets_delta / NULLIF(executions_delta,0)) avg_buffer_gets
FROM dba_hist_sqlstat s
JOIN dba_hist_snapshot sn USING (snap_id, instance_number)
WHERE sql_id = 'abc123xyz'
AND begin_interval_time > SYSDATE - 1
ORDER BY snap_id;
重点看avg_buffer_gets是否随executions_delta非线性增长——这往往意味着查询条件未走索引，全表扫描被滥用，典型注入特征。
真正难的是把sql_id和原始HTTP请求关联起来。ASH不存client_info或module以外的应用上下文，除非你在应用层主动设置DBMS_APPLICATION_INFO.SET_MODULE，否则只能靠时间戳对齐Web日志与数据库采样点。
