ios - 使用 firebaseSimpleLogin 确保 Firebase 用户帐户安全

Question

我正在努力寻找为我们使用 firebase 的应用设计安全性的最佳方法

基本问题

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

问题细节

• 我们提供带有用户帐户的应用，这些用户拥有私有(private)数据
• 用户应该只能阅读:
  • 他们自己的数据
  • 与所有用户相关的应用范围数据，例如一个所有用户都可以获得副本的模板当他们最初创建他们的帐户时，其中的原始副本在 Facebook 数据库上
  • 另一个用户的部分数据，如果其他用户已明确决定与他们分享，例如他们制作的一款游戏，他们希望其他用户拥有一份副本的
• 现在，用户登录Firebase 简单登录。这是有问题的，因为任何恶意用户可以合法地创建自己的帐户，并使用他们的帐户使用恶意脚本登录的电子邮件和密码，并访问分贝

我们考虑过的解决方案

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

• 受到对 How to setup Firebase security rules to accept connections only from an iOS App 的回答中的第二种方法的启发
  • 结构看起来像 security->user_secret->associated_user 或 security->user->{all_valid_user_secrets}
  • 安全规则:“.read”:“root.child('user_secrets/'+auth.uid).exists()”
• 我们可以为每个用户存储多个用户 key ，允许从多个经过验证的来源(iOS 应用程序、网络应用程序等)进行访问

#1 的问题

• 我们如何限制对安全 child 的写/读访问？
  • 服务器不存在 SimpleLogin
  • 我们不希望此信息可见，因为恶意用户可以从技术上读取它以查找有关他/她自己帐户的信息，然后使用它来细读数据库的其余部分
• 与问题陈述中的问题相同:用户可以合法地生成帐户，然后使用这些凭据恶意访问数据库

2。临时存储用户 secret

• 用户发起登录
• 节点服务器生成密码，将其存储在 Firebase 的受限安全子项中(服务器可以执行此操作，因为 Firebase Secret 允许完全访问)
• 我们像以前一样使用 Firebase SimpleLogin 授权 firebase 客户端
• 用户与应用互动。 Firebase 安全规则仅在节点服务器编写的安全子项存在时才允许读/写访问
• 用户发起注销/崩溃/关闭应用
• 节点服务器从受限安全子节点中删除密码
• 像我们一样取消对 Firebase ref 的授权
• 完成

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

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

• 我们希望有一个内置的 firebase 解决方案，但还没有找到解决上述问题的解决方案。如果您能为我们指出一个，那就太好了。

我们希望有人可以帮助阐明这里的最佳方法，无论是使用我们的想法还是其他途径。非常感谢您的帮助。

Answer 1

您实际上是在要求某人为您的应用编写完整的安全架构。如果您在尝试将安全规则应用到像这样的复杂结构之前彻底了解安全规则会更好。 A good study of the docs from start to end将带您走很长一段路才能获得功能齐全的解决方案。

让我们只关注似乎是核心问题的问题，即您不确定如何使用仅限客户端的解决方案使邀请安全地工作。 (考虑到能够创建我们自己的 token 所提供的额外火力，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，并将其存储在invites/$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) 要加入游戏，用户必须首先接受访问 token ，这证明他们知道 token (因为他们无法读取邀请路径)并将 token 链接到他们的帐户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()"
        }
      }
   }
}

我们客户端解决方案的另一个改进是为邀请分配一个优先级，代表它们何时过期，然后在安全规则中引用该优先级以控制 token 的有效期。