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

Question

我正在尝试为使用Firebase的应用找到设计安全性的最佳方法

基本问题

我们希望我们的用户数据是安全的。 我们不希望恶意代理能够访问Firebase数据库上其他用户的私有数据。 似乎应该通过firebaseSimpleLogin解决此问题，但是尽管仔细阅读了文档，但我们还没有看到。

问题细节

• 我们提供了一个带有用户帐户的应用，这些用户拥有私人数据
• 用户应该只能阅读：
  • 他们自己的数据
  • 与所有用户相关的应用程序范围的数据，例如，所有用户最初创建其帐户时都会获得一份副本的模板，该副本的原始副本位于fb db上
  • 如果另一个用户已明确决定与他们共享数据，例如另一个用户制作的游戏，他们希望另一个用户拥有该用户的副本，
• 现在，用户使用FirebaseSimpleLogin登录。 这是有问题的，因为任何恶意用户都可以合法地创建自己的帐户，并使用其帐户的电子邮件和密码使用恶意脚本登录并访问数据库。

我们考虑过的解决方案

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

• 受第二种方法的启发，回答了如何设置Firebase安全规则以仅接受来自iOS应用的连接
  • 该结构看起来像security-> user_secret-> associated_user或security-> user-> {all_valid_user_secrets}
  • 安全规则：“ .read”：“ root.child（'user_secrets /'+ auth.uid）.exists（）”
• 我们可以为每个用户存储多个用户密钥，从而允许从多个经过验证的来源（iOS应用程序，Web应用程序等）进行访问

＃1问题

• 我们如何限制对安全子级的写入/读取访问？
  • 服务器不存在SimpleLogin
  • 我们不希望此信息可见，因为恶意用户可以从技术上阅读该信息以查找有关自己账户的信息，然后使用该信息仔细阅读数据库的其余部分
• 与问题声明中相同的问题：用户可以合法生成一个帐户，然后使用这些凭据来获得对数据库的恶意访问

2.临时存储用户密码

• 用户启动登录
• 节点服务器生成密码，并将其存储在Firebase中受限制的安全子级中（该服务器将能够执行此操作，因为Firebase Secret允许完全访问）
• 我们已经使用Firebase SimpleLogin授权Firebase客户端
• 用户与应用进行交互。 Firebase安全规则仅在存在由节点服务器编写的安全子级的情况下才允许读/写访问
• 用户启动注销/崩溃/关闭应用程序
• 节点服务器从受限制的安全子级中删除密码
• 像过去一样对Firebase参考进行授权
• 完成

＃2的问题-这种方法的问题是，用户在登录时很容易受到攻击，因为会显示其安全信息。

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

• 我们希望有一个内置的Firebase解决方案，但还没有找到能够解决上述问题的解决方案。 如果您能指出我们一个很棒的地方。

我们希望有人可以使用我们的想法或其他方法帮助阐明此处的最佳方法。 非常感谢你的帮助。

Answer 1

实际上，您已经要求有人为您的应用程序编写整个安全模式。 最好在尝试将安全规则应用到像这样的复杂结构之前彻底理解安全规则。 从头到尾对文档进行深入的研究，将带您走完整功能的解决方案的很长一段路。

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

数据结构：

/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）要邀请用户，请创建一个uuid （表示一个无法猜测的ID），并将其存储在Invitations / $ 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。 该条目的值是邀请的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。 到目前为止，使用内置规则和设计架构的解决方案使我们避免了使用第三方认证服务器。 该模式的一些示例如下：

 "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成为可能的另一个关键是，除了具有安全规则架构之外，我们还创建了通用管理凭据，匿名用户登录到数据库的子集时可以使用该通用管理凭据。执行必要的跨帐户操作。

感谢大家在这里的投入。