Page 204 - 《软件学报》2026年第7期

毛祥煜 等: 面向 Web 应用漏洞检测的多数据流静态分析方法 2889

当程序执行时, 数据会在变量赋值、函数调用、模块之间传递, 形成数据流动的路径, 即数据流. 数据流描述
程序中数据的流动与变换过程, 其伴随着控制流而发生. 图 1 所示的两条控制流路径上分别包含对应的数据流传
播过程, 二者最终交汇于 x = call(c) 语句, 表明变量 c 可能来自用户输入变量 a 或字符串常量 b.
1.2 Web 应用安全与污点分析技术
Web 应用 (Web application) 是基于 Web 技术开发的应用程序, 其核心逻辑运行于服务器端, 通过 HTTP/HTTPS
协议与客户端代理交互, 动态处理请求并生成响应. Web 应用安全旨在保护此类应用免受恶意攻击和漏洞利用, 其
焦点集中于应用层风险, 典型例子如 OWASP Top 10 漏洞类型. Web 应用安全通常以接口为分析基本单位——每
个接口在代码层面对应一个入口函数 (entry point), 即负责接收客户端 HTTP 请求并返回响应的函数或方法, 作为
Web 程序的实际执行入口. 此外, 相较于内存安全而言, Web 应用安全更关注应用层语义, 如重点分析变量是否可
能被恶意输入污染, 而无须精确追踪其具体取值.
污点分析 (taint analysis) 是一种程序分析技术, 其核心思想是将特定的数据源标记为“污点源”, 并监控这些数据
在程序中的流动, 当未经安全处理的污染数据流入敏感逻辑时, 报告潜在安全漏洞. 早在由 Liskov [20] 提出的 CLU 语
言中, “数据污染”概念便已经出现, 其用于验证程序的类型安全性和数据完整性. 污点分析技术首次被明确用于安全
领域, 则可追溯到 Perl 语言中引入的“Taint mode”安全检查机制 [21] . 图 2 展示了静态污点分析算法的基本工作流程.
P 和漏洞规则 Rule 作为输入, 规则中配置有污点源模式集合 Source、污点汇模式集
算法以待分析的程序中间表示
合 Sink 和净化函数集合 Sanitizer 等安全相关方法 (security-relevant method, SRM) 信息. 算法包含 3 个主要步骤:
(1) 基于规则中预设的污点源模式, 匹配程序中指定类型的输入参数, 将其标记为污染变量; (2) 执行数据流分析, 追
踪污点数据随程序代码执行的传播与净化过程; (3) 当检测到未被净化的污染数据流入敏感操作时, 报告潜在漏洞.

程序中间表示
污点源匹配 污点传播追踪 敏感操作检测
安全漏洞

规则配置
图 2 传统污点分析流程

然而, Web 应用程序的逻辑复杂性和独特交互模式, 使得传统污点分析算法在 Web 安全领域面临双重挑战.
(1) 缺少跨控制流的异步追踪能力. Web 应用程序多采用请求-响应架构, 依赖会话保持与异步 I/O 机制, 导致
恶意载荷可通过 HTTP 会话、数据库持久化、线程共享数据等中间介质跨执行过程传播. 传统污点分析基于单次
程序控制流轨迹, 难以追踪此类隐式数据流. 例如图 3(a) 展示的存储型 XSS 漏洞中, 攻击载荷进入数据库存储 (第
3 行) 的请求与内容渲染请求 (第 10 行) 分属于不同控制流, 且二者间无显式调用关系, 传统方法因忽略跨 HTTP
事务的数据依赖而产生漏报.
(2) 细粒度语义表征能力不足. Web 应用的输入空间具有显著异构性, 涵盖结构化数据 (HTTP 请求参数、JSON/
XML 请求体)、非结构化数据 (文件内容) 及隐式输入来源 (Cookie/Session 变量) 等. 而现有方法采用粗粒度污染
标记策略, 即将不同输入简单划分为同类型污染/非污染变量, 未充分考虑输入语义差异性, 可能导致执行上下文
信息丢失, 影响复杂漏洞检测精确度. 例如图 3(b) 中, 第 7 行的密码重置操作虽然接收用户控制的 password 参数,
但在执行时通过不可伪造 Session 凭证完成身份校验. 传统方法忽视该语义关联性, 将产生越权漏洞误报.
近年来, Web 静态应用安全测试技术的相关研究工作多聚焦于改进污点分析算法的具体实现 [3−9] , 而在底层
检测原理上均遵循传统污点分析算法框架, 故在分析图 3 所示程序代码逻辑时, 仍然无法避免其局限性; 部分工作
采用启发式建模策略 [10−12] 处理异步执行过程间的数据依赖关系, 但方案适用范围较窄, 缺乏普遍性; 对于多源输
入语义差异特性, 同样少有研究者进行关注. 因此, 亟需一种通用的污点分析算法增强方案, 以扩展现有 Web 应用
静态分析技术的能力与适用场景.