攻击Firebase目标：高级漏洞利用指南
什么是Google Firebase？
Google Firebase是Google拥有的综合性应用开发平台，提供后端即服务功能。它允许开发人员构建交互式Web和移动应用程序，而无需管理服务器基础设施。服务包括身份验证、存储分析、应用程序托管等。
本文将重点关注两项服务：
- Firebase Firestore：用于实时存储和同步应用程序数据的NoSQL文档数据库
- Firebase Storage：用于存储和提供用户生成内容（如图像、视频和文件）的云存储服务
两项服务都提供内置的安全访问控制规则，我们将深入探讨这些规则。
Firebase安全规则
Firebase安全规则是一种声明式配置语言，用于定义谁可以访问Firebase资源以及在什么条件下访问。它们充当Firebase服务的主要安全机制，本质上作为服务器端防火墙，在允许或拒绝对数据的访问之前评估每个请求。
例如，在Firebase Firestore中，安全规则确定哪些用户可以读取、写入、更新或删除NoSQL数据库中的文档和集合。对于Firebase Storage，安全规则具有类似的保护功能，但侧重于文件操作而非数据库操作。它们控制谁可以上传、下载、修改或删除存储桶中的文件。
这种服务器端强制执行至关重要，因为仅依赖客户端验证或API级检查从根本上是不安全的。攻击者可以完全绕过API级检查，直接向Firebase的REST API发送请求，或使用Firebase SDK与后端服务交互。
发现和识别Firebase目标
要正确识别与目标关联的所有Firebase项目，我们需要结合多种发现方法。一些开发人员使用反向代理来避免从客户端直接连接到Firebase REST API。
检查HTTP请求
识别目标中Firebase的最直接方法是通过检查传出的HTTP请求。在某些情况下，您会遇到使用Firebase服务但未在客户端和Firebase REST API之间部署服务器的目标。
在这种情况下，您可以简单地打开开发者工具下的网络选项卡或您选择的代理拦截器，检查对*.firebaseio.com和.firebaseapp.com的任何HTTP请求。此方法还将允许我们枚举可能的REST API端点，这是我们进行访问控制测试时的关键步骤。
检查JavaScript文件
JavaScript文件通常包含Firebase配置数据，包括项目ID、数据库URL（指向*.firebaseio.com）、存储桶（指向firebasestorage.app）等。当我们想要与Firebase的REST API通信以测试缺失的访问控制时，这些数据至关重要。
Google和GitHub搜索
Firebase Firestore和Storage都提供REST API，您可以通过这些API执行各种数据操作。这些API托管在相应的firebaseio.com和firebasestorage.app域下。
通过简单的Google或GitHub代码搜索，我们可以轻松检查目标是否有任何我们可以测试的活跃Firebase项目：
|
|
或：
|
|
测试缺失的访问控制
正如本文前面所述，Firebase Firestore和Storage都依赖Firebase安全规则来验证适当的访问控制。它们允许开发人员以类似JavaScript的编程语言定义谁可以在什么条件下访问某些Firebase资源。当这些规则缺失或配置不当时，可能允许我们读取、创建或删除比预期更多的数据。
值得注意的是，在测试缺失的访问控制时，您必须直接针对Firebase的REST API执行测试。此外，由于Firebase规则的执行方式（默认拒绝），我们需要在有凭证和无凭证的情况下测试访问控制。实际上，这意味着我们需要以匿名导航器（无凭证）和经过身份验证的用户身份测试访问。
由于Firebase安全规则是细粒度的，允许开发人员为每个资源指定安全条件，因此我们还必须确保分别测试所有端点。
测试缺失的读取访问控制
让我们从一个过于宽松的Firebase安全规则的基本示例开始。您能发现以下规则中的问题吗？
在上面的代码片段中，我们可以看到默认情况下所有访问都被限制。但是，对/contact-form-data端点的保护不足，允许任何人读取包含敏感联系详情的联系表单查询。
这种简单的疏忽可能源于逻辑错误，开发人员可能认为页面访问者需要创建、读取、更新和删除访问权限才能提交联系查询表单。
在实践中，我们可以访问以下端点之一并读取所有数据：
|
|
测试缺失的创建和写入访问控制
Firebase Firestore和Storage支持4种数据操作：创建、读取、更新和删除。假设我们要测试目标的"创建"方法的缺失访问控制，我们需要向Firebase的REST API制作POST请求。
让我们看一个例子：
在上面的Firebase规则配置中，我们可以发现3个问题：
- /admin-mgmt/products端点仅执行身份验证检查（无授权验证）
- /admin-mgmt/discount-codes端点允许读取、创建和删除访问，如果身份验证对象中包含admin或maintainer用户角色
- /users/profile端点在插入前不执行任何数据验证，允许我们作为经过身份验证的用户分配或添加任意用户角色
第一个缺陷允许我们作为任何经过身份验证的用户创建新产品。复制以下HTTP请求实际上将创建一个新产品，该产品将在目标网站的前端可见。
我们还可以从Firebase安全规则配置中推断出/user/profile端点不执行任何类型的数据验证。这可能意味着开发人员有一个执行所有数据验证的API，但这不被推荐，因为我们可以通过直接向Firebase REST API发送请求轻松绕过所有验证。
结合/admin-mgmt/discount-codes，我们基本上可以添加在结账页面上有效的折扣代码。
请求1：更新我们的个人资料以包含必要的用户角色 请求2：添加新的折扣代码
测试缺失的删除访问控制
让我们介绍另一个例子。以下Firebase安全规则旨在帮助用户轻松添加和删除他们的个人资料图片。
在此配置中，我们可以看到所有权验证存在缺陷，任何在文件上传期间操纵metadata.userId的人都可以在没有适当授权的情况下删除此资源。在这种情况下，开发人员可能需要在允许任何人上传或更改其个人资料图片之前引入适当的输入验证。
测试CORS配置错误
跨源资源共享在两个Firebase服务上都受支持。Firebase Firestore允许任何源连接到REST API，这是预期的。然而，Firebase Storage使用一组规则，开发人员需要在特殊配置文件中声明这些规则。
当这些规则过于宽松时，例如在开发期间，任何不需要的源实际上都将被允许向存储桶发出请求。这可能会引入潜在的安全缺陷，可能进一步被武器化为更高严重性的问题。
结论
您可能已经遇到过积极使用Firebase Firestore/Storage的目标，甚至可能遇到过配置错误的目标，如果您之前忽略了它们，我们希望本文能够揭示这两项服务中最常见的安全配置错误。
所以，您刚刚了解了Firebase Firestore/Storage中的安全配置错误的新知识…现在是时候将您的技能付诸实践了！您可以通过在易受攻击的实验室中练习开始，或者浏览我们在Intigriti上的70多个公共漏洞赏金计划，谁知道呢，也许在您下次提交时获得赏金！