如何给SaaS应用做安全测试-开发者社区

作者 | 陈峻

审校 | 重楼

SaaS（软件即服务）应用在过去几年中得到了迅速发展。应用截至2023年，做安全球已有超过30,全测000家SaaS初创公司。SaaS应用程序已成为无数行业在线业务的应用重要组成部分和首要选择。凭借着简化的做安流程，便捷的全测交付和可扩展性，越来越多的应用应用数据和业务逻辑已从本地被迁移到了SaaS云端环境中。

然而，做安SaaS应用的全测增长与普及也自然成为了无数网络威胁与攻击的诱人目标。面对各种安全挑战，应用SaaS应用供应商和使用方需要通过全方位的亿华云做安安全措施与测试来积极分析与应对。

SaaS面对的全测主要风险

由于SaaS应用通常被托管在服务提供商的云服务器上，并让用户设备通过互联网进行访问，应用因此这种交付模式具有更低的做安成本和更易维护的优点。不过，全测攻击者一旦发现SaaS应用上存在安全漏洞，就会想方设法通过获取应用服务的访问权限，如探囊取物般批量获取使用方和客户的数据信息。

目前，此类风险大致包括如下方面：

多租户架构缺陷

在多租户SaaS架构中，云计算来自不同客户的数据驻留在同一台服务器上。一旦租户之间的逻辑隔离不到位，那么某个租户就可能无意、甚至刻意访问到另一个租户的数据，进而出现隐私信息的泄露，机密性的缺失。

任意访问的开放性

由于任何人都可以从任何位置访问SaaS应用，因此攻击者不再受限。他们可以轻松地使用网络钓鱼诈骗，来获取用户凭据，模板下载或通过直接破解弱密码，来实现未经授权的访问。

与其他应用的集成

SaaS平台通常使用API来与其他应用集成。如果这些API在设计上具有安全缺陷，那么攻击者便可以将其作为网关，渗透到SaaS应用以外的多个系统，并窃取敏感数据。

故障导致数据丢失

虽然SaaS的云服务保障了应用的可用性，但是云服务器上的数据安全性可能因网络问题、源码库设备故障、甚至是自然灾难而丢失或损坏。对此，安全团队在检查SaaS业务时，应注意数据备份策略的可靠性，以避免因为数据丢失而造成服务的完整性欠缺。

直接遭遇攻击

根据开放式Web应用安全项目（OWASP）列出的典型十大Web应用和API风险，我们可以知道SaaS应用上一旦存在逻辑漏洞和技术问题，就会被黑客通过互联网，发起直接攻击和利用，也就可能产生服务中断、数据泄露、服务器租用以及隐私侵犯等不利影响。

责任共担

由于多个应用共享同一套云服务系统与后台逻辑，因此服务提供方的配置错误、服务中断等运营故障，就可能会被SaaS系统的共享结构所放大，进而波及到使用方的业务，甚至将网络钓鱼、恶意软件、以及勒索攻击，传播至使用方的业务数据上，使其被动承担相应的责任。建站模板

欠合规与监管

纵然SaaS应用的使用方竭力遵循合规与监管的要求，但是一旦疏忽了对其使用到的SaaS供应商的合规性查验，则会面临连带的监管风险，进而导致巨额的罚款、或让公司声誉受损。对此，安全团队应定期审查SaaS供应商对行业标准和法律法规的遵守情况。

测试的概念与好处

鉴于SaaS应用为用户简化了复杂的服务处理与提供机制，而其自身通常会保留使用方和最终用户的大量敏感商业信息与个人数据，因此SaaS安全测试可以通过对SaaS业务的所有组成部分采取深入扫描、利用与评估，以发现并修复应用在界面、网络、通信、API、第三方集成、基础代码、用户输入、以及角色权限等方面的安全漏洞，进而降低SaaS应用的运营风险，改进其安全态势。

可见，SaaS安全测试不但有助于保障企业的云端系统、应用与数据安全，而且能够满足各种严格的合规性要求。

测试关注的组件

对于SaaS应用的安全测试而言，安全团队通常需要关注和检查如下三个方面的基本组件：

连接的安全性

客户端设备与SaaS应用的连接是一个值得关注的重要风险点。鉴于SaaS应用的特点，服务提供商需要为使用方实施必要的信道保护、身份验证、权限管理、以及行为监控等连接上的准入与保障。而本着“从不信任，始终验证”的零信任原则，应用使用方的安全团队有必要通过了解，来为后续的安全测试做好规划。

应用服务的安全性

SaaS应用虽然简化了使用方的自我构建，对于后端复杂的调用逻辑，使用方往往通过API 、以及配套的管理控制台来实现调用。不过，在开展应用安全测试之前，使用方的安全人员有必要通过与SaaS服务供应商的交互，获悉其平台应用本身的基本业务类型，了解其技术架构可能存在的挑战，API的权限管控，管理控制台的设置与操作逻辑。

集成交互的安全性

使用方往往需要将由SaaS平台提供的服务与数据，通过API集成等方式，为自己的前端应用提供扩展的功能、自动化的工作流、以及与其他服务的交互。鉴于此类集成往往是一次性完成的，因此使用方的安全团队应当根据职责分离（SoD）和最小权限（PoLP）原则，审查前端应用与SaaS平台集成及交互的必要性与可控性。

测试的阶段

为了避免出现“拆盲盒”的不确定性，使用方的安全团队可以参考如下步骤，分阶段开展SaaS安全测试：

收集信息

安全团队在考虑对SaaS应用开展安全测试之前，需要对待测的应用的架构、网络、业务逻辑、数据流转、以及角色权限有所了解。这是制定有效的测试策略的基础。鉴于安全团队可能并非在应用项目开始时就参与其中，因此我们可以通过如下简单的问卷列表，来获取“第一手资料”：

该应用能够提供哪些基本功能？哪些团队会在哪些场景下使用到该应用？该应用对于前端业务的重要程度？该应用中将存储哪些业务数据类型，它们的敏感度如何？最终用户会使用受管理的设备、还是个人终端访问该应用？用户会使用受管理的私密网络、还是互联网连接访问该应用？访问该应用的方式是浏览器、还是由使用方提供的应用接口？平台供应商是否能给出应用的架构、通信、以及配置等信息？特别是如下安全控制信息：

Web应用防火墙（WAF）等云安全组件

可用的外部端口

负载均衡和DDoS保护

基于身份认证管理（IAM）的单点登录（SSO）集成、或多因素身份验证（MFA）的访问控制

静态和传输中的数据加密

服务器上的端点检测和响应（EDR）和反病毒（AV）方案

API密钥的管理与限流

数据与代码的备份和服务的高可用性（HA）

日志记录和监控选项

制定计划

安全测试团队根据了解到待测应用的信息与复杂程度，与各个利益方讨论潜在的限制、预估的成本，最终创建一个全面的安全测试计划，其中包括：明确的范围、标准、方法、深度、以及测试所需的系统配置、工具、及脚本。

双方交流

安全测试团队通过与被测应用供应商交流，确定将要执行测试的人员以及联系方式，给将要使用的测试工具开放端口，并将其IP地址放入白名单，按需开放跳板主机，以及开通测试工具的安装许可。

自动扫描

该阶段，安全团队通过专业的扫描工具，采用自动化的方式，仔细寻找被测应用的显著漏洞。此类工具往往具有一定的侵入性。也就是说，它们可以通过模拟潜在的攻击者，来爬取应用中的每个请求，进而快速地发现潜在的安全弱点和漏洞。

利用测试

针对自动化扫描到的漏洞，安全测试团队需要综合运用PoC（漏洞验证程序）和EXP（漏洞利用程序）里的各种工具、Selenium脚本、及策略，通过手动测试的方式，按照计划所制定的标准与范围，先后对应用开展黑盒、白盒、以及灰盒（按需）等类型的利用和测试。参照OWASP Top 10，典型的测试要点包括：

注入渗透服务器配置审查模糊输入数据篡改文件上传跨站脚本（XSS）

通过模拟攻击的真实场景，我们可以获悉被测应用的抗攻击能力、以及攻击得逞后，可能泄露的数据、篡改的系统、以及中断的服务。值得一提的是，安全测试人员除了使用手动测试技术，也可以利用自动化工具模拟人类的交互，以社会工程的方式非法获取应用的访问授权。

评估报告

在完成了利用测试之后，安全测试团队应根据记录到的漏洞，测算潜在系统的损失、参考CVSS评分、以及核对如下维度实施漏洞分类，影响分析，优先级评定，以及按需进行风险计算。

IAM – 基于角色的访问控制（RBAC）、SSO、MFA数据安全 – 数据加密、数据分级、数据泄露保护（DLP）可见性 – 日志记录（SIEM）、监控、警报配置 – 安全设置、访问控制列表（ACL）、IP白名单、接入的第三方应用网络 – WAF 、入侵检测、DDoS保护合规–认证（ISO 27001 、SOC 2 Type II、PCI DSS等）、隐私（PII、HIPAA 、GDPR、CCPA等）

此外，通过结果保存与按需截屏的方式，安全测试团队最终出具高准确度的报告，并向利益相关方给出修复建议。

整改重测

针对被确认的漏洞，应用使用团队将协同安全团队着手整改。而对于实难整改的部分，则可以按需引入云访问安全代理（CASB）和云安全态势管理（CSPM）等元安全组件以辅助加固。完成后，安全测试团队将进入重新测试的阶段，以确认漏洞是否被修复，且无新的漏洞产生，进而达到提高SaaS应用程序的整体安全态势。