前言
感谢您阅读此系列的第二篇文章。上一篇文章我们讨论了注入攻击。在视频中，可以看到使用它攻击传统应用程序到Serverless应用攻击面的变化。对于Serverless应用来说，注入攻击是基于不同源的各种事件。
在这篇文章中，我将研究Serverless应用安全性方面面临的另一个问题。在Serverless架构中，有很多隐秘的入口点，服务，事件和触发规则且没有连续的flow，事情可能会变得更加复杂。与传统应用程序架构不同，Servless应用在Stateless容器中运行。数百个不同的功能，分别运行在不同的Server，这意味着单个的Server没有很大的flow。不同的Server有不同的功能，由不同的事件触发，没有团队协作的概念。
攻击者试图寻找容易被遗忘的资源，像公共云储存仓库和公共API，这意味着作为开发者的我们必须给每个Server和资源加上密钥。然而，面向外部的资源不是唯一需要考虑的。让我们继续深入研究。
外部资源的认证方式通常很脆弱，用暴力破解的方式，攻击者可以使用自动化工具猜测用户的凭据。如果某个网站的认证方式很脆弱，那么攻击者就可以接触到它的敏感内容或功能。弱密码和不安全的密码恢复流程也是属于脆弱的认证方式。好消息，现在现代的网络中，服务器提供商能防御大多数的攻击。我们再也不用担心密码管理，暴力破解和密码恢复流程等安全问题。经验丰富，装备精良的服务提供商将完美防御任何这类攻击。
如果面向外部的资源没有合适的身份认证方式，那么Serverless应用会出现重大安全漏洞。现在，我们唯一要做的就是确保我们的资源配置正确，如恰当的访问权限控制和合适的认证方式。这可以由云服务商提供的身份管理服务轻松完成，如AWS Cognito，Azure AD，Google Firebase或Auth0等服务。
那么，我们可以去睡一觉，等待下一篇文章？NO！当应用的内部功能不是由用户端发出请求（或某些的事件）触发时，事情会变得更加复杂。在应用的整个flow中，存在一些特殊方式可以绕过我们的身份认证架构，接触到一些资源。这种漏洞通常是身份验证和访问控制设计存在缺陷的结果。
案例研究
一个非常简单的Serverless应用：
一. 正常的用户通过了身份验证，发送一个API请求，触发一堆内部flows（图中蓝色区域）
二. 用户也可以上传文件（例如图像），其存储在云存储中
三. 典型的Serverless flow：当文件上传到云存储时，触发另一个处理该上传文件的功能。
四. 从下图可以看到，云存储是开放的，不需要任何身份验证。
五. 恶意用户直接上传文件到云存储，触发内部功能，可以绕过身份验证。
所以？只是一个文件上传。这里的安全问题是什么？我们首先要了解我们绕过的flow(s)，
让我尝试着全面解读。
在这个例子中，用户通过指定的移动应用提交图片，应用程序打印图片。流程：
A. 用户注册并登录程序，然后选择所需的产品。
B. 完成后，用户将被重定向到付款的flow，填写收货和账单地址。
C. 付款信息被核准后，应用生成带有签名的云储存链接发送给用户，用户上传用于打印的图片。
D. 用户上传完成。考虑到安全性，应用程序会验证文件类型以确保仅为图像。
E. 上传完成后，用户将被重定向到主页，收到一封包含订单详细信息的电子邮件。
F. 另外，在文件上传后触发某个功能进行打印。
G. 打印完成后，应用会向用户发送一封电子邮件。
可以发现，云存储仓库没有正确的身份认证，可供任何用户直接上传图片文件。
这里可以造成一些攻击。首先，最明显的漏洞，攻击者可以不用付款，使应用跳转到下一个flow（绕过C阶段），即处理上传图片文件（阶段D）。如何实现？ 如果云储存开放写入访问权限，攻击者使用aws cli（AWS命令行界面）就可以进行攻击。
但这里还有另一个漏洞，应用程序会验证上传的文件类型和文件名，以确保没有上传恶意文件。可能有些人已经发现了，D阶段也可以绕过，攻击者可以直接上传恶意文件到云存储仓库。
保护云存储其实很容易，只需简单点击几下就可以阻止公共访问。问题是，我们如何确保内部资源中没有其他脆弱的身份验证方法？没有十全十美的办法。我们可以根据Serverless应用的资源类型和flow设计独特的认证方式，我们选择可以使用知名的服务，例如Federated Identity(e.g. SAML, OAuth2, Security Tokens)，并确保使用经得起实践的产物(e.g. encrypted channels, password and key management, client certificate, OTA/2FA)。
演示视频
如果你想观看演示视频，这里有