Serverless安全研究—Serverless安全风险

一.专题信息专题: Serverless安全研究
标签: Serverless安全风险
二.引言通过上一篇《Serverless安全研究 — Serverless概述》相信各位读者已经对Serverless有了一个大致的理解 , 本文为Serverless安全研究系列的安全风险篇 , 笔者将从Serverless安全架构介绍出发 , 对目前Serverless面临的安全风险进行分析解读 , 并针对每种风险提供相应的攻击实例 , 希望可以引发各位读者更多的思考 。
三.Serverless安全架构
Serverless安全研究—Serverless安全风险文章插图
图1. Serverless安全责任共享模型图
图1为Serverless环境下安全责任共享模型图 , 图中不难看出FaaS提供商负责云环境的安全管理 , 主要包括数据中心集群、存储、网络、数据、计算、操作系统等 , 除此之外 , 应用程序逻辑、代码、客户端数据、访问控制等同时需要安全防护能力 , 这一部分是应用开发者的责任 。
上一篇文章中提到的 , Serverless有一大局限性便是供应商锁定问题 , FaaS提供商非常之多 , 每一家厂商均有着不同的安全解决方案和各自的实现机制 , 因缺乏统一标准 , 故本文笔者将不对FaaS平台面临的安全风险进行阐述 , 重点放在开发者侧面临的安全风险上 。
通过近期的调研 , 笔者总结并绘制了一幅Serverless安全风险脑图 , 如下所示:
Serverless安全研究—Serverless安全风险文章插图
图2. Serverless安全风险脑图
笔者将Serverless开发者测的安全风险简单分为五类 , 以下笔者会针对每一类进行分析说明 。
四.Serverless安全风险【Serverless安全研究—Serverless安全风险】4.1 针对应用程序代码的注入攻击
应用程序内部由于开发者未对外界输入数据进行过滤或编码 , 因而经常导致SQL注入、系统命令执行等攻击行为 。 过去的传统应用程序中 , 开发者可根据自身实战经验在数量有限的可能性中轻易判定出恶意输入来源 , 而Serverless模式下的函数调用由事件源触发 , 输入来源的不确定性限制了开发者的判定 , 以下是函数的事件源示意图:
Serverless安全研究—Serverless安全风险文章插图
图3. 函数事件源触发示意图
通常来说 , 当函数订阅一个事件源后 , 该函数在该类型的事件发生时被触发 , 这些事件可能来源于FaaS平台内部或外部 , 也可能是来源于未知的 , 对于来源未知的事件源可被开发者标注为不受信任 。 在实际应用场景中 , 开发者并没有良好的习惯对事件源进行分类 , 常将不受信任的事件错认为是平台内部事件因此常被视为受信任的输入来处理 , 导致了大量注入攻击的发生 。
有关Serverless应用程序的注入攻击实例研究可参考OWASP(Open Web Application Security Platform)组织在2017年发布的《Top 10 Interpretation for Serverless》报告【7】 。
4.2 针对应用程序依赖库漏洞的攻击
开发者在编写应用程序时不可避免的会引入第三方依赖库 , 毕竟有许多现成的实现逻辑无需开发者自己编写 , 这样就面临一个非常严峻的问题 — 开发者是否使用了含有漏洞的依赖库?据Synk公司在2019年的开源软件安全报告中【8】透露 , 已知的应用程序安全漏洞在过去两年增加了88%【2】 。 我们不妨试想如果开发者编写的函数只有短短几十行代码 , 但同时引入了第三方含有漏洞的依赖库 , 那么即使函数编写的再安全也是无济于事的 。 此外 , 引入了第三方依赖库也会实际增加应用部署至服务器的代码总量 , 例如python库 , 其代码量可能是上千行 , node.js的npm包中的代码量就更大了 , 可能会导致上万行 , 随着代码量的增多 , 攻击面也相应增加 , 从而给客户端程序带来了极大安全隐患 。
近年来 , 随着业界对不安全的第三方依赖库的重视 , 许多行内报告包括OWASP Top 10项目均提出了使用已知漏洞库的安全风险 , 这些含有漏洞的依赖库可在CVE、NVD等网站上进行查询 , 在此笔者列出Serverless场景下使用率较高的三种开发语言库漏洞列表供各位读者参考【3】 , 细节由于篇幅原因不予赘述 。
已知的Node.js库CVE漏洞列表:
已知的Java库CVE漏洞列表:
已知的Python库CVE漏洞列表:
关于Serverless第三方依赖库漏洞本文在4.5小节有一个实例分享 , 详情见下文 。
4.3 针对应用程序访问控制权限的攻击
访问控制作为应用程序的一大安全风险在Serverless场景下也同样存在 , 例如函数对某资源的访问权限、可以触发函数执行的事件等 。 试想这么一个场景 , 函数执行业务逻辑时不可避免会对数据库进行CRUD操作 , 在此期间 , 我们需要给予函数对数据库的读写权限 。 在不对数据库进行其它操作时 , 我们应当给予只读权限或关闭其权限 , 如果此时开发者将权限错误的更改为读写操作 , 攻击者会利用此漏洞对数据库展开攻击 , 从而增加了[lw3] [PM4] 攻击面 。