使用firebaseSimpleLogin的Firebase用户帐户安全性

Question

我正在努力寻找最好的方法来为我们的应用程序设计安全，使用防火墙

基本问题

我们希望用户的数据是安全的。我们不希望恶意代理能够访问Firebase db上其他用户的私有数据。似乎应该有一个通过firebaseSimpleLogin来解决这个问题的解决方案，但是尽管浏览了文档，我们还没有看到一个。

问题的特殊性

• 我们提供一个带有用户帐户的应用程序，这些用户拥有私有数据。
• 用户只应该能够读取：
  • 他们自己的数据
  • 与所有用户相关的应用程序范围的数据，例如，所有用户在最初创建帐户时都会得到一个模板，其原始副本在fb db上。
  • 另一个用户的一部分数据，如果另一个用户明确决定与他们共享数据，例如他们制作的游戏，他们希望另一个用户拥有

​

• 现在，用户使用FirebaseSimpleLogin登录。这是问题，因为任何恶意用户都可以合法地创建自己的帐户，并使用其帐户的电子邮件和密码使用恶意脚本登录，并访问db。

我们考虑过的解决方案

1.存储user_secret以确保用户有合法的访问权限

• 在回答如何设置Firebase安全规则以仅接受来自iOS应用程序的连接 的第二个方法的启发下
  • 该结构看起来类似安全->user_security->关联的_user或安全性->user->{all_valid_user_secrets}
  • 安全规则：".read"：.read

​

• 我们可以为每个用户存储多个用户密钥，允许从多个经验证的来源(iOS应用程序、web应用程序等)访问。

问题与#1

• 如何限制对安全子级的读写访问？
  • 服务器不存在SimpleLogin
  • 我们不希望该信息可见，因为恶意用户可以从技术上读取该信息以查找有关他/她自己帐户的信息，然后使用该信息来浏览db的其余部分。

​

• 与问题语句中的问题相同:用户可以合法地生成帐户，然后使用这些凭据获得对db的恶意访问。

2.暂时储存用户机密

• 用户启动登录
• 节点服务器生成密码，将其存储在Firebase中受限制的安全子节点中(服务器将能够这样做，因为Firebase秘密允许完全访问)
• 我们使用firebase SimpleLogin授权防火墙客户端，就像我们以前一样
• 用户与应用程序交互。防火墙安全规则仅允许在节点服务器写入的安全子节点存在时进行读写访问。
• 用户启动注销/崩溃/关闭应用程序
• 节点服务器从受限制的安全子节点删除密码。
• 不授权Firebase ref，因为我们已经
• 完成

#2的问题--这个方法的问题是用户在登录时容易受到攻击，因为他们的安全信息是存在的。

3.内置在Firebase安全规则中的使用

• 我们希望有一个内置的防火墙解决方案，但还没有找到一个解决上述问题的解决方案。如果你能指给我们看的话那就太棒了。

我们希望有人能帮助阐明这里最好的方法，或者使用我们的想法或另一条路线。非常感谢你的帮助。

Answer 1

实际上，您已经要求有人为您的应用程序编写完整的安全架构。在尝试将安全规则应用于这样复杂的结构之前，最好彻底了解它们。从头到尾对文档的良好研究将为您提供一个功能齐全的解决方案。

让我们只关注似乎是核心问题的问题，即您不确定如何使用只使用客户端的解决方案安全地进行邀请工作。(考虑到能够创建自己的令牌所提供的额外火力，node.js解决方案也应该是显而易见的)我将在这里做很多假设；只要将这些想法应用到您认为合适的当前用例中即可。

A数据结构：

/invites/$game_id/$uuid/true  (a place to store invited users)
/accepted_invites/$gameid/$userid/$uuid/true (a place to store accepted invites)
/games/$game_id (the place we want to invite users into)
/users/$user_id (a place where we put profiles for existing users)

1)当新用户在应用程序中创建帐户时，将其配置文件写入/users。安全用户/如下：

"users": {
   "$userid": {
      ".write": "auth.uid === $userid"
   }
}

2)若要邀请用户，请创建一个表示不可猜测的id的uuid，并将其存储在邀请/$game_id中。请注意，没有人应该能够读取这条路径。

"invites": {
   "$game_id": {
     "$invite_id": {
        // I can only create an invite for groups I'm a member of
        ".write": "root.child('games/'+$game_id+'/members/'+auth.uid).exists()",
        ".validate": "newData.val() === true"
     }
   }
}

3)要加入游戏，用户必须首先接受访问令牌，这证明他们知道令牌(因为他们无法读取邀请路径)并将令牌链接到他们的帐户id。此条目的值是invite的uuid。

"accepted_invites": {
   "$game_id": {
      "$user_id": {
         ".write": "auth.uid === $user_id",
         ".validate": "root.child('invites/'+$game_id+'/'+newData.val()).exists()"
      }
   }
} 

4)如果用户已经接受了邀请，或者最初创建时还没有成员，用户就可以将自己写入游戏中( !data.parent().exists()规则)。

"game": {
   "$gid": {
      "members": {
        "$uid": {
           ".write": "auth.uid === $uid",
           // I can join a group if a) I'm creating it or b) I have accepted an invite
           ".validate": "!data.parent().exists() || root.child('accepted_invites/'+$gid+'/'+auth.uid).exists()"
        }
      }
   }
}

客户端解决方案的另一个改进是为邀请分配一个优先级，该优先级表示这些优先级过期的时间，然后在安全规则中引用该优先级来控制令牌有效的时间。

Answer 2

在@Kato的建议的帮助下，我最终选择了想法#3。到目前为止，使用内置规则和设计模式的解决方案可以避免需要第三方auth服务器。模式的一些示例如下：

 "game_detail" : {
      "$game_detail" : {
        ".read" : "data.child('owner').val() === auth.email || root.child('admins').val() === auth.email",
        ".write" : "newData.child('owner').val() === auth.email || root.child('admins').val() === auth.email"        
      }
    },

然后，使#3成为可能的附加密钥是，除了有一个安全规则模式之外，我们还创建了一个通用管理凭据，当匿名用户登录访问DB的一个子集并执行必要的跨帐户操作时，可以使用该证书。

谢谢大家的意见。