在 URL 中向用户显示 Key 值是否存在安全问题?

发布于 2024-09-17 21:11:30 字数 268 浏览 10 评论 0原文

我使用数据存储中实体的键值作为 URL 中的唯一标识符来提取记录:

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

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

不过,我主要担心的是,是否存在与显示实体的唯一键值相关的安全问题?

I am using the Key value of entities in my datastore as the unique identifier in the URL for pulling up a record:

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

This is not a very attractive solution, nor is it SEO friendly, but it's the easiest way I've found to identify an entity uniquely in App Engine/Java.

My main concern, though, is whether there is any security concern related to displaying the unique Key value for the entity?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

疑心病 2024-09-24 21:11:30

编码的密钥包含您的应用程序 ID、命名空间(如果有)、实体种类名称以及密钥名称或 ID。这里有两个可能的问题:该信息的泄露(可能没有问题),以及您接受编码密钥的事实。如果您不检查传入的密钥指定的实体是否属于正确类型,并且用户应该有权访问它,那么他们可能会传入自己的密钥,导致您泄露不应该泄露的信息。

然而,几乎普遍地,您已经知道要获取的实体的种类名称,因此更好的想法是仅使用键名称或键的 ID,并根据需要构造完整的键。这也使得 URL 更加干净。

The encoded key contains your app ID, namespace (if any), entity kind name, and key name or ID. There's two possible issues here: the disclosure of that information (probably not problematic), and the fact that you're accepting an encoded key. If you don't check that the entity specified by the key being passed in is of the correct kind, and that the user should have access to it, then they could pass in their own key to cause you to disclose information you shouldn't.

Almost universally, however, you already know the kind name of the entity you're fetching, so a much better idea is to use just the key name or ID of the key, and construct the full key on demand. This also makes for much cleaner URLs.

九公里浅绿 2024-09-24 21:11:30

安全问题是潜在的黑客对您的数据库了解一些信息,无论多么小。

如果数据库的某些部分被泄露,实体 ID 可能对黑客有用。

和您一样,我不太喜欢显示数据库 ID,但是如果您正确保护应用程序,则无需担心,因为知道实体 ID 没有用处。

The security concern is that a potential hacker knows something, however small, about your database.

If parts of your database are ever compromised the entity id could prove useful for the hacker.

Like you I don't really like displaying database IDs but IF you secure your application properly it isn't worth worrying about as knowing the entity id isn't going to be useful.

-黛色若梦 2024-09-24 21:11:30

你确定这是一把真正的钥匙吗?它看起来不像(其中之一是未经过 Base64 处理的数据通常包括您的应用程序标识符)。

不过,文档对此进行了介绍:

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

这样做要干净得多:

foo = FooModel.get_by_id(int(foo_id))

这并不能阻止攻击者猜测 ID,但至少它不会欺骗您认为 ID 是“不透明的”(并且您可以轻松更改 ID 来测试访问控制,而不是需要搞乱 base64-protobuf 编码的数据)。

Are you sure that's an actual key? It doesn't look like one (the un-base64'd data generally includes your app identifier, for one).

The documentation covers it, though:

Note: A string-encoded key can be converted back to the raw key data. This makes it easy to guess other keys when one is known. While string-encoded key values are safe to include in URLs, an application should only do so if key guessability is not an issue.

It's a lot cleaner to do something like this:

foo = FooModel.get_by_id(int(foo_id))

That doesn't stop attackers from guessing IDs, but at least it doesn't fool you into thinking that IDs are "opaque" (and you can trivially change the ID to test access control, instead of needing to mess around with base64-protobuf-encoded data).

凉月流沐 2024-09-24 21:11:30

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

在这方面,您希望禁止您的站点转储数据库错误当它们发生时,抓住它们并妥善处理。

This is not a security concern in my opinion. Lots of sites use id as identifier within the site. A key is just a key to a row in a database table, you do want to refrain from showing much detail about your database in terms of table and user accounts etc.

In this regard, you want to prohibit your site from dumping out database errors when they occur, catch them and handle nicely.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文