当开发人员无法对支持其移动应用程序的数据库或云实例执行身份验证时，这里会发生一种最简单且最具破坏性的安全事件。这种事件已经在未受保护的Amazon S3存储桶发生多次，导致敏感数据遭暴露，例如Booz Allen Hamilton、Verizon和五角大楼遭遇的泄漏事件。

移动应用安全公司Appthority公司（现在属于赛门铁克公司）的研究表明，这种问题并不仅限于错误配置的Amazon基础设施。该报告还详细介绍了大量遭暴露的谷歌Firebase数据库，这些数据库用于支持移动应用并包含详细用户信息。

Appthority公司共发现了2300个不安全的Firebase实例，总共暴露了超过1亿个用户记录。这包括高度敏感的数据，例如个人身份信息、健康记录和260万个明文密码。如果这些数据被黑客获取，对受影响的公司来说将非常具有破坏性，他们将面临声誉受损和潜在的监管罚款。

不安全的Firebase和AWS之间的区别

Amazon S3存储桶暴露的数据与这些不安全的Firebase实例之间的主要区别在于，在默认情况下Amazon是安全的，数据曝光是源于意外错误配置，而Firebase在首次安装时就是不安全的，而且，它需要开发人员保护单个表和行。

尽管这并不复杂，并且，谷歌提供了有关如何安全配置Firebase的详细文档，但事实表明开发人员不一定接受过安全培训，或者没有在开发生命周期中没有时间部署正确安全控制。在大多数开发中都存在这种问题，而不仅仅是移动应用程序。但是，在移动应用程序的情况下，这更容易导致敏感数据暴露，因为开发人员使用的是基于云的基础架构。

未受保护的数据很容易被黑客发现。Shodanthat等工具可索引整个互联网，并允许用户搜索特定的关键术语，让任何知道正确搜索术语的人可识别暴露的实例。由于数据暴露给所有人而不需要对数据库进行身份验证，任何瞄准此类漏洞的黑客都可以访问数据，而无需太多技术知识。

这些不安全的Firebase数据库表明，即使在当前网络安全意识提高的时代，简单的错误也可能暴露敏感数据。虽然我们不断发现新的复杂漏洞，但这些漏洞在现实世界中通常无法轻易被利用，因为这需要大量的工作或技术知识。

但是，不安全的Firebase实例等漏洞却很容易被利用，因此更有可能导致受影响企业泄漏数据。这表明企业需要投资于安全开发技能，并在开发生命周期中为开发人员留出时间以确保在数据暴露之前识别和修复这些类型的漏洞，这可最大限度地降低意外数据泄露的风险。