深入考察无服务器架构的安全威胁，SLS-2：突破身份验证的防线
欢迎大家来到本系列文章的第二篇。在上一篇文章中，我们讨论了各个平台下最令人担忧的攻击方式——注入攻击。在本文中，我们将为大家介绍当我们的系统从传统的单体应用程序中基于边界的入口点迁移到无服务器应用程序的过程中，攻击面会带来哪些方面的变化。对于无服务器应用程序来说，注入攻击是基于事件的，而且，这些事件的来源也是五花八门。
作为本系列的第二篇文章，这里将研究应用程序安全方面所面临的另一个安全问题。在无服务器体系结构中，会有多个潜在的入口点、服务、事件和触发器，并且没有连续的执行流程，因此，事情会变得更加复杂。与传统架构不同，无服务器函数是在无状态的计算容器中运行的。这意味着根本就不存在由服务器管理的大型流程，相反，现实情况是，会有数百种不同的函数在各行其事。并且，每一个函数都具有不同的用途，由不同的事件来触发，并且，也没有其他活动部件（moving parts）的概念。
对于开发人员来说，这就意味着我们需要确保每个资源都需要进行适当的身份验证，而对于攻击者而言，则可以尝试寻找被“遗忘”的各种资源，如公共云存储或开放API。但是，除了面向外部的资源，还有许多东西需要引起我们的关注，下面我们略举一二。
实际上，外部资源的身份验证被攻陷是非常常见的事情，并且，最常见的攻击手法就是暴力破解，即攻击者能够使用自动的试错方法来猜解用户的登录凭据。如果身份验证系统的强度不够的话，攻击者就能直接访问包含敏感内容或功能的网站，并且完全无需通过网站的身份验证。身份验证强度不足的情形，还涉及弱密码和不安全密码恢复过程等攻击。不过好消息是，大多数攻击的处理，现在都是交由服务提供商来应付的。所以，我们不再需要处理密码管理、反自动化和密码恢复流程。换句话说，任何诸如此类的攻击活动，都将遭遇经验丰富、装备精良的基础设施供应商的顽强抵抗。
现在，我们唯一要做的事情，就是确保我们的资源配置的正确性，具有合适的身份验证和访问控制机制。而且，这些机制可以通过云基础设施提供的身份管理服务来轻松实现，这些服务包括AWS Cognito、Azure Ad、Google Firebase或Auth0，等等。只要面向外部的资源的任何一部分没有采取适当的身份验证控制的话，都可能导致我们的无服务器应用程序出现重大安全隐患。
那么，难道大家真的可以高枕无忧，无所事事的等着俺下一篇文章的到来吗？绝非如此！如果内部函数不是由最终用户的请求（或者任何类型的事件）触发的，而是由应用程序的整个流程中的某个位置的某个资源绕过应用程序身份验证而直接触发的，那么事情就会变得更加复杂。这种身份验证的失败通常是身份验证和访问控制设计不佳的后果。
下面，假设有一个非常简单的无服务器场景，具体如下所示:
1.经过身份验证的用户发送了一个API请求，从而触发了一组内部流程（见蓝色区域）
2.该流程涉及到用户上传的文件（例如图像），并且该文件是存储在云存储器中的。
3.作为典型的无服务器流程，当文件上传到云存储时，它会触发另一个处理该文件的函数。
4.但是，云存储是开放的，并不需要任何身份验证。
5.恶意用户可以文件直接上传到云存储，触发内部函数，因此，攻击者可以借此顺利绕过身份验证。
结果呢？上传的是另一个文件。这里最大的(安全)问题是什么？为了理解这个问题的影响，首先需要搞清楚我们刚刚绕过的那个流程，为此，我们需要从整体着眼。
例如，假设有一个应用程序会根据用户通过指定的移动应用上传的图像来完成画布的打印操作。该应用程序的登录流程如下所示：
A.用户注册/登录应用程序，并选择所需的产品。
B.完成上述操作后，用户会被重定向到结帐流程，在那里，他们需要填写相应的发货和帐单接收地址。
C.当计费信息通过审核后，会向用户发送一个指向云存储的签名链接，这样，他们就可以上传图像来进行打印了。
D.之后，用户上传所需的文件。为了增加安全性，应用程序会验证文件的类型，以确保仅能将图像上传到存储空间。
E.完成上传后，用户将被重定向到主页，并发送一封包含订单详细信息的电子邮件。
F.此外，文件上传时，还会触发一个函数来处理打印事项。
G.处理完成后，系统将向用户发送确认电子邮件。
正如我们已经提到的，云存储没有配置正确的身份验证机制，所以，任何用户都可以直接将文件上传到云存储中。
这使得某些攻击成为可能。首先，也可能是最明显的一点，攻击者可以利用这一点来操纵应用程序执行流程，在填写收货信息后就能够立即触发图像处理函数，根本无需提供计费信息(即，绕过了上面列表中的步骤C )。他们是如何做到的呢？如果存储对其具有开放的写访问权限，攻击者可以直接利用aws cli来实现这一攻击。
欢迎大家来到本系列文章的第二篇。在上一篇文章中，我们讨论了各个平台下最令人担忧的攻击方式——注入攻击。在本文中，我们将为大家介绍当我们的系统从传统的单体应用程序中基于边界的入口点迁移到无服务器应用程序的过程中，攻击面会带来哪些方面的变化。对于无服务器应用程序来说，注入攻击是基于事件的，而且，这些事件的来源也是五花八门。
作为本系列的第二篇文章，这里将研究应用程序安全方面所面临的另一个安全问题。在无服务器体系结构中，会有多个潜在的入口点、服务、事件和触发器，并且没有连续的执行流程，因此，事情会变得更加复杂。与传统架构不同，无服务器函数是在无状态的计算容器中运行的。这意味着根本就不存在由服务器管理的大型流程，相反，现实情况是，会有数百种不同的函数在各行其事。并且，每一个函数都具有不同的用途，由不同的事件来触发，并且，也没有其他活动部件（moving parts）的概念。
对于开发人员来说，这就意味着我们需要确保每个资源都需要进行适当的身份验证，而对于攻击者而言，则可以尝试寻找被“遗忘”的各种资源，如公共云存储或开放API。但是，除了面向外部的资源，还有许多东西需要引起我们的关注，下面我们略举一二。
www.wnhack.com
实际上，外部资源的身份验证被攻陷是非常常见的事情，并且，最常见的攻击手法就是暴力破解，即攻击者能够使用自动的试错方法来猜解用户的登录凭据。如果身份验证系统的强度不够的话，攻击者就能直接访问包含敏感内容或功能的网站，并且完全无需通过网站的身份验证。身份验证强度不足的情形，还涉及弱密码和不安全密码恢复过程等攻击。不过好消息是，大多数攻击的处理，现在都是交由服务提供商来应付的。所以，我们不再需要处理密码管理、反自动化和密码恢复流程。换句话说，任何诸如此类的攻击活动，都将遭遇经验丰富、装备精良的基础设施供应商的顽强抵抗。
现在，我们唯一要做的事情，就是确保我们的资源配置的正确性，具有合适的身份验证和访问控制机制。而且，这些机制可以通过云基础设施提供的身份管理服务来轻松实现，这些服务包括AWS Cognito、Azure Ad、Google Firebase或Auth0，等等。只要面向外部的资源的任何一部分没有采取适当的身份验证控制的话，都可能导致我们的无服务器应用程序出现重大安全隐患。 内容来自无奈安全网
那么，难道大家真的可以高枕无忧，无所事事的等着俺下一篇文章的到来吗？绝非如此！如果内部函数不是由最终用户的请求（或者任何类型的事件）触发的，而是由应用程序的整个流程中的某个位置的某个资源绕过应用程序身份验证而直接触发的，那么事情就会变得更加复杂。这种身份验证的失败通常是身份验证和访问控制设计不佳的后果。
下面，假设有一个非常简单的无服务器场景，具体如下所示:
1.经过身份验证的用户发送了一个API请求，从而触发了一组内部流程（见蓝色区域）
2.该流程涉及到用户上传的文件（例如图像），并且该文件是存储在云存储器中的。
3.作为典型的无服务器流程，当文件上传到云存储时，它会触发另一个处理该文件的函数。
4.但是，云存储是开放的，并不需要任何身份验证。
内容来自无奈安全网
5.恶意用户可以文件直接上传到云存储，触发内部函数，因此，攻击者可以借此顺利绕过身份验证。
结果呢？上传的是另一个文件。这里最大的(安全)问题是什么？为了理解这个问题的影响，首先需要搞清楚我们刚刚绕过的那个流程，为此，我们需要从整体着眼。
例如，假设有一个应用程序会根据用户通过指定的移动应用上传的图像来完成画布的打印操作。该应用程序的登录流程如下所示：
A.用户注册/登录应用程序，并选择所需的产品。
B.完成上述操作后，用户会被重定向到结帐流程，在那里，他们需要填写相应的发货和帐单接收地址。
C.当计费信息通过审核后，会向用户发送一个指向云存储的签名链接，这样，他们就可以上传图像来进行打印了。
D.之后，用户上传所需的文件。为了增加安全性，应用程序会验证文件的类型，以确保仅能将图像上传到存储空间。
E.完成上传后，用户将被重定向到主页，并发送一封包含订单详细信息的电子邮件。
F.此外，文件上传时，还会触发一个函数来处理打印事项。 www.wnhack.com
G.处理完成后，系统将向用户发送确认电子邮件。
正如我们已经提到的，云存储没有配置正确的身份验证机制，所以，任何用户都可以直接将文件上传到云存储中。
这使得某些攻击成为可能。首先，也可能是最明显的一点，攻击者可以利用这一点来操纵应用程序执行流程，在填写收货信息后就能够立即触发图像处理函数，根本无需提供计费信息(即，绕过了上面列表中的步骤C )。他们是如何做到的呢？如果存储对其具有开放的写访问权限，攻击者可以直接利用aws cli来实现这一攻击。
本文来自无奈人生安全网