研究无服务器架构所造成的威胁，SLS-1：事件注入

这篇文章讨论了可能是变化最大、也是最令人担忧的一种攻击技术——注入攻击。

SQL注入、OS命令注入、代码注入等攻击手法，常常是黑客们的最爱，因为它们通常会无往不胜。但是，站在防御者这一边，情况就大为不同了。这些攻击方法总是被认为是头号风险，并且通常会尽一切努力来防御它们。不过，虽然单体应用程序的发展至少已经有20个年头了，我们仍然经常听说其中又爆出巨大的安全漏洞，使得攻击者能够插入恶意代码，随之而来的，便是正式的致歉新闻稿，以及客户在相关页面上留下的几十万条的抱怨留言。由此看来，我们一直都没有“学乖”。

实际上，在以前的环境中，防御注入攻击要更容易一些。在采用无服务器架构之前，注入攻击基本上（现在仍然）都具有相同的攻击套路。它们主要是应用程序对于来自网络的不可信来源的输入内容处理不当所致。这意味着编写安全代码时，我们不能再依赖于在网络边界上实施的安全控制了。这是真的：我们无法在收到的电子邮件与其触发的功能之间设置防火墙。对于我们的代码来说，我们既无法知道其运行当下的情况，也不知道之前发生了什么，更不知道它将走向何方。也就是说，它们只是一堆代码而已。如果函数的代码容易受到某种类型的注入攻击，在无服务器架构的世界中，它通常被称为事件注入漏洞。

好了，让我们看看它到底是什么样子吧。现在，请考虑以下简单的无服务器架构场景:

1.用户与Slack聊天机器人频道进行交互

2.用户消息被发送到Slack后端

3.Slack后端被配置为向公司API网关发送消息

4.该请求通过事件触发一组Lambda函数

5.其中一个lambda函数用于将消息写入动态数据库表

6.然后，向Slack后端发送自动回复

7.这样，就会把请求作为Slack机器人发布到指定的频道上

在我们的示例中，事件注入攻击是可能的，因为通过Slack事件触发的Lambda函数容易受到代码注入漏洞的影响。在AWS上，大多数函数都在运行动态语言(如Python或NodeJS语言)，这可能导致运行完全不同的代码，而非原始代码——RCE风格的攻击。如您所见，上面的代码(在野外经常被发现)使用了eval()函数来解析事件中的JSON数据，我们都知道(我们真的知道吗？)，这本来是应该极力避免的。然而，这仅仅是一个例子，任何含有其他类型安全漏洞的代码都面临着被攻击的风险。

在验证漏洞（任何sleep或curl技术都可以）之后，攻击者就可以着手攻击这个无服务器环境了。当然，环境中的大多数文件都不会引起攻击者的兴趣。因此，我们最终可以忘记/etc/passwd示例。实际上，这些文件属于环境容器，并且大多数在应用程序中没有起到重要的作用。但是，它们还可以提供其他方面的线索。例如，通过访问环境，攻击者可以通过注入以下payload来窃取完整的函数代码：

（编辑：大同站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!