我使用数据存储中实体的键值作为 URL 中的唯一标识符来提取记录：
http://mysite.appspot.com/myaction/1x7s3fgdlbnRlcklkcicLAbcXc2VyQWNjb3VudCIFYW9uZ
这不是一个非常有吸引力的解决方案，也不是对 SEO 友好，但它是我发现在 App Engine/Java 中唯一标识实体的最简单方法。
不过，我主要关心的是是否存在与显示实体的唯一键值相关的安全问题？
问问题
176 次
4 回答
5
编码的密钥包含您的应用 ID、命名空间（如果有）、实体类型名称和密钥名称或 ID。这里有两个可能的问题：该信息的披露（可能没有问题），以及您接受编码密钥的事实。如果您不检查传入的密钥指定的实体类型是否正确，并且用户应该有权访问它，那么他们可能会传入他们自己的密钥，以使您泄露您不应该披露的信息.
但是，几乎普遍地，您已经知道要获取的实体的种类名称，因此更好的主意是仅使用键名或键的 ID，并按需构造完整的键。这也使得 URL 更清晰。
于 2010-09-06T18:25:41.457 回答
3
安全问题是潜在的黑客知道一些关于您的数据库的信息，无论多么少。
如果您的数据库的某些部分曾经遭到破坏，那么实体 ID 可能对黑客有用。
像您一样，我不太喜欢显示数据库 ID，但如果您正确保护应用程序，则无需担心，因为知道实体 ID 不会有用。
于 2010-09-06T16:35:10.473 回答
1
你确定那是一把真正的钥匙吗？它看起来不像一个（un-base64'd 数据通常包括您的应用标识符，例如）。
但是，文档涵盖了它：
注意：字符串编码的密钥可以转换回原始密钥数据。这使得在已知一个密钥时很容易猜测其他密钥。虽然字符串编码的键值可以安全地包含在 URL 中，但只有在键的可猜测性不是问题时，应用程序才应该这样做。
做这样的事情要干净得多：
foo = FooModel.get_by_id(int(foo_id))
这并不能阻止攻击者猜测 ID，但至少它不会让您误以为 ID 是“不透明的”（您可以简单地更改 ID 以测试访问控制，而不是需要弄乱 base64-protobuf -编码数据）。
于 2010-09-06T18:37:47.297 回答
0
在我看来，这不是安全问题。许多站点使用 id 作为站点内的标识符。键只是数据库表中一行的键，您确实希望避免在表和用户帐户等方面显示有关数据库的太多详细信息。
在这方面，您希望禁止您的站点在发生数据库错误时将其转储出来，捕获它们并妥善处理。
于 2010-09-06T16:14:41.853 回答