晦涩难懂的Firebase存储安全性 [英] Firebase Storage security through obscurity

问题描述

如此处所述，在具有包含私有文件的组的特定情况下，似乎确实没有不使用用户声明来使用存储安全规则的好的"解决方案.虽然在该线程中有一些变通办法，但是对于我的情况来说并不是很好的解决方案.

As mentioned here, in the specific scenario of having Groups with private files, it looks like there is really no "good" solution to use Storage Security Rules without using User Claims. There are some workarounds in that thread though, but aren't good solutions for my case.

所以我想知道，如果我将UUID作为后缀添加到文件路径中(目前我为实现唯一性，是e.g. groups/{groupId}/images/{imageId}/imageName-{UUID}.png)，它是否可以作为一种通过默默无闻的安全性方法? (很难猜测，制作一个私有"文件).

So I was wondering, if I add an UUID as post-fix to the file paths (which I currently do for uniqueness, e.g. groups/{groupId}/images/{imageId}/imageName-{UUID}.png), could it work as a way of security through obscurity? (it would be very hard to brute-guess, making sort of a "private" file).

我知道这并不理想，但至少暂时是这样，直到Firebase针对这种情况实施更好的解决方案，并能够在晚上睡得更好:P

I know it's not ideal, but at least it's something for the time being until Firebase implements a better solution for this scenario, and be able to sleep better at night :P

我的想法是设置类似以下内容的

My idea is to set something like:

• list:不允许(给出晦涩感")
• get，create:仅身份验证用户
• update，delete:不允许(仅对于Admin SDK)

• list: don't allow (to give "obscurity")
• get, create: only auth users
• update, delete: don't allow (only with the Admin SDK)

我的想法有意义吗?还是我错过了什么?

Does my idea make sense? Or am I missing something?

推荐答案

要求客户端知道秘密字符串是通过默默无闻的安全性，是的.

Requiring a client to know a secret string is security through obscurity, yes.

如果您允许创建访问，并希望客户端应用程序生成UUID，则这似乎是其自身的安全性(或数据完整性)问题，因为客户端实际上没有义务遵循任何命名约定，并且不可能写出强制执行的规则.

If you're allowing create access, and expecting the client app to generate the UUID, that seems like its own security (or data integrity) problem, since the client is not actually obliged to do follow any naming conventions, and it's not possible to write a rule to enforce that.

您可以通过首先调用HTTP函数，让该函数创建文件(空)，并返回创建的路径，来强制客户端创建对象.然后，客户端可以使用返回的路径将实际内容上传到其顶部.

You could force the client to create the object by first calling an HTTP function, having the function create the file (empty), returning the path that was created. Then the client can upload the actual content on top of it using the returned path.

您可以改写一个存储触发器，以确保客户端在事发后的路径中写了安全"的内容.但是最好的安全性永远不会相信客户端会做正确的事.

You could instead write a Storage trigger to make sure the client wrote something "secure" in the path after the fact. But the best security never trusts the client will ever do the right thing.

这篇关于晦涩难懂的Firebase存储安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！