论文部分内容阅读
攻击者有多种方法来攻击无服务器应用，但是本文中的这些最佳实践将有助于阻止这些攻击。
无服务器应用亦称为云函数，可执行非常具体的任务且存在时间仅为数秒钟。这使得它们在充分利用云环境和降低成本方面更加高效。
与任何新技术一样，这种新范式的安全隐患尚未得到充分探索或理解。PureSec的首席技术官兼联合创始人Ory Segal称：“许多人仍然认为无服务器是神奇的，保护代码的安全可交由他人负责，但事实远非如此。”不过，我们也许可以通过强化无服务器应用和使用安全最佳实践来降低数据泄露的概率。
如何攻击无服务器函数
当然，服务器仍然存在，但函数是抽象的且不依赖于任何一个基础设施。事实上，服务器上有函数的源代码，并且至少有一个托管的临时容器正在执行函数。这意味着应该认真考虑它们的安全性。
Segal指出，“无服务器函数只是几个简单的代码片段，当某个事件触发时云提供商将执行这些代码片段。因此与任何其他软件一样，它们也会遇到应用程序层漏洞。”
关于无服务器架构中最常见的安全风险的研究发现，GitHub上五分之一的无服务器应用存在严重的安全漏洞。不过到目前为止，还没有关于无服务器函数遭到破坏的重大攻击报告。尽管如此，安全研究社区却对此非常感兴趣，其中一些人认为有针对性的攻击正在发生，只是没有被发现而已。
Mozilla的安全工程师Andrew Krug在去年早些时候的黑帽大会上表示：“人们正在寻找无服务器函数的漏洞，特别是在开源领域，很容易就找到代码中漏洞在哪里。”
2018年7月，PureSec在其所支持的IBM Cloud Functions产品的开源无服务器计算平台Apache Openwhisk中发现了一个漏洞。该漏洞允许攻击者覆盖源代码并更改函数逻辑。为此Apache基金会还专门发布了一个补丁。
PureSec最近还演示了一种攻击。该攻击利用无服务器中的自动扩展函数将单个易受攻击的函数转变为大规模的加密货币挖掘矿场。在测试中，该攻击可使挖矿函数扩展至平台的最大并发限制。这种攻击可能会导致在账期结束时出现大量费用。由于加密货币挖矿会导致受害者消耗额外的计算资源，该报告估算这笔费用每月多达12万美元。
“最常见的攻击方法是事件数据注入。在这过程中，攻击者会注入恶意数据，然后在事件触发期间被函数使用，”PureSec的Segal说。“此类恶意数据可能会滥用应用程序层漏洞，例如SQL注入、命令注入、本地文件包含、数据泄漏等。此类攻击将操纵函数的业务逻辑。”
在2018年7月的伦敦OWASP AppSec大会上，Checkmarx的Shimi Eshkenazi和Amit Ashbel则演示了一种代码注入攻击，它可在同一应用程序中“交叉污染”函数，克服了持久性问题。在演示过程中，该团队展示了他们能够通过代码注入访问函数代码，并下载该函数代码，在对其进行修改后再通过原始病毒函数感染其他的函数。
Eshkenazi说：“你将会陷入无限循环的交叉感染中，而这将导致所有其他函数失控。摆脱这种情况的唯一方法是将所有函数恢复到原始来源。记住是所有函数，不能遗漏其中的任何一个。”
无服务器计算有哪些安全优势？
尽管可能存在风险，但无服务器函数仍拥有一些安全优势，主要在于它们是孤立的、短时的和只读的，并且通常只有很少或是没有特权升级。与其他类型的代码相比，将它们做为攻击目标具有更大的难度。与单体应用程序相比，函数通常没有什么职责和访问数据，因此直接破坏范围更小。
Checkmarx的网络安全推广官Amit Ashbel在OWASP AppSec大会上表示：“函数在它们自己的环境中运行这一事实减少了潜在的破坏，并且由于没有任何东西存储在上面，所以函数在运行后会被移动、删除和丢弃。这两个特点也都阻止了注入的东西被存储起来。如果你注入的东西（在函数结束后）被删除，那么这一函数仍然是新的和干净的。（它们）应该更加安全。”
函数由主要云提供商作为服务提供这一事实也提供了额外的安全性。虽然实际函数的编码和配置是由用户决定的，但是AWS和Azure之类的产品将负责确保底层硬件的安全性和补丁，同时函数本身也将定期更新，这些提供商的规模意味着拒绝服务攻击将更加容易被应对。
与错误配置的S3存储桶会导致许多重大数据泄漏事件一样，错误配置的无服务器应用也可能会导致出现数据泄漏等问题。“Lambda的默认值很好。这里面的问题在于流行的无服务器框架引入的默认值，它们往往会导致IAM（身份和访问管理）权限完全敞开，”Mozilla的Krug说。
如何保护无服务器函数
无服务器技术目前仍处于初期阶段，这一特点也反映在围绕着该技术的安全实践当中。Serverless.com的调查发现，调试、监控和测试是无服务器应用的最大挑战;而PureSec的调查发现，35%的企业并没有安全指南或工具以保护无服务器代码。在该研究中，有48%的企业对其无服务器应用的安全可见性的水平并不满意。当一家企业拥有50多个职能部门时，这一数字会急剧上升，这表明存在大规模安全问题。
Segal指出，“传统的应用层保护，例如Web应用防火墙和端点保护解决方案，不适用于无服务器架构，并且由于缺乏底层基础设施或网络/操作系统无法访问而无法部署。目前无服务器的安全测试方法和工具仍几乎没有。”
尽管如此，企业还是可以遵循一些最佳实践来改善其无服务器应用和函数的安全状态。以下是可以遵循的五大应用安全最佳实践：
1、在设计和开发时就考虑到安全性，并使用威胁建模来了解自己面临的风险。执行静态代码分析和渗透测试以检测漏洞。使用安全API验证事件数据输入。该安全API可以清理或验证用户输入，并将流入的HTTP / HTTPS流量扫描至无服务器应用。
2、确保身份与访问管理（IAM）的角色和权限被正确配置，以便函数只能被需要访问它们的东西访问。只授予函数提供执行任务所需的权限。如果只需要读取函数，请确保其权限是只读的。
3、尽可能不将敏感数据放入函数的源代码中。确保所有数据都已加密。同时，要确保身份验证方法是有效的，并尽可能使用FaaS提供商的东西。此外，还要进行定期评估。Checkmarx的Eshkenazi说：“如果你不在服务器上的代码中编写敏感数据，那就同样不应该在无服务器代码中编写敏感数据，因为它们可能被泄露和受到攻击。”
4、清楚如何正确开发无服務器应用。糟糕的自动扩展函数可能会拖累资源。Auth0的Webtask.io函数即服务平台（FaaS）的首席架构师Tomasz Janczuk表示，平台遭受拒绝服务攻击的情况很常见，这些攻击实际上通常是由用户错误而导致。这些例子中包括设计效率低下的函数，这些函数会试图分配大量内存，尝试将大量文件写入文件系统，或者通过无休止的循环来阻塞CPU。
5、确保对无服务器应用拥有细致入微的安全可见性和深刻的洞察力。监控非常重要，尤其是在增加函数的数量时。监视API身份验证尝试，对函数配置、权限或触发器的修改行为，以及执行超时等。“无论应用程序是传统的、容器化的，还是无服务器的，都必须不断监控整个交付堆栈的安全性，”Synopsys的Black Duck高级技术推广人员Tim Mackey说。“随着应用程序被分解至以无服务器模式部署的函数中，这些应用程序的潜在攻击面将会增加，每个函数都应被视为一个不同的可交付成果，并进行全面的安全审查。”
无服务器应用亦称为云函数，可执行非常具体的任务且存在时间仅为数秒钟。这使得它们在充分利用云环境和降低成本方面更加高效。
与任何新技术一样，这种新范式的安全隐患尚未得到充分探索或理解。PureSec的首席技术官兼联合创始人Ory Segal称：“许多人仍然认为无服务器是神奇的，保护代码的安全可交由他人负责，但事实远非如此。”不过，我们也许可以通过强化无服务器应用和使用安全最佳实践来降低数据泄露的概率。
如何攻击无服务器函数
当然，服务器仍然存在，但函数是抽象的且不依赖于任何一个基础设施。事实上，服务器上有函数的源代码，并且至少有一个托管的临时容器正在执行函数。这意味着应该认真考虑它们的安全性。
Segal指出，“无服务器函数只是几个简单的代码片段，当某个事件触发时云提供商将执行这些代码片段。因此与任何其他软件一样，它们也会遇到应用程序层漏洞。”
关于无服务器架构中最常见的安全风险的研究发现，GitHub上五分之一的无服务器应用存在严重的安全漏洞。不过到目前为止，还没有关于无服务器函数遭到破坏的重大攻击报告。尽管如此，安全研究社区却对此非常感兴趣，其中一些人认为有针对性的攻击正在发生，只是没有被发现而已。
Mozilla的安全工程师Andrew Krug在去年早些时候的黑帽大会上表示：“人们正在寻找无服务器函数的漏洞，特别是在开源领域，很容易就找到代码中漏洞在哪里。”
2018年7月，PureSec在其所支持的IBM Cloud Functions产品的开源无服务器计算平台Apache Openwhisk中发现了一个漏洞。该漏洞允许攻击者覆盖源代码并更改函数逻辑。为此Apache基金会还专门发布了一个补丁。
PureSec最近还演示了一种攻击。该攻击利用无服务器中的自动扩展函数将单个易受攻击的函数转变为大规模的加密货币挖掘矿场。在测试中，该攻击可使挖矿函数扩展至平台的最大并发限制。这种攻击可能会导致在账期结束时出现大量费用。由于加密货币挖矿会导致受害者消耗额外的计算资源，该报告估算这笔费用每月多达12万美元。
“最常见的攻击方法是事件数据注入。在这过程中，攻击者会注入恶意数据，然后在事件触发期间被函数使用，”PureSec的Segal说。“此类恶意数据可能会滥用应用程序层漏洞，例如SQL注入、命令注入、本地文件包含、数据泄漏等。此类攻击将操纵函数的业务逻辑。”
在2018年7月的伦敦OWASP AppSec大会上，Checkmarx的Shimi Eshkenazi和Amit Ashbel则演示了一种代码注入攻击，它可在同一应用程序中“交叉污染”函数，克服了持久性问题。在演示过程中，该团队展示了他们能够通过代码注入访问函数代码，并下载该函数代码，在对其进行修改后再通过原始病毒函数感染其他的函数。
Eshkenazi说：“你将会陷入无限循环的交叉感染中，而这将导致所有其他函数失控。摆脱这种情况的唯一方法是将所有函数恢复到原始来源。记住是所有函数，不能遗漏其中的任何一个。”
无服务器计算有哪些安全优势？
尽管可能存在风险，但无服务器函数仍拥有一些安全优势，主要在于它们是孤立的、短时的和只读的，并且通常只有很少或是没有特权升级。与其他类型的代码相比，将它们做为攻击目标具有更大的难度。与单体应用程序相比，函数通常没有什么职责和访问数据，因此直接破坏范围更小。
Checkmarx的网络安全推广官Amit Ashbel在OWASP AppSec大会上表示：“函数在它们自己的环境中运行这一事实减少了潜在的破坏，并且由于没有任何东西存储在上面，所以函数在运行后会被移动、删除和丢弃。这两个特点也都阻止了注入的东西被存储起来。如果你注入的东西（在函数结束后）被删除，那么这一函数仍然是新的和干净的。（它们）应该更加安全。”
函数由主要云提供商作为服务提供这一事实也提供了额外的安全性。虽然实际函数的编码和配置是由用户决定的，但是AWS和Azure之类的产品将负责确保底层硬件的安全性和补丁，同时函数本身也将定期更新，这些提供商的规模意味着拒绝服务攻击将更加容易被应对。
与错误配置的S3存储桶会导致许多重大数据泄漏事件一样，错误配置的无服务器应用也可能会导致出现数据泄漏等问题。“Lambda的默认值很好。这里面的问题在于流行的无服务器框架引入的默认值，它们往往会导致IAM（身份和访问管理）权限完全敞开，”Mozilla的Krug说。
如何保护无服务器函数
无服务器技术目前仍处于初期阶段，这一特点也反映在围绕着该技术的安全实践当中。Serverless.com的调查发现，调试、监控和测试是无服务器应用的最大挑战;而PureSec的调查发现，35%的企业并没有安全指南或工具以保护无服务器代码。在该研究中，有48%的企业对其无服务器应用的安全可见性的水平并不满意。当一家企业拥有50多个职能部门时，这一数字会急剧上升，这表明存在大规模安全问题。
Segal指出，“传统的应用层保护，例如Web应用防火墙和端点保护解决方案，不适用于无服务器架构，并且由于缺乏底层基础设施或网络/操作系统无法访问而无法部署。目前无服务器的安全测试方法和工具仍几乎没有。”
尽管如此，企业还是可以遵循一些最佳实践来改善其无服务器应用和函数的安全状态。以下是可以遵循的五大应用安全最佳实践：
1、在设计和开发时就考虑到安全性，并使用威胁建模来了解自己面临的风险。执行静态代码分析和渗透测试以检测漏洞。使用安全API验证事件数据输入。该安全API可以清理或验证用户输入，并将流入的HTTP / HTTPS流量扫描至无服务器应用。
2、确保身份与访问管理（IAM）的角色和权限被正确配置，以便函数只能被需要访问它们的东西访问。只授予函数提供执行任务所需的权限。如果只需要读取函数，请确保其权限是只读的。
3、尽可能不将敏感数据放入函数的源代码中。确保所有数据都已加密。同时，要确保身份验证方法是有效的，并尽可能使用FaaS提供商的东西。此外，还要进行定期评估。Checkmarx的Eshkenazi说：“如果你不在服务器上的代码中编写敏感数据，那就同样不应该在无服务器代码中编写敏感数据，因为它们可能被泄露和受到攻击。”
4、清楚如何正确开发无服務器应用。糟糕的自动扩展函数可能会拖累资源。Auth0的Webtask.io函数即服务平台（FaaS）的首席架构师Tomasz Janczuk表示，平台遭受拒绝服务攻击的情况很常见，这些攻击实际上通常是由用户错误而导致。这些例子中包括设计效率低下的函数，这些函数会试图分配大量内存，尝试将大量文件写入文件系统，或者通过无休止的循环来阻塞CPU。
5、确保对无服务器应用拥有细致入微的安全可见性和深刻的洞察力。监控非常重要，尤其是在增加函数的数量时。监视API身份验证尝试，对函数配置、权限或触发器的修改行为，以及执行超时等。“无论应用程序是传统的、容器化的，还是无服务器的，都必须不断监控整个交付堆栈的安全性，”Synopsys的Black Duck高级技术推广人员Tim Mackey说。“随着应用程序被分解至以无服务器模式部署的函数中，这些应用程序的潜在攻击面将会增加，每个函数都应被视为一个不同的可交付成果，并进行全面的安全审查。”