前言
由于云计算的发展，带来了如对象存储等很多丰富的中间件，应用开发者希望可以不用写后端逻辑，直接把逻辑写在客户端，组合云上的一些服务来完成业务逻辑，FaaS的概念逐渐浮现。
2014 年 AWS 在拉斯维加斯的 re:Invent 大会发布 Lambda ，得到业界非常大的关注。从 Lambda 开始，每个云厂商都逐渐有了自己的无服务器服务。
- 亚马逊AWS AWS Lambda 让您无需预置或管理服务器即可运行代码。只需按消耗的计算时间付费 代码未运行时不产生费用。
- 微软Azure 利用无服务器计算，开发人员可依赖基于云的服务器、基础结构和操作系统。
- 阿里云 函数计算是一个事件驱动的全托管计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。
- 腾讯云 无服务器云函数是腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。
- 华为云 函数工作流是一项基于事件驱动的函数托管计算服务。通过函数工作流，只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数以弹性、免运维、高可靠的方式运行。
以 AWS Lambad 为例，基本定义了什么叫 Serverless，只要一个服务具备了四方面特性：免运维、按需付费、高可用和自动扩容，这个服务就是个 Serverless 的服务。所以 Serverless 这个概念可以对应 FaaS，也可以代表一种架构，也可以代表一种服务的形态。而Serverless与容器的区别在于，Serverless 是无容器的，除了不关注服务器，也看不到容器。两者是面向不同场景的，并不是互相替代的关系。
OWASP自2017年就提出了无服务器应用风险TOP10，下面将详细介绍其风险
OWASP Serverless top10
A1 | 注入 |
|---|---|
A2 | 失效的身份验证 |
A3 | 敏感数据泄露 |
A4 | XML外部实体 |
A5 | 失效的访问控制 |
A6 | 安全配置错误 |
A7 | 跨站脚本 |
A8 | 不安全的反序列化 |
A9 | 使用含有已知漏洞的组件 |
A10 | 不足的日志记录和监控 |
一、注入
维度测评
攻击向量 | API调用、云存储时间、留时间处理、数据库更改、代码更改通知 |
|---|---|
安全弱点 | SQL/NoSQL注入、命令注入（关注于容器里的代码和敏感信息） |
影响 | 取决于受攻击函数的权限 |
总体评价 | 攻击门槛较高、API攻击安全可预测、但攻击面更广 |
预防
- 不信任输入，对输入进行校验
- 用安全的API
- 尽可能使用白名单验证
- 标识信任源和资源列入白名单
- 动态查询，特殊字符要进行转义
- 考虑所有事件类型和入口点
- 以最小特权运行函数
- 使用可靠的运行时防御方案来保护函数
综述
SQL注入，OS命令注入，代码注入之类的攻击以及许多其他攻击的方式通常是黑客的最爱，同时，在蓝方看来，这些攻击一直被认为是头号风险，他们通常会尽一切努力来防止它们。即使经过至少二十年的整体应用程序开发，仍然存在这些问题。
所以，这依旧在OWASP无服务安全领域排行前十。但是，对于注入攻击的防护比以前的更加容易。在无服务出现之前，注入攻击几乎是相同的攻击流程。应用程序处理来自不受信任源的输入，该输入通过网络进入应用程序。
尽管第一部分依旧是一样的，但在无服务器的“网络”上却是一个更复杂的术语。无服务器功能通常是通过事件触发的。事件可以是基础架构提供的任何服务，例如云存储，电子邮件或通知。
这意味着编写安全的代码更加重要，我们不能再相信网络外围放置的安全控制设备为我们提供保护。我们留下的代码可以在不知道目标优劣，不知道发生了什么的情况下运行。如果该函数的代码容易受到任何类型的注入攻击，那么在无服务器环境中，通常将其称为事件注入。
案例
以owasp的官方靶场为例，输入任意网址然后添加 ; ls
返回结果如下，可以看到由攻击者输入的ls命令被服务器端执行
二、失效的身份验证
维度测评
攻击向量 | 公有云存储或开发的API、欺骗性电子邮件 |
|---|---|
安全弱点 | 潜在的入口点、服务、事件和触发器 |
影响 | 敏感信息泄露、破坏系统的业务逻辑和业务流程 |
总体评价 | 无服务器使用完整和安全的身份验证方案比较复杂、识别没有身份 验证的内部触发函数是一个挑战 |
预防
- 尽量使用基础设施提供商提供的身份验证 方案
- 面向外部资源要进行身份验证和访问控制
- 内部资源的访问控制要使用已知的安全方法，公司最好有自己的统一标准
三、敏感数据泄露
维度测评
攻击向量 | 窃取密钥、中间人攻击、在静态存储和传输中获取数据、Github获取密钥、函数的运行环境如/tmp目录中获取函数的源代码和环境变量 |
|---|---|
安全弱点 | 明文形式存储敏感数据、容器销毁时不清理/tmp目录 |
影响 | 敏感数据暴露造成的维护与传统模式一致 |
总体评价 | 敏感数据泄露是一个风险，但服务提供商提供了一整套安全方案帮助开发者保护自己的数据 |
预防
- 识别并分类敏感数据
- 将敏感数据存储最小化，仅为绝对必要
- 根据最佳实践保护静态和传输中的数据
- 仅使用https用于API
- 尽可能使用基础设施提供商提供的密钥服务和加密服务加密敏感数据案例以owasp的官方靶场为例，输入任意网址然后添加 ; env #
即可查看到亚马逊云的access_key等敏感参数,通过这些关键数据访问其存储服务可以造成更进一步的利用
四、XML外部实体
维度测评
攻击向量 | 云存储上传事件触发 |
|---|---|
安全弱点 | 使用XML处理器可能导致XXE攻击 |
影响 | 可能导致函数代码和敏感文件泄露 |
总体评价 | 使用供应商的SDK可以降低XXE的风险和影响，如果使用了XML解 析，请确保安全 |
预防
- 尽可能使用服务提供商的SDK
- 扫描供应链中相关库的漏洞
- 如果可能，通过API调用识别和测试XXE
- 确保实体禁用
五、失效的访问控制
维度测评
攻击向量 | 超特权功能为目标,而不是控制环境 |
|---|---|
安全弱点 | 授予函数过多资源的权限是潜在的后门,不遵守最低授权原则的函数都可能导致访问控制受损 |
影响 | 取决于受损的资源 |
总体评价 | 就算不存在基础设施,也可能会泄露敏感数据 |
预防
- 检查每个函数，遵守最小授权原则
- 检查每个函数，防止过多的权限
- 建议自动执行权限配置功能
- 遵循供应商的最佳实践相关危害
- 对特定存储桶进行未经授权的操作，如：读取和/或删除其他用户订单或上传未经验证的文件·
- 删除账户中的其他存储，即使是在功能/应用范围之外；
- 执行内部功能，如：执行带有恶意输入的函数。由任何帐户云存储上的事件触发；
- 通过高容量上传大文件或消耗高带宽等耗费成本的操作导致拒绝钱包攻击 (DoW)
六、安全配置错误
维度测评
攻击向量 | 无链接的触发器、公共存储桶 |
|---|---|
安全弱点 | Github密钥泄露、长超时函数攻击和低并发函数攻击 |
影响 | 敏感信息丢失、资金损失、DoS攻击，严重情况下导致未经授权访问云资源 |
总体评价 | 入口点数量增加、但是影响降低 |
预防
- 扫描云账户识别公共资源
- 实施强制访问
- 遵循供应商的最佳实践
- 检查具有未链接触发器的功能
- 将超时设置为函数所需的最小值
- 遵循供应商提供的功能配置建议
- 使用自动工具检测安全配置错误案例
七、跨站脚本(XSS）
维度测评
攻击向量 | 存储攻击,Email、存储、日志等 |
|---|---|
安全弱点 | 在JSON中解析不受信任的数据 |
影响 | 敏感信息泄露 |
总体评价 | 更多攻击媒介,但影响更小 |
预防
- 不受信任的数据，输入进行校验，输出进行编码
- 已知框架和头文件同样有效
案例
以owasp的官方靶场为例，使其包含一个恶意的doc文档。
文档内容如下：
成功触发弹框：
八、不安全的反序列化
维度测评
攻击向量 | Python、NodeJS和JSON的普及使得向量很广泛 |
|---|---|
安全弱点 | 第三方库处理JSON数据引入漏洞 |
影响 | 任意代码执行和数据泄露 |
总体评价 | 攻击面很小、但影响很巨大 |
预防
- 通过执行严格的类型约束来验证来自任何不受信任的数据（如：云存储、数据库、电子 邮件、通知、API）的序列化对象；
- 查看第三方库是否存在已知的反序列化漏洞；
- 监控反序列化使用和异常以识别可能的攻击也是一种很好的做法。 综述Python 和 NodeJS 等动态语言，伴随着 JSON（一种序列化数据类型）的普及，使得无服务 器世界中的反序列化攻击更加常见。
与可能的攻击向量一起，大多数函数使用第三方库来处理数据的序列化，可能会给我们的无服务器应用带来这样的弱点。反序列化漏洞在 Python（如：pickle）和 JavaScript（如：nodeserialize）中很常见，但也可能在.NET 和 Java 中找到。
像往常一样，业务影响取决于应用及其处理的数据。不安全的反序列化通常导致运行任意代 码，最终可能导致数据泄漏，在严重的情况下甚至会导致数据泄漏资源和帐户控制。
九、使用含有已知漏洞的组件
维度测评
攻击向量 | 依赖库和第三方库 |
|---|---|
安全弱点 | 问题很普遍 |
影响 | 一些大规模的漏洞爆发正是利用了已知组件的漏洞 |
总体评价 | 每个函数都会带一大堆的依赖，所以漏洞存在的可能性更高 |
预防
- 在整个系统中监控依赖组件及其版本
- 仅通过安全链接从官方来源获取组件
- 持续监控CVE和NVD等来源的漏洞
- 建议使用商业化方案扫描已知组件的漏洞
十、不足的日志记录和监控
维度测评
攻击向量 | 依靠监控和日志记录不足来避免被发现，无服务器审计更加困难 |
|---|---|
安全弱点 | 不实施恰当的审计机制和仅依赖服务提供商的手段 |
影响 | 影响不确定，但太晚发现攻击可能造成很大的损失 |
总体评价 | 缺乏恰当审计机制所造成的影响本身是无法确定的。但是，太晚发现安全事件的影响可能是重大的。攻击者可能已经成为应用的一部分，并感染了代码。值得一提的是，无服务器函数的短暂性降低了攻击的粘性，这意味着即使应用被感染，如果攻击者不使用技术使攻击持续下去，它可能会自行消失。 |
预防
- 利用服务提供商的监控工具来识别和报告不需要的行为
- 部署审计和监控基础设施提供商未充分报告的数据的机制，以识别安全事件
其他风险
除TOP10以外从实战环境视角参考还有一些其他需要考虑的风险
拒绝服务（DoS）
在实际场景中，每个事件都是在一个单独环境中处理的，这意味着传统的 DoS 攻击与当前场景不太一样。即使攻击者设法让容器不可用，但它也只会影响进入此环境的事件，而不会影响下一个即将发生的事件。
但是这不代表威胁不存在，只要着眼于当前条件，攻击者照样可以实现跨账户的 DoS：
- 函数并发限制（如：触发函数，直到实现预定义的并发为止）；
- 环境磁盘容量（如：填充/tmp 文件夹）；
- 帐户读写容量（如：触发允许最大 DynamoDB 表扫描）。
加固基础设施有助于防御此类攻击，AWS 甚至还提供了一些解决方案（如：AWS Shield）。因此，针对此类攻击，风险较低。
风险值：2分
拒绝钱包（DoW）
自动化的可伸缩性和可用性是使用无服务器的原因之一。这允许应用开发人员只为自己使用的部分付费，并将扩展应用的责任转移到基础设施提供商。
由于这种天然特性。攻击者可以疯狂触发资源（如：外部 API、公共存储），让服务提供者造成大量资源损失从而加大资金开销。
为了“防止”此类攻击，AWS 允许配置调用或预算的限制。然而，如果攻击者可以达到该限制，他可能会对账户可用性进行 DoS 攻击。在传统体系架构中，攻击并不像在无服务器体系架构中那样简单。因此，该问题风险相当高。
风险值：9分
不安全的机密信息管理
安全的管理我们所有的机密信息总是很难的。然而，机密信息通常可以在后台一个受保护的地方进行管理。在无服务器中，它们在账户中跨资源共享。
像密钥、API 令牌、存储凭证和其他敏感设置等这样的机密信息，现在更容易在函数和代码之间共享，这可能会导致敏感数据泄露的风险难以缓解。
此外，如果机密信息以环境变量的方式被存储在每个函数所部署的环境之中，而不是一个传统的配置文件，那么如果受到破坏，就很难对所有函数进行更改。
另一方面，与现场编译版本相比，在云原生应用上更改已获取的密钥更容易。因此，总体风险应与传统应用中的风险相等。
风险值：5分
不安全的共享空间
如果容器没有被销毁，那么无服务器的环境空间在调用之间是被共享的，这意味着，如果应用将一些数据写入用户空间（如：/tmp），并且在使用后没有手动删除这些数据，并且认为容器将会销毁，那么攻击者就可以利用这些数据窃取其他用户的数据。
这可能需要另一个漏洞，为攻击者提供对该环境访问权限。如果应用容易受到代码或者命令注入的攻击，攻击者只需要简单地访问/tmp 文件夹并窃取敏感数据即可。
在传统应用上，这通常是在应用容易受到遍历攻击时实现的。在AWS无服务器服务上，唯一可写的空间是/tmp。然而它只是暂时的（或仅限于容器），这使得风险略低一些。
风险值：4分
业务逻辑/流程操作
业务逻辑攻击可能是检测到的最复杂攻击，通常具有很高的业务影响。诸如识别、约束和流操作之类的攻击对于无服务器可能不是唯一的，但事实是，使用无状态的微服务意味着在依赖之前可能发生或已经发生的事件时，应考虑详细设计。
此外，在某些情况下，函数只能由某些调用者调用。由于他们是无状态的，这意味着他们可能无法被核实。
这种行为可以通过以下方式实现：
- 攻击配置错误的公共资源，触发一个内部功能来绕过执行流程（请参考 A2：失效的身份验证攻击案例场景）；
- 攻击那些访问控制没有被强制执行并导致流操作被执行的资源；
- 通过操作函数所依赖的参数来访问未经授权的数据，而没有方法对其进行验证；
- 修改客户端代码以绕过限制。
仅无状态体系结构就使逻辑和流操作成为无服务器应用中的实际风险，这很容易导致 DoS、
DoW、调用内部功能、执行流绕过等。在无服务器应用中，总体风险应该明显更高。
风险值：8分
函数的安全性
以上概况了各种类型的威胁，然而放眼实际场景，可能还是略有不同。
再次以AWS的lambda为例 2018年10月 一位名叫Caleb Sima的用户提供了一个在线的网站http://www.lambdashell.com/ 使用默认的权限和配置让人们通过Lambda函数攻击他的AWS账户，该函数使人能够运行Shell命令,甚至还做出了美观的GUI界面，但到目前为止没有人能造成严重破坏。
唯一的例外是有些人设法使用过度特权的功能删除了他的网页，当然还有一些人设法挖掘加密货币（尽管每次调用需要3秒钟），但这只是在他故意向其设置引入了一些宽松权限之后才发生的。
靶场
官方靶场：https://www.serverless-hack.me/
项目地址：https://github.com/OWASP/Serverless-Goat
参考
参考文档：OWASP无服务器安全风险Top10
参考文章：https://www.keithrozario.com/2019/02/securing-lambda-functions.html
参考文章：https://thetestlabs.io/code/exploiting-common-serverless-security-flaws-in-aws/
参考文章：https://www.protego.io/category/a-deep-dive-into-serverless-attacks/
参考文章：https://www.protego.io/owasp-top-ten-serverless-attacks-sls-1-event-injection/
参考项目：https://github.com/puresec/sas-top-10
本文作者 r0fus0d、RyuZU、the-fog、xidaner、Alienware-OWO
