SaaS 渗透测试：范围、租户隔离与服务商选择

下面的场景是虚构的，但很常见。一家小型 B2B 采购管理平台即将与一位大客户签约。客户的安全团队发来一份问卷，其中关键的一条是："请附上最近十二个月内的渗透测试结果。"时间紧迫，团队选择了最快的方案——对主域名做一次自动化扫描，并附 PDF 报告。报告里列出几个过时的响应头和一条 TLS 版本警告；问卷填完，合同签了。

几个月后，某个客户的管理员导出季度报表，却在文件里看到了另一家公司的数据行。原来导出后台任务接受请求中的组织 ID，却没有检查发起用户对该组织及所导出对象的权限。这次扫描没有发现这一点：扫描器只有一个租户中的一个账号，导出也不在已执行的检查中。

这只是示例，并非真实事件。但它说明了关键所在：在 SaaS 中，客户、角色和异步流程之间的边界可能存在严重缺陷，因此测试范围必须覆盖这些边界。下文介绍这类测试包含什么、如何处理发现项以及如何选择服务商。

SaaS 渗透测试与普通网站测试有何不同

渗透测试是经授权、有时间限制的评估：专业人员在产品、API 及其环境中寻找漏洞，并以安全方式证明利用后果。NIST SP 800-115 指南将渗透测试与扫描等其他技术评估手段并列，并把其目的描述为发现漏洞和验证是否符合策略与要求。对 SaaS 公司而言两方面都重要：发现并随后修复问题有助于降低风险，而受测试边界限制的结果可为与客户和审计方沟通提供材料。

但渗透测试不是认证、鉴证或审计意见。报告描述的是在特定构建版本、特定环境、特定账号下，在实际执行的检查范围内，哪些得到了证明、哪些没有。找到读取他人数据的方法，证明在所观察的条件下这是可能的；在有限天数内没有严重发现，并不能证明严重问题不存在。

SaaS 的测试对象不是一个网站，而是浏览器应用，公开、合作伙伴和内部 API，登录与单点登录，管理控制台，租户开通，计费，集成，以及代码交付流水线。当客户共用代码和基础设施时，一个授权缺陷就可能同时影响多个客户。正是这种共享的影响范围，要求不同的测试范围。

攻击面：从 HTTP 会话到后台任务

SaaS 产品几乎一切都经由 HTTP。协议本身不在请求之间保存状态，MDN 介绍了 Cookie 如何加入状态。但 HTTP 并不"禁止"会话：应用可以在服务器端保存会话，通过 Cookie 中的标识与请求关联，也可以使用签名令牌。测试人员关心的是：产品如何把独立的请求转化为用户、角色和租户，以及这种关联在哪里断裂。

会话、Cookie 与令牌

测试从会话生命周期开始：创建、刷新、退出和改密时的终止，以及用户被移出组织后的情况。Cookie 属性、令牌吊销以及服务器从哪里获取租户标识需要单独检查。标识通过哪里传递，本身不能决定安全性：用户完全可能合法地在请求头或参数中选择组织。服务器必须把该选择与已验证的身份、当前成员关系，以及对具体操作和对象的权限关联起来；即使租户保存在会话或签名令牌中，也不能省略这些检查。

API 与界面同样值得重视。OWASP API Security Top 10 2023 版区分了三个授权层级：对象级、对象属性级和功能级。用户可能无权打开他人订单，却能通过嵌套对象拿到其字段；也可能看不到管理员按钮，却能直接调用对应方法。不受限制的资源消耗和对敏感业务流程的访问被单独列出，例如批量创建试用租户。详见 REST API 安全评估一文。

浏览器安全头：能防什么，不能防什么

MDN 介绍了几种浏览器端机制。内容安全策略（CSP）有助于发现和缓解部分攻击，包括跨站脚本和数据注入。CORS 决定其他源的脚本能否读取响应，但它不是服务器端授权：根据请求方法、凭据和端点处理方式，即使浏览器不把响应交给脚本，来自其他站点的请求仍可能到达 API 并执行操作。跨源资源策略（CORP）在某些 no-cors 场景下限制响应体的加载，但不阻止请求发送。权限策略控制页面对浏览器功能的访问。

有价值的测试检查的不是响应头是否存在，而是它们是否与产品真实行为相符。对于允许携带 Cookie 的宽泛源列表，应结合受信任源、端点返回的数据以及凭据能否被使用来判断；缺少 CSP 的意义同样取决于页面是否处理不受信任的内容以及是否存在可利用路径。错误响应也值得关注：详细的错误信息有时会暴露内部标识，或暴露某对象在其他租户中存在这一事实。

人员凭据与服务凭据

登录、注册、MFA、SSO、密码重置和邀请是经典范围。但还有服务凭据：客户 API 密钥、集成令牌、Webhook 签名密钥、OAuth 连接、后台任务账号。MFA 保护的是登录时的人，无法说明集成密钥如何限制和吊销。对于实际使用的 SSO 协议，还要分别检查该协议规定的签名与密钥、issuer 与 audience、redirect URI 或 RelayState/state，以及账号与租户绑定和本地会话的创建与终止。如果一个客户的密钥能打开另一个客户的资源，或在集成断开后仍然有效，其严重程度取决于可访问的数据、操作以及受影响的租户数量，界面授权绕过也应按同样方式评估。

租户隔离：SaaS 最核心的边界

SaaS 渗透测试的核心，是验证一个客户的数据和操作对另一个客户不可访问，且客户内部角色按设计分离。直接检查跨租户越权至少需要两个租户；检查租户内部的横向和纵向越权，则需要实际模型中的角色，例如用户、经理和组织管理员。具体组合应以产品的权限矩阵为准。

租户边界不只存在于可见的读取请求中：隔离必须覆盖导出与报表、搜索、缓存、后台任务、队列、Webhook、集成、文件存储和客服工具。对于缓存、队列、文件链接和后台任务，要分别检查租户上下文来自何处，以及它是否进入键值和访问检查。计费还应检查变更套餐与查看发票的权限、Webhook 的租户绑定、签名、重放防护和幂等性；只有在明确授权时才执行真实扣款。导出或搜索形式上"只是读取"，却可能比任何编辑表单泄露更多，因此不应自动视读取为低风险。也并非所有看似读取的请求都无副作用：生成报表可能启动繁重任务或发送通知。

导致跨客户泄露的攻击链常由多个单独看似无害的步骤组成。下面是一个虚构示例。

1. 试用租户攻击者注册一个免费租户，获得具有报表导出权限的合法角色。
2. 替换标识在导出请求中填入其他客户的对象标识；API 只检查用户是否已登录。
3. 后台任务工作进程以服务账号生成文件，未核对对象是否属于发起者所在租户。
4. 文件链接生成的压缩包通过链接交给发起者，其中包含其他组织的数据。

如果扫描只有一个账号且不执行导出，就不会检查这条链：它需要第二个租户、对报表价值的理解以及对异步任务的观察。因此，业务逻辑测试是 SaaS 测试的重要组成部分，并与可自动化检查相互补充。我们在业务逻辑安全测试一文中详细讨论过这类检查。

如何准备测试租户和数据

测试租户的使用必须由对相关资产和环境有授权权力的一方明确许可；租户应专为测试创建，并填充合成或最小化数据。不需要真实数据：要证明泄露，只需在导出中找到第二个测试租户的标记行。请事先约定角色、集成桩服务、是否允许导出和群发邮件，以及测试后如何删除租户。

应纳入哪些租户、角色和集成，可以与 Pentest.red 团队沟通：在渗透测试范围界定页面描述您的租户模型、API 和环境限制——测试的深度和构成取决于这些信息。

哪些标准真正有助于确定测试深度

标准不是用来在商业报价里罗列的，而是让不同服务商用相同语言描述同一项工作，并让复测能与首轮比较。

WSTG 与 ASVS：描述范围的共同语言

OWASP Web 安全测试指南（WSTG）是 Web 应用测试的方法论框架；本文把 4.2 版作为固定示例，具体项目应记录实际选用的版本。服务商应说明执行了哪些 WSTG 测试类别、排除了哪些及原因——例如负载相关检查可能被测试规则排除。

OWASP ASVS 解决另一个问题：其宣称目标是用开放、可商用的标准统一市场上验证覆盖面和严格程度的差异。本文以 5.0.0 版作为固定示例。需求编号随版本变化，因此 ASVS 建议注明版本，例如 v5.0.0-1.2.5 的形式。如果服务商把范围和发现项映射到带版本号的 ASVS 需求，报价就可比，复测也可验证。

WSTG 和 ASVS 针对应用层：Web 应用及其 API。云配置、Kubernetes 或构建流水线需要各自的方法，纳入范围须另行约定。

OWASP Top 10 2025 版是关于最关键 Web 应用风险的意识提升文档。它便于向管理层和开发人员解释结果，但它是风险类别清单，而不是测试计划。只承诺"覆盖 OWASP Top 10"描述的是最低限度，而不是对 SaaS 产品的评估。

治理与产品视角：NIST CSF 2.0 与 CISA 安全设计

NIST SP 800-115 于 2008 年 9 月发布，取代了 SP 800-42。它早于许多云架构，NIST 自己也强调该文件概述的是技术测试的关键要素，而非现成方案。其价值在于规范性：正式评估分为规划、执行和执行后三个阶段，最后一个阶段包括分析发现项和制定缓解措施。还应结合项目所选并记录版本的 OWASP 资料使用。

NIST 网络安全框架 2.0 有助于把渗透测试视为网络风险管理的一项输入，而非一次性活动。CISA"安全设计"（Secure by Design）倡议补充了产品方视角：高管层面对安全负责、默认安全，以及免费提供 MFA、日志记录和 SSO。在约定范围内，渗透测试可以检查选定承诺在实践中的实现方式。

哪些法律、标准或合同要求渗透测试以及频率如何，请向律师和审计方确认。报告可以作为 SOC 2、ISO 27001 或 PCI DSS 的证据之一，但不会让企业自动合规。

扫描器、人工渗透测试还是按发布测试

NIST SP 800-115 将扫描与渗透测试视为各有局限的不同技术。扫描能够扩展广泛且可重复的检查，但对业务逻辑、多步骤场景和跨租户授权的覆盖较弱。人工渗透测试可以更深入地探索漏洞链并安全证明影响，但仍是受时间、访问条件和范围限制的时间点快照。

黑盒、灰盒与白盒

黑盒更接近外部攻击者，但相当一部分预算花在侦察上，可能触及不到深层角色和跨租户越权。灰盒为团队提供账号、角色和 API 文档。白盒提供代码访问，可帮助追溯发现项的根因并寻找同类模式的其他位置，但不保证穷尽所有实例。

我们的实践判断：对多数 SaaS 产品而言，合理的起点是灰盒，并可按需查阅代码。这是关于效率的结论，而非规则：如果主要威胁是没有账号的攻击者，黑盒也有其合理性。

每周都在变化的产品该多久测一次

SaaS 持续变化，年度测试结果可能不再代表当前版本。CISA 关于安全部署软件的指南强调发布流程应包含可靠的测试和度量环节。一种可行的实践方案是分层模式：流水线中的自动化检查；发布高风险功能（新 API、角色模型变更、新集成）时的针对性测试；以及按固定周期或在重大发布前进行更深入的独立渗透测试。关于如何把针对性检查限定在变更部分，请参阅变更触发的渗透测试一文。

持续或众测项目在时间上覆盖面广，但需要强有力的报告分诊，也不能替代用预备角色对跨租户授权进行的周密检查。

如何安全地开展测试：授权、环境与监控

首先是书面授权。测试规则记录确切范围和排除的系统、时间窗口、允许的技术、数据最小化与脱敏、证据访问权限及保存期限、停止条件以及双方联系人。如果产品运行在云或其他服务提供商之上，也要核对其测试政策。开始工作前，对每项资产和环境有授权权力的一方必须记录许可、范围和规则；记录形式取决于项目约定和适用要求。

测试环境还是生产环境

对于预定检查具有代表性、与生产隔离且填充合成租户的测试环境，可以降低客户面临的运营风险。但测试环境的结果不能不加说明地套用到生产：配置、功能开关、服务版本、WAF 设置和访问权限都可能不同。因此应在开始前记录差异，并在报告中写明每个结果来自哪个构建版本和环境。

如果生产环境在范围内，只能在专用测试租户中进行，不接触真实客户数据，并遵守约定的请求频率；除非另行规划，否则排除拒绝服务类检查。群发邮件、支付和删除数据须事先约定或以安全演示替代。

检验检测能力

渗透测试也可检验监控：CISA 将日志记录列为默认开启的功能。请将测试人员的操作日志与系统实际记录比对：是否发现了标识枚举、跨租户访问尝试、代登录被开启？如果检测测试属于约定目标，已确认的盲区应记录为发现项；否则应作为有边界的观察结果报告。

发现项优先级：弱点类别、实际利用与影响范围

MITRE 发布了 2025 年 CWE Top 25 最危险软件弱点清单，以及一份与 CISA 已知被利用漏洞（KEV）目录相关联的弱点清单。与实际被利用漏洞相关联的类别值得更仔细审查；只有当具体发现项的可达性、影响、暴露程度和补偿性控制支持时，才应提高其优先级。

但 CWE 类别描述的是错误类型，并不能说明您产品中某个具体发现项被利用的可能性。类别层面的 KEV 关联是分析输入，而不是独立提高优先级的理由，也不能替代分析：该功能是否无需认证即可访问？影响多少租户？暴露哪些数据？有无补偿性控制？

对于 SaaS，严重程度应增加一个独立维度——影响范围。只影响用户自身数据的中危缺陷，与位于客户边界上的同类缺陷有本质区别。报告应明确说明发现项影响单个用户、单个租户还是多个租户。关于如何综合这些因素，请参阅基于风险的漏洞优先级排序一文。

应寻找有证据支持的根因，而不是停留在症状：根因分析可以为更广泛的修复提供依据，CISA 安全设计资料也从类别层面讨论如何防止跨站脚本、操作系统命令注入和目录遍历反复出现。适用的 CWE 编号用于分类弱点类型，而相关 ASVS 要求把适用的 Web/API 检查关联到具体的验证要求。如果证据确认多个位置存在同一原因，再考虑修复共享组件，例如在数据访问时集中校验租户、使用安全模板引擎或参数化查询。

从报告到修复与复测

按照 NIST SP 800-115，评估包括分析发现项和制定缓解措施。有用的报告包含管理层摘要、将适用的 Web/API 检查映射到 WSTG 和 ASVS 的范围与方法、每个发现项的可复现证据、CWE 编号、租户影响范围、业务影响和具体建议。局限需单独说明：哪些未测试、哪些角色和集成不可用、在哪个构建版本上测试。

接下来由企业自己闭环。这是我们的实践做法，而非 NIST 规定的阶段：按严重程度约定修复期限、指定负责人、进行复测，并跨项目跟踪反复出现的 CWE 类别。修复可通过合同委托给服务商或外部团队，但残余风险的接受决定应由组织中获授权的风险负责人作出。

复测同样有边界：它确认某场景在特定构建版本上不再复现，但不能证明相邻方法中没有同样错误。如果修复涉及共享组件——授权检查、模板引擎、查询构建器——应在其多个使用位置复查。关于如何建立这种验证，请参阅渗透测试修复验证一文。

可以向客户展示什么

CISA"按需安全"（Secure by Demand）指南帮助软件采购方在采购中向供应商提问，MITRE 也指出处理弱点时的透明能体现对安全的承诺。一封列明范围、日期、方法和修复状态的简短确认函或摘要，能回答客户问题而不泄露利用细节——前提是如实说明测试边界，不把渗透测试说成证书。

如何选择 SaaS 渗透测试服务商

明确了测什么以及如何使用结果，选择就归结为用证据对照需求。

在报价前应索取什么

向每家入围服务商索取同样一套材料：范围调查问卷、脱敏样例报告、方法论说明，以及项目专业人员的经验信息。如果问卷中没有关于租户、角色、API、后台任务和集成的问题，应要求说明；缺少这些信息，报价就无法证明覆盖了 SaaS 特有边界。

在样例报告中查看多租户授权和 API 测试、可复现证据、CWE 编号、影响范围以及对 KEV 相关弱点的处理。确认复测是否包含在价格中、何时进行、确认什么，以及是否提供面向客户的摘要。对资质和过往客户的说法要核实，而非轻信。

价格只有在范围对齐后才可比较：不同价格背后可能是不同数量的角色、API 方法和测试天数。对于适用的 Web/API 检查，一种可验证的范围描述方式是采用带版本号的 ASVS 要求和 WSTG 类别；其他组件需要各自的标准。

危险信号

以下情况值得警惕：把自动化扫描当作渗透测试；范围固定、不考虑您的租户模型；样例报告缺少可复现证据；报价只承诺"覆盖 OWASP Top 10"而无细节；服务商不愿书面确定授权和测试规则，或承诺"保证找出所有漏洞"。

您可以与 Pentest.red 讨论在约定范围内对 SaaS 产品进行人工渗透测试：纳入哪些租户、角色、API 和集成，报告应包含哪些证据，复测如何安排。具体条件可通过渗透测试服务页面单独沟通。合规审计、鉴证或 SOC 2 意见是合格审计师的另一类工作，渗透测试不能替代。

给管理层的决策顺序

如果基本安全措施已到位，并期望测试在修复后为风险降低作出可衡量的贡献，管理层可在几次会议内走完这一顺序。首先是触发因素（客户要求、重大发布、新 API、架构变更、审计）：它决定需要广泛测试还是针对性测试。然后盘点攻击面（包括后台任务和租户边界），并通过 ASVS 需求和 WSTG 类别设定目标严格程度。

接着确定测试模式（灰盒求深度、扫描求广度、按发布测试应对变更）、书面授权、测试租户、合成数据、监控计划以及测试与生产环境的差异说明。事先决定严重的跨租户发现项是否阻止发布、由谁接受残余风险、何时复测。根据已证明的影响、可达性、暴露程度和影响范围确定优先级，把 CWE 和类别层面的 KEV 关联作为背景信息，按 CSF 2.0 的思路纳入风险管理，并向客户提供如实的摘要。

每个项目后都应重新审视这一顺序。如果发现项集中在某一类别，应先确认是否存在有证据支持的共同原因，再将精力用于修复；如果发现项很少，不要据此断定产品安全；先评估剩余不确定性、范围和访问条件，再决定是否需要追加测试。

SaaS 渗透测试最终应带来什么

当范围围绕租户隔离、凭据和 API 构建，适用的 Web/API 检查通过 WSTG 和 ASVS 设定，发现项根据已证明的利用条件和影响范围确定优先级并推进到经过验证的修复时，SaaS 渗透测试尤其有价值。

把渗透测试当作测量工具，而不是证书。购买您能验证的严格程度，要求书面授权和可复现证据，如实记录测试边界，并依据已确认的根因修复适用的缺陷类别。如果把已确认的修复和经验纳入开发，下一轮测试可以从更高的起点开始，而重复出现的问题也会成为单独的信号。