应用安全审计：扫描器之外还要检查什么

一个假设的例子。一家金融科技公司正在接受一家大型企业客户的供应商审查，问卷中有一个问题：“是否进行过应用安全审计？”团队手里有一份几十页的自动化扫描报告，其中没有任何一项严重发现。团队很容易想回答“是”，但仅凭扫描报告，还不能证明已经完成了符合客户所要求范围的审计。

但实际上，扫描器从未以两种不同角色登录客户门户；从未尝试通过替换API请求中的标识符去打开另一位客户的付款指令；没有检查能否跳过审批步骤来确认一笔操作；也没有阅读配置，没有查看代码是如何构造数据库查询的。如果有一天客户问的不是“有没有做过审计”，而是“到底检查了什么”，回答就会很尴尬。

这个情形是虚构的，但“有报告”与“防护经过检验”之间的差距却随处可见。应用安全审计的范围比任何单一工具都要广。它是一项结构化、经过约定的检查，用来确认防护机制是否真正能够抵御现实的风险：涵盖架构、代码、配置、API和业务逻辑。

审计需要支撑哪项决策

发现漏洞，还是验证合规

NIST SP 800-115把技术测试描述为规划和实施测试、分析结果并制定缓解措施的过程。文件同时指出，这类工作可以服务于两个目的：发现漏洞，或者验证是否符合政策及其他要求。

这种双重性决定了范围。以在发布前找出可被利用的弱点为目标的审计，与检查是否符合内部政策或客户要求的审计相比，需要的深度和工期都不同。因此，向审计委托方提出的第一个问题是：审计需要支撑哪项决策？是一次发布、供应商验收、修复计划，还是提交给监管机构和客户的材料？

对于经常需要回答客户问卷的SaaS公司来说，这个问题尤其重要；如何针对这种情形安排测试，我们在关于SaaS公司渗透测试的文章中做过分析。

书面范围与授权

范围需要以书面形式确定，并附有系统所有者的明确授权。文件中列出环境、账户和角色、API和第三方组件、测试时间窗口、联系人，以及有权叫停工作的人。还要单独说明是否可以访问源代码和文档：这决定了审计是“白盒”检查，还是外部检查。

如果您还没有确定自己的应用需要什么样的范围，可以在渗透测试范围准备页面上与 Pentest.red 团队一起梳理：在任何工作开始之前，在那里记录系统、角色、访问权限和预期结果。

本文中的任何内容都不意味着可以在没有系统所有者书面授权的情况下检查系统。

为什么扫描报告不等于审计

扫描器擅长什么

自动化工具能够快速遍历大量页面和请求，发现已知的错误模式、过时的组件、缺失的响应头和典型的注入问题。这既有用又便宜，而且很容易嵌入开发流水线。没有人建议放弃扫描器。

扫描器的盲区在哪里

扫描器并不知道您的应用意味着什么。它不明白，当两个请求在语法上都正确时，A公司的用户不应该看到B公司的发票；它不知道在核验文件之前不能批准申请；它很少能同时使用多个角色进行测试，也看不到负责做出访问决策的代码。授权错误和业务逻辑错误往往代价最高，而它们恰恰位于扫描器的盲区之中。

还有一个更实际的问题：覆盖范围。如果扫描器无法通过身份认证，或者在遍历中途丢失了会话，它就只会认真检查登录页面和几个公开栏目。这样一份报告里没有严重发现，说明的是检查得很少，而不是保护得很好。因此，对于任何自动化报告，首先要问的是：它实际访问了哪些栏目和端点，使用的是哪些账户。

审计并不是扫描器的对立面：它把自动化检查作为工具之一，同时补充了自动化无法提供的内容，也就是对系统的理解和人工验证。

架构：审计从哪里开始

信任边界与数据流

审计从理解应用的构造开始。用户在哪里进行身份认证？访问决策在哪里做出？哪些服务彼此信任而不再重复检查？数据流向哪里？每一个数据跨越信任边界的位置——从浏览器到API、从网关到内部服务、从应用到外部支付服务商——都需要一组专门的检查。

在分布式系统中，架构阶段尤其重要：错误往往不在某一个服务里，而在于“请求到达我们之前已经被检查过了”这一假设。如何在这类系统中规划测试，请参阅我们的微服务渗透测试指南。

文档与现实

架构图、API规范和角色说明是有用的起点，但审计人员要检查它们是否与现实一致。例如：文档中没有、却仍然响应请求的端点；书面上是“只读”、实际上却可以修改记录的角色；架构图上显示外部无法访问、实际上却接受来自互联网请求的服务。文档与现实之间的差异，是常见的发现来源。

代码与配置

基于风险的代码审查

如果可以访问源代码，逐行通读通常既无必要，也不现实。基于风险的审查更有效：审计人员从威胁地图出发，追踪到做出决策的位置。权限是如何检查的？数据库查询和操作系统调用是如何构造的？上传的文件如何处理？令牌如何签发和校验？密钥存放在哪里？

命令注入就是一个典型例子。OWASP ASVS中有一条要求明确规定，操作系统调用必须使用参数化查询或与上下文相适应的命令行输出编码。从外部可以发现某一个存在漏洞的位置，但只有查看代码，才能看出这在代码库中是不是一种系统性的写法。

配置、密钥与依赖

许多漏洞并不存在于代码中，而存在于设置中：生产环境开启了调试模式、错误信息过于详细、服务账户权限过大、密钥存放在过多人员都能看到的环境变量中、使用了带有已知漏洞的过时库。审计会在约定的范围内检查应用和环境的配置，并记录哪些组件可以查看、哪些不能。

对于第三方组件，重要的是不要夸大结论。审计可以说明正在使用的库版本存在已知漏洞，以及该漏洞代码能否从应用中被触达；但它并不检验这个库本身或供应商整个云服务的安全性。报告中应当体现这一区别：“组件已过时”“已确认存在可利用路径”和“未对该组件进行分析”是三种不同的表述。

HTTP与浏览器策略

Web应用的大部分防护是通过HTTP的行为来实现的。HTTP是一种无状态协议，状态由Cookie添加。因此，审计人员会查看会话如何通过Set-Cookie建立、带有哪些属性，身份认证如何实现，以及重定向、缓存和跨域交互是否会泄露数据。

由浏览器执行的策略是另一个独立领域。内容安全策略（CSP）控制页面可以加载哪些资源，有助于发现和缓解跨站脚本和数据注入。CORS规定网站如何响应跨域请求。权限策略（Permissions Policy）和跨源资源策略（CORP）限制浏览器功能和跨域加载。这些策略中的错误会悄无声息地削弱代码所依赖的防护。像HTTP Observatory这样的工具便于对获得授权的目标进行快速、非侵入式的检查，但响应头的规范只是辅助措施，不能替代对访问控制和业务逻辑的检查。

API与授权

对象、属性、功能

现代应用首先是API，而API中最严重的错误通常与授权有关。2023版OWASP API安全Top 10区分了三种不同的失效。对象级授权失效：用户通过替换标识符读取或修改他人的对象。属性级授权失效：API返回或允许修改用户不应看到或修改的字段。功能级授权失效：用户调用了为其他角色设计的操作。

对象级检查可能通过了，而功能级检查却完全缺失。因此，审计会分别检查这三个层面，使用多个角色和多个测试租户，并记录覆盖了哪些端点和方法。

API契约与实际行为

API规范是一种承诺。审计人员要检查API在承诺之外的行为：请求中带有多余字段、数据类型出乎意料、有人忘记下线的旧版本端点，以及批量请求。

同一份清单中有两项风险值得特别关注，因为扫描器几乎从来无法正确评估它们。第一项是无限制的资源消耗：对请求的频率、大小和成本没有任何限制。第二项是对敏感业务流程的无限制访问：注册、预订或发送验证码等在技术上完全正常的场景，可以被自动化到损害业务的规模。这两项风险都处于API与业务逻辑的交界处，需要理解什么才是应用的正常行为。

关于REST接口测试方法的详细介绍，请参阅我们关于REST API安全评估的文章。

业务逻辑与人工验证

自动化无能为力的地方

业务逻辑是您这个应用特有的运行规则。折扣不能使用两次。上传文件之前不能批准申请。超过限额的转账需要二次确认。退款金额不能超过已支付金额。违反这些规则，在扫描器看来并不像“错误”：每一个单独的请求都是正确的，问题出在顺序、数值或角色上。

人工验证是什么样子

审计人员研究应用的业务流程，写下必须始终成立的不变条件，并在约定的范围内尝试打破它们。能否跳过某个步骤？能否重复执行？能否同时执行两个相互冲突的操作？能否代入负值？能否以不应具备该权限的角色执行操作？每一次这样的尝试都要记录下来，即使没有产生发现：这本身就是覆盖范围的证据。

人工验证需要时间，因此应当集中在出错代价最高的地方：资金、个人数据、访问权限和不可逆操作。一份好的审计计划会明确说明哪些流程经过了人工验证、哪些只做了自动化检查，以及为什么这样选择。如何采购这类工作，我们在关于业务逻辑安全测试的文章中做了分析。

以标准作为方法框架

什么重要、检查什么、如何测试

各项开放标准覆盖审计的不同层面，彼此之间可以很好地互补。2025版OWASP Top 10是一份提高意识的文件，反映了业界对Web应用最关键风险的共识。它适合用于界定任务和与管理层沟通，但它是一份风险清单，而不是一套可验证的要求。

OWASP ASVS 5.0.0更接近审计的基线：它为测试技术安全控制提供了基础，目标是让市场上安全验证的覆盖范围和严格程度趋于一致。ASVS建议在引用要求时同时注明版本。例如，v5.0.0-1.2.5表示5.0.0版本中“编码与净化”一章里“注入防护”一节的第五条要求。如果不注明版本，随着编号变化，引用会逐渐失去意义。OWASP WSTG的稳定版本为4.2，5.0版本正在开发中，它规定了具体的测试流程。SP 800-115描述了规划、执行和执行后活动，其中包括分析发现、提出缓解建议和形成报告。

把它们结合起来是这样运作的：Top 10和CWE回答“什么重要”，ASVS回答“检查什么”，WSTG和SP 800-115回答“如何测试”，而治理框架回答“如何处理结果”。

1. 决策与范围明确审计支撑的决策，并记录环境、角色、API以及代码访问权限。
2. 要求选择一组带版本号、与应用风险和审计目标相匹配的ASVS要求。
3. 检查结合架构分析、代码审查、配置审查、API测试和业务逻辑的人工验证。
4. 确认复现每一项发现，剔除误报，并对应到CWE类别和ASVS要求。
5. 报告与复测在业务背景下评估风险，指定负责人，并对修复进行复测。

以弱点类别代替任务清单

CWE Top 25排名列出了最危险、最常见的软件弱点。MITRE还发布了一份依据CISA已知被利用漏洞（KEV）目录列出的被积极利用弱点清单，以及一份“差一点”进入Top 25的弱点清单。对审计人员来说，这表明了哪些根本原因会反复出现并吸引攻击者。

对应到CWE会改变关于修复的讨论方式。团队不再只是修复一个存在漏洞的参数，而是会问：代码中是否存在系统性的写法？CWE指出，从根本原因入手有助于消除整类缺陷，例如与注入或内存安全相关的缺陷。CISA“设计即安全”项目关于从类别层面消除跨站脚本、操作系统命令注入和目录遍历的警示，也指向同一方向。按类别归组发现的报告，为工程管理层提供的是一张路线图，而不仅仅是一份任务清单。

报告验收与复测

“没有发现”意味着什么

报告中的每一项发现都应当记录被检查的要求、观察到的证据、复现步骤、受影响的资产、在业务背景下的风险评级以及置信程度。但报告如何说明“没有发现”同样重要。如果没有说明检查了哪些要求、使用了哪些方法、以哪些角色进行、在多长时间内完成，那么“未发现漏洞”就毫无意义。

审计不是认证证书，也不能证明不存在任何漏洞。如果范围或时间限制了检查，报告必须直接说明。诚实列出未检查的内容，是工作质量高的标志，而不是弱点。

按照同样的要求复测

只有在按照同一版本的同样ASVS要求、使用同样的方法、并在可能的情况下使用同样的测试数据进行复测之后，修复才算得到确认。复测不仅要检查具体的那个位置，还要检查整个类别：如果修复了一处注入，相邻模块中是否还存在同样的写法？如何组织一次真正能够证明问题已被消除的复测，我们在关于渗透测试修复验证的文章中做了说明。

风险管理中的审计

负责人与期限

只有当发现进入一个受管理的流程时，审计才能带来价值。NIST网络安全框架2.0帮助组织理解网络风险并改进风险管理，它提供了配置文件以及指向NIST各类资源的参考信息。如果把审计结果放进与CSF保持一致的配置文件中，就更容易随时间比较当前状态与目标状态。

一项发现的优先级不仅取决于技术评级，还取决于业务背景。同样的授权错误，出现在只有三名员工使用的管理后台中，与出现在支付服务的公开API中，是两种不同的风险。好的报告会解释为什么给某项发现定为这样的优先级，以便风险负责人可以认同或提出异议。

在操作层面，这意味着为每一类弱点指定负责人和期限，对修复进行复测，并把反复出现的类别反馈到架构评审和开发人员培训中。这里最常见的错误是错配：把扫描报告当作对确定性要求很高的决策依据，或者一次昂贵的人工审计结束后，修复工作却没有负责人。

如果您是采购方而不是开发方

CISA“设计即安全”的立场增加了问责这一维度：技术供应商应当在管理层面对安全负责，产品应当在不额外收费的情况下提供多因素认证、日志功能和单点登录。对于产品团队来说，关于缺少日志或身份认证薄弱的发现是设计问题，而不仅仅是一个缺陷。对于采购方，CISA的“按需安全”指南有助于在采购过程中提出这些问题。向供应商索取其承诺是有益的，但承诺只是一种声明，而不是审计结果。

让我们回到假设例子中的那份问卷。对客户问题的好回答，不是“是的，做过审计”，而是一段简短的描述：审计支撑了哪项决策，检查了哪些要求和领域，使用了哪些方法，发现了什么，哪些问题已经修复并经复测确认，哪些内容不在范围之内。如果您希望事先弄清楚哪种测试形式适合自己的应用、您的决策需要什么样的结果，可以在准备渗透测试范围时与我们一起完成。我们的整体工作形式可在渗透测试服务中查看。