Firebase实时数据库的这些默认安全规则是什么意思? [英] What do these default security rules for the Firebase Realtime Database mean?

问题描述

我在Firebase上创建了一个新项目，并在其中创建了一个实时数据库.当被问到数据库的安全规则时，我选择了以测试模式启动.

现在，我在Firebase控制台中数据库的安全规则显示为:

  {规则":{" .read" ;:"现在<1622790000000&;//2021-6-4" .write" ;:"现在<1622790000000&;//2021-6-4}} 

这些规则是什么意思?以及如何更改它们以使其更安全?

解决方案

这些默认的测试模式规则是一个简单的综合功能，它使世界上的每个人都可以在给定日期之前对数据库进行读取和写入.

让我们分解规则以了解其工作原理:

1. 规则" 下的.read" 和.write" 节点确定哪些人可以阅读/将数据写入整个数据库.

2. now 变量设置为服务器上的当前时间.此值以自纪元以来的毫秒数为单位，该值也是在Firebase中存储时间戳的建议值

3. 规则中的 1622790000000 值是将来某个时间点的时间戳.让我们看一下该值在更易读的日期格式中的含义:

     console.log(新日期(1622790000000)) 

   " 2021-06-04T07:00:00.000Z"

因此，任何人都可以在2021年6月4日之前读取并写入我们数据库中的所有数据，在那之后，没有人可以使用客户端SDK来访问数据了. Firebase Admin SDK 完全绕开了这些规则，因此它们不受影响.

---

我可以延长时间段吗?

您可能已经从Firebase收到了这样的消息:

您选择开始以测试模式进行开发，这将使您的实时数据库实例完全对Internet开放.由于此选择使您的应用容易受到攻击者的攻击，因此您将数据库安全规则配置为在开始的30天后停止允许请求.在5天内，所有对您的实时数据库实例的客户端请求都将被拒绝.

此消息表示，由于安全规则中的时间戳记，对您的数据的访问即将到期.

将测试模式扩展到另一个截止日期实际上很容易.您需要做的就是更改 1622790000000 的值.例如，要将其扩展到7月4日，我可以将值设置为 1625382000000 .

要确定要使用的值，我运行了这个很小的JavaScript代码段:

  console.log(new Date("2021-07-04T07:00:00.000Z").getTime())

这里还有另一个工具来计算这些值.

通过使用 1625382000000 ，我们将测试模式延长了一个月，每个人都可以读/写整个数据库，直到2021年7月4日为止.

---

如何更好地保护数据?

在某个时候，您应该想出一种更好的方法来保护您的(用户)数据，而不仅仅是在特定日期之前打开它.通常，我在启动项目时会这样做，但是稍后再启动它也可以.

重要的是，您应对待服务器端安全性规则，使其与应用程序的客户端源代码相同.

我一齐开发我的代码和规则.所以:

1. 我从完全关闭的数据库开始，因为还没有代码需要访问任何数据.

2. 我将一些数据手动添加到数据库，并编写代码以读取它.在这一点上，我编写了仅允许对该特定数据进行读取访问的安全规则.因此它可能是.read":true ，但是在我的JSON结构中会更深.即使是这样简单的规则也已经阻止了许多不良行为者.

3. 我第一次希望应用程序写入到数据库也是在添加身份验证时.通常，我从匿名身份验证开始，因为它不需要我输入任何凭据.

   然后，在我的安全规则中包括硬编码的UID，以确保只有我可以写数据.在添加适当的数据所有权之后，您经常会在我的规则中仍然找到此顶级.write":"auth.uid ==='hardcodedUidOfPufsAnonymousUser'" ./p>

   使用Firestore时，有时会按照以下说明进行改进:

当我编写代码时，这需要更新我的安全规则，这会减慢我编写代码的速度，但是无论如何我都会很乐意这样做.在每一步都确保数据库中数据的安全，这使我可以放心地使人们访问应用程序/数据库.我建议您也这样做.

有关更多信息，我建议阅读:

• 安全规则上的Firebase文档，其中包含以下常见用例的示例:
• 仅限内容所有者访问
• 公共读取，私有写入权限
• 基于属性和角色的访问
• 所有经过身份验证的用户可以读取/写入所有数据

I've created a new project on Firebase, and created a Realtime Database in there. When asked about the security rules for my database, I selected to Start in test mode.

Now the security rules of my database in the Firebase console show up as:

{
  "rules": {
    ".read": "now < 1622790000000",  // 2021-6-4
    ".write": "now < 1622790000000",  // 2021-6-4
  }
}

What do these rules mean? And how can I change them to be more secure?

解决方案

These default test mode rules are a simple catch-all that allows everyone in the world to read from and write to your database until a given date.

Let's break the rules down to see exactly how they work:

1. The ".read" and ".write" nodes immediately under "rules" determine who can read/write the data in the entire database.

2. The now variable is automatically set by Firebase to be the current time on the server. This value is in milliseconds since the epoch, which is the recommended value to also store timestamps in Firebase.

3. The 1622790000000 value in the rules is the timestamp of some point in the future. Let's see what this value is in a more readable date format:

      console.log(new Date(1622790000000))
   
     

   "2021-06-04T07:00:00.000Z"

So anyone can read of write all data in our database until June 4th, 2021. After that date nobody can access the data anymore with the client-side SDKs. The Firebase Admin SDKs bypass these rules altogether, so they are not affected.

---

Can I extend the time period?

You may have gotten a message like this from Firebase:

You chose to start developing in Test Mode, which leaves your Realtime Database instance completely open to the Internet. Because this choice makes your app vulnerable to attackers, your database security rules were configured to stop allowing requests after the first 30 days. In 5 day(s), all client requests to your Realtime Database instance will be denied.

This message means that access to your data is about to expire, due to timestamp that is in your security rules.

It's actually pretty easy to extend the test mode to another deadline. All you need to do is change that 1622790000000 value. For example, for extend it to July 4th, I can set the value to 1625382000000.

To determine the value to use, I run this tiny JavaScript snippet:

   console.log(new Date("2021-07-04T07:00:00.000Z").getTime())

Here's another tool to calculate these values.

By using 1625382000000 we've extended test mode for a month and everyone can read/write the entire database until July 4, 2021.

---

How can I better protect the data?

At some point you should come up with a better way to protect your (user's) data than just opening it until a specific date. I typically do this right when I start a project, but it's also fine if you start it a bit later.

The important thing is that you should treat the server-side security rules the same as the client-side source code of your app.

I develop my code and rules in tandem. So:

1. I start with a fully closed off database, since there is no code yet that needs access to any data.

2. I add some data manually to the database, and write code to read it. At this point, I write security rules that only allow read-access to that specific data. So it may be ".read": true, but it'll be much deeper in my JSON structure. Even such simple rules will already block many bad actors.

3. The first time I want the app to write to the database is also when I add authentication. Typically I start with anonymous auth, since it does not require me to enter any credentials.

   I then include the hard-coded UID in my security rules, to ensure only I can write data. You'll often still find this top-level ".write": "auth.uid === 'hardcodedUidOfPufsAnonymousUser'" in my rules much later, after I added proper data ownership.

   When using Firestore I sometimes evolve that as explained here: User conflict when using same Auth method for Admin and Normal users | Firebase Auth

4. At any point when I add (typically lists of) data, I think through who "owns" this data, and who can read it. I then expand my rules to allow exactly that access, and nothing more.

This need to update my security rules as I write code slows down the pace at which I code, but I'll gladly do it anyway. Keeping the data in my database secure at every step, allows me to give people access to the app/database with confidence. I recommend you do the same.

For more information, I recommend reading:

• The Firebase documentation on security rules, which contains examples of these common use-cases:
• Content-owner only access
• Public read, private write access
• Attribute and role based access
• All authenticated users can read/write all datsa

这篇关于Firebase实时数据库的这些默认安全规则是什么意思?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！