Web应用漏洞检测：范围、方法与经得起检验的证据

设想一个假想的B2B工单服务。它有Web界面、供集成使用的公开REST API、CSV报表导出、每晚为管理者汇总数据的后台任务，以及部署在部分接口前面的缓存。它的客户是彼此独立的公司，每家公司都在自己的租户中工作。在一次将引入新角色“组织管理员”的重大版本发布之前，技术负责人要求对应用“做一次漏洞检查”。扫描器爬取了页面，返回十几条关于响应头的提示。然而最重要的问题依然没有答案：一家公司的用户能否通过导出功能拿到另一家公司的报表？普通员工能否看到本应只给管理员的字段？会话切换之后，缓存会不会返回别人的数据？

这个例子是虚构的，但它暴露的落差在任务的提出方式上相当典型。Web应用漏洞检测是一项经过授权的结构化工作：找出攻击者可能利用的弱点，确认这些弱点到底有多重要，并把结果转化为通过复测的修复。下面为负责产品、研发或安全的人员梳理一套实用顺序：范围应包含什么，如何测试角色与信任边界，扫描器在哪里有用、在哪里无能为力，以及如何验收结果。

Web应用检测实际涵盖什么

一次评估覆盖的远不止用户能看到的页面。OWASP应用安全验证标准（ASVS）将自身定位为验证应用技术安全控制的基础，同时也涵盖应用所依赖的环境中的控制措施。在实践中，讨论范围时应包括代码与业务逻辑、身份认证与会话管理、API、HTTP层面的配置，以及应用所依赖的支撑组件。

发出第一个请求之前的资产清点

测试从一份清单开始，而不是从扫描器开始。团队需要记录域名和环境、Web界面以及使用同一后端的移动客户端、公开和内部API、导出与导入机制、后台任务、队列、Webhook、缓存和CDN、第三方集成以及管理后台。还值得单独记下：其中哪些部分会处理不同客户的数据，哪些角色会访问它们。没有这样一份清单，评估只会检查显眼的部分，而漏掉重要的部分。

下表有助于在每条边界进入计划之前，就它作出决定。

授权与工作边界

只能测试自己拥有的系统，或系统所有者已给予明确书面许可的系统。一份好的计划应列明纳入范围的应用、环境和接口，角色与测试账号，明确的排除项，测试时间窗口和紧急联系人。计划还要规定数据处理规则：是否可以在生产环境中工作，哪些操作不允许，以及发现真实个人数据时应如何处理。验收标准也值得提前写下来，下文会专门讨论。

角色、认证状态与信任边界

许多对业务重要的问题，并不出现在登录页面上，而是出现在登录之后。因此，评估不应只覆盖一个账号，而应覆盖一张矩阵：匿名访客、普通用户、拥有扩展权限的用户、租户管理员、客服运营角色；如果产品是多租户的，还至少需要两个相互独立的租户。对每个角色而言，状态同样重要：刚登录的用户、修改密码后的用户、被降级后的用户、退出登录后的用户，以及会话过期后的用户。

信任边界是数据或控制权从可信度较低的一方传递到可信度较高的一方的位置：从浏览器到服务器，从合作伙伴集成到API，从用户输入到后台任务，从单个租户到共享存储。每一条这样的边界都会变成一个测试问题：接收方是否校验了收到的内容，还是依赖于此前已经做过校验的假设？

认证不等于授权

认证回答“你是谁”，授权回答“你可以对这个具体的对象、字段或功能做什么”。成功登录对第二个问题什么也说明不了。一个危险的假设是：只要用户已经登录，界面又只显示属于他的按钮，访问就已经受到限制。服务器必须在每一次请求中依据身份、角色和对象归属作出访问决定，而不是依据客户端没有渲染某个链接这一事实。

超出可见API的租户隔离

在SaaS产品中，租户隔离本身就是一个需要单独验证的对象。仅仅确认读取记录的接口在收到他人标识符时返回错误是不够的。同样的数据还可能通过以下途径流出：租户筛选被单独实现的导出功能；以系统权限生成报表的后台任务；搜索或自动补全提示；缓存键未考虑用户或租户的缓存。在我们的假想服务中，导出功能和每晚汇总恰恰是隔离逻辑可能被重新实现的地方，因此值得在两个租户下单独检查。

API授权的三个问题：对象、属性、功能

OWASP API安全Top 10 2023区分了几个在实践中容易混淆的类别。把它们分开看是有益的，因为每个类别都需要各自的测试和各自的修复。下文的排列顺序并不代表普遍程度或重要程度。

对象级与属性级

对象级授权回答的是：这个用户能否操作这条具体记录，例如一张工单、一张发票或一个文件。检查方法是在一个角色和一个租户下，访问属于另一个用户或租户的对象，并确认服务器拒绝请求，且对所有方法都拒绝：读取、修改、删除和导出。

属性级授权是一个更细致的问题：即使允许访问该对象，它的每个字段是否都可以读取和修改？API响应可能返回界面根本没有显示的内部字段，修改请求也可能接受用户不应更改的字段，例如角色、支付状态、所属组织。测试要把角色应当看到和修改的内容，与服务器实际返回和接受的内容进行对比。

功能级

功能级授权关注的是操作而不是数据：这个角色究竟能否调用这个功能？管理接口、批量操作、用户管理、套餐变更都需要在每个角色下检查，包括那些在界面上没有对应菜单的角色。在假想服务中，新角色“组织管理员”需要双向检查：它是否获得了所需的功能，以及它是否没有获得客服运营人员的功能。

资源消耗与敏感业务流程

OWASP API安全Top 10 2023中的另外两个类别容易混淆，尽管它们讲的是不同的事情。不受限制的资源消耗，是指API没有限制请求的数量、频率或成本：分页大小、导出条目数量、重量级筛选条件、对付费外部服务的调用。不受限制地访问敏感业务流程，是指一个合法功能可以被自动化地、以损害业务的规模使用：批量注册、批量抢购、滥发邀请、猜测优惠码。前者是资源和成本问题，后者是业务流程被滥用的问题，二者的测试方法和防护措施都不同。若想深入了解如何针对API开展此类评估，可参阅关于REST API安全评估的文章。

扫描器无法判断的业务逻辑

业务逻辑是让产品成为产品的那套规则：谁可以审批工单，何时扣款，一份邀请可以使用几次，下单步骤按什么顺序进行。这些规则并没有写在协议里，工具也不知道正确的行为应该是什么。因此，这里的弱点要靠理解功能用途、并有意检查“走错路会发生什么”的人来发现。

流程步骤、限额与状态转换

需要检查的实际问题是这样的：能否跳过某个步骤，或者以不同顺序执行步骤？本应只执行一次的操作能否重复执行？在并发请求下限额是否依然有效？如果请求在意料之外的时刻到达，对象从一个状态转换到另一个状态时会发生什么？服务器重新计算的数值，是否与客户端发送的数值一致？每个这样的问题都源自产品说明，因此测试人员需要文档、测试数据，以及能够说明何为正确行为的联系人。关于如何界定此类工作的范围并选择服务商，可参阅关于业务逻辑安全测试的文章。

HTTP控制、会话与浏览器策略

HTTP层是一个很好的起点：检查它风险低，又能很快看出应用的配置有多细致。但它只是起点，而不是结论。

会话状态是应用层的设计决策

HTTP作为协议本身并不把请求彼此关联起来：每个请求都携带处理它所需的全部信息。状态由应用添加，最常见的方式是通过保存会话标识符的Cookie，会话数据则由服务器存储；也可以通过令牌实现。基于HTTP的普通服务器端会话是标准做法。因此，要测试的不是协议，而是应用如何创建、绑定、刷新和结束会话：登录后标识符是否更换，退出登录和修改密码时会话是否失效，会话有效期是否受限，Cookie是否设置了Secure、HttpOnly属性和合适的SameSite值，角色被降级后旧令牌是否仍然有效。

响应头是佐证，而非证明

现代浏览器提供了多种需要应用正确配置的机制。内容安全策略（CSP）规定页面可以加载哪些资源，有助于缓解XSS和数据注入。CORS控制站点如何响应跨站请求，过于宽松的策略再加上携带凭据的请求，可能把响应暴露给外部来源。跨源资源策略（CORP）保护资源免受某些跨站加载，权限策略则限制页面代码可以使用的浏览器功能。错误处理同样值得检查：响应是否一致，是否泄露了过多信息。即便如此，某个响应头存在并不能证明系统安全。严格的CSP修复不了授权缺陷，正确的CORS也保护不了一个不校验租户的导出功能。

扫描的广度、人工测试的深度与后果确认

NIST的安全测试技术指南SP 800-115把漏洞扫描、渗透测试和安全评估视为相关但彼此不同的活动，并强调每种技术都有优点和局限。对Web应用来说，这一区分具有直接的实践意义。

每种方法能证明什么、不能证明什么

自动化扫描提供广度：它可以快速、可重复地覆盖大量页面、参数和版本，发现已知的配置问题和常见类别的输入处理错误。它适合在交付流程中频繁执行。它的局限在于业务意图：扫描器不知道用户A是否应该看到用户B的工单，也不理解审批步骤不能被跳过。扫描结果需要人工研判，否则报告会被误报填满。

人工测试提供深度：专业人员会逐一走查角色和租户，检查对象级、属性级和功能级授权，以及业务流程、后台任务和导出功能。它速度更慢，并且高度依赖技能水平，因此覆盖范围必须事先规划，而不能想当然。

确认现实后果回答的是第三个问题：在约定的边界内，已发现的弱点能否串联成对业务有意义的结果，例如读取另一个租户的数据？这是某一时间点的快照，而且此类工作只能在授权范围内进行，影响尽可能小，绝不超出范围。

在一次评估中组合使用

合理的顺序是：扫描负责广度并清除明显问题，人工工作深入角色、信任边界和业务逻辑，后果确认则用于业务需要看到某个发现真实影响的地方。在假想服务中，扫描器有助于检查响应头和组件的已知问题，而关于导出、每晚汇总和缓存的问题，则需要在两个租户下进行人工检查。任何一种方法都不能取代另一种：它们回答的是不同的问题。

标准的分工：Top 10、ASVS与WSTG

对标准的混淆很容易导致范围模糊。每份文件都有自己的任务。

OWASP Top 10是一份关于最关键Web应用风险的意识文件。它为开发人员、管理者和高管提供共同语言，非常适合用于培训。但仅以Top 10为依据的合同或测试计划，不如引用具体需求的文件精确。

以带版本号的ASVS需求作为验收标准

ASVS的设计初衷是统一验证的覆盖范围和严格程度，因此它很适合回答“验证完成”究竟意味着什么。团队挑选适用于自身架构的需求，并为每一项记录结果：通过、未通过或不适用。需求标识符由章、节和需求编号组成，项目方提醒这些编号可能随版本变化。因此需要明确写出版本号：例如，v5.0.0-1.2.5指的是5.0.0版“编码与净化”（Encoding and Sanitization）一章中“注入防护”（Injection Prevention）一节的第五条需求。不带版本号的标识符会随着标准的演进而产生歧义。需求清单以包括CSV和JSON在内的机器可读格式提供，便于导入跟踪系统，并在不同版本发布之间比较结果。

WSTG作为测试指导，CWE作为根因语言

OWASP Web安全测试指南（WSTG）说明如何测试Web应用的各个具体领域：身份认证、授权、会话管理、输入处理和业务逻辑。它是方法论指导，而不是验收标准。MITRE CWE目录有助于在根本原因层面描述发现：如果每个已确认的问题都映射到CWE条目，就能消除一整类缺陷，而不只是修复单个实例。NIST SP 800-115适合用来搭建流程结构，涵盖规划、执行、分析和缓解；而Web专项技术最好参考最新的OWASP资料，因为NIST这份文件发布于2008年。

证据、优先级与复测

测试的价值产生于最后阶段：发现被转化为经复测确认的修复。

一个可用的发现包含什么

开发人员能够据以开展工作的发现应包含：可复现该问题的角色和租户；准确的请求与响应，或界面中的操作步骤；受影响的对象、字段或功能；观察到的结果和预期行为；对应的CWE条目和带版本号的ASVS需求；以及结合该具体产品对后果的评估。未经研判的扫描器原始输出不是发现，而只是有待分析的材料。

如何确定优先级

合理的分级规则基于三项输入：弱点的技术严重程度、该类弱点在现实中被利用的证据，以及对具体资产的影响。MITRE发布了最危险弱点清单，以及与CISA已知被利用漏洞（KEV）目录相关联的弱点清单，这有助于评估第二项输入。这些来源都没有规定统一的公式，因此组织应写下自己的规则并始终如一地执行。对于多租户产品，租户隔离失效通常因其业务影响而值得高度优先处理，即便它在技术上看起来很简单。

复测与关闭

只有当修复以发现问题时相同的方式重新检查过，并且确认相邻路径也已关闭，修复才算得到确认。对于授权缺陷，这意味着在同一角色、同一租户下重复原始请求，然后检查相关方法、导出、后台任务和缓存。关于如何证明修复真正有效，可参阅关于渗透测试修复验证的文章。

1. 确认使用记录下来的角色、租户和请求复现问题
2. 修复在服务器端消除根本原因，而不是隐藏某个界面元素
3. 重复以相同方式、使用相同数据执行原始检查
4. 相邻路径检查相关方法、导出、后台任务和缓存
5. 关闭在跟踪系统中记录证据和剩余风险

如何采购Web应用评估

ASVS统一覆盖范围和严格程度的目标对买方有利：该标准提供了一把共同的尺子，用来比较那些原本用互不兼容的术语描述工作的方案。CISA的《按需安全》（Secure by Demand）指南基于同样的原则：要求供应商提供可验证的证据。它是为产品采购而写的，但同样适用于安全测试服务。

向服务商提出的问题

• 将验证哪个版本的ASVS、哪些需求？每一项的结果如何报告？
• 人工测试将覆盖哪些角色、租户和认证状态？
• API、导出、后台任务和缓存是否纳入范围，而不只是可见界面？
• 哪些WSTG领域由人工覆盖，哪些检查是自动化的？
• 范围、测试账号、排除项和书面授权如何形成文件？
• 每个发现是否都会映射到CWE条目和带版本号的ASVS需求，并附有复现证据？
• 是否包含复测？剩余风险如何记录？
• 工作期间如何保护敏感数据和生产环境的稳定性？

需要警惕的信号包括：报告主要由扫描器输出构成；发现没有根因或需求引用；没有复测；没有明确的授权流程。服务商关于认证资质或过往成果的任何说法，都值得独立核实。

渗透测试结果是什么、不是什么

渗透测试是在约定范围内、某一时间点的安全状况快照。它说明发现并确认了哪些弱点、这些弱点之间如何关联，以及复测后哪些问题已经修复。渗透测试不是认证、证明或鉴证意见，也无法保证不存在漏洞。测试之后对代码、配置和集成的改动会产生新的攻击面，因此值得在交付流程中嵌入轻量级自动化检查，并在重大版本发布前和架构发生重大变化后重复深入的人工评估；具体频率由组织自行决定。如果需要把应用测试与更广泛的计划联系起来，从架构一直到开发流程，可以继续阅读关于应用安全审计的文章。

对于开头提到的假想服务，一次好的评估的成果不会是一份响应头清单，而是对最初那些问题的回答：租户在API、导出、每晚汇总和缓存中是否都得到隔离，新角色的权限是否符合设计意图，以及哪些修复已经通过复测确认。Pentest.red可以协助界定这样的范围并开展经授权的评估；一个方便的起点是描述您的渗透测试范围，包括系统、角色、访问权限和限制条件。