Question

我使用数据存储区中实体的Key值作为URL中用于提取记录的唯一标识符：

http://mysite.appspot.com/myaction/1x7s3fgdlbnRlcklkcicLAbcXc2VyQWNjb3VudCIFYW9uZ

这不是一个非常有吸引力的解决方案，它也不是SEO友好的，但它是我发现在App Engine / Java中唯一识别实体的最简单方法。

但我主要担心的是，是否存在与显示实体的唯一Key值相关的安全问题？

Answer 1

编码密钥包含您的应用ID，名称空间（如果有），实体类名称以及密钥名称或ID。这里有两个可能的问题：信息的披露（可能没有问题），以及您接受编码密钥的事实。如果您没有检查传入的密钥指定的实体是否属于正确的类型，并且用户应该有权访问它，那么他们可以传入自己的密钥以使您披露不应该泄露的信息

然而，几乎普遍地，您已经知道要获取的实体的类型名称，因此更好的想法是仅使用密钥的密钥名称或ID，并根据需要构造完整密钥。这也使得更清晰的URL。

Answer 2

安全问题是潜在的黑客知道有关您的数据库的一些内容，无论多么小。

如果数据库的某些部分遭到入侵，则实体ID可能对黑客有用。

和我一样，我不喜欢显示数据库ID，但如果你正确保护你的应用程序，因为知道实体id不会有用，所以不值得担心。

Answer 3

你确定这是一个真正的钥匙吗？它看起来不像一个（un-base64'd数据通常包括你的app标识符）。

documentation涵盖了它：

注意：字符串编码的密钥可以转换回原始密钥数据。这使得在知道其他键时很容易猜到。虽然字符串编码的键值可以安全地包含在URL中，但只有在关键可猜测性不成问题时，应用程序才应该这样做。

做这样的事情要干得多：

foo = FooModel.get_by_id(int(foo_id))

这并不能阻止攻击者猜测ID，但至少它不会让你误以为ID是“不透明的”（并且你可以轻而易举地更改ID以测试访问控制，而不是需要乱用base64-protobuf编码数据）。

Answer 4

在我看来，这不是安全问题。许多站点使用id作为站点内的标识符。密钥只是数据库表中某一行的键，您确实希望避免在表和用户帐户等方面显示有关数据库的详细信息。

在这方面，您希望禁止您的网站在发生数据库错误时将其丢弃，捕获它们并妥善处理。