【问题标题】:Ok to pass IDs in query string?可以在查询字符串中传递 ID 吗?
【发布时间】:2019-04-03 01:39:10
【问题描述】:

可以在查询字符串中传递 ID 吗?例如:

example.com/viewperson.aspx?personid=22d62e18-2383-42ca-ba6d-a535355b98bb

对于 Intranet 站点,这是否会发生变化(风险降低)?

如果是公共站点,假设任何人都可以访问(肩部服务、浏览器日志记录等).. 即使我们使用 SSL,我仍然假设“在那里”。显然,将应用安全性来禁止未经身份验证的用户查看页面。但仍有风险?

使用查询字符串的另一个好处是为您想要回叫的一些人(例如本例中的人)添加书签,而无需穿过前门并回头看。 永远不会传递任何有意义的东西,但也许一个 ID 足够有意义而不会传递?

当然,另一种选择是 cookie 或会话变量。

【问题讨论】:

  • 查询字符串 id 不正确,可以吗?
  • 使用查询字符串可以节省用户搜索该用户或分享的时间,个人而言,我更喜欢使用查询字符串而不是会话
  • @User2012384,实际上是这样。这个问题太宽泛和/或基于意见。没有正确或错误的答案,因为它可能取决于我们不知道的 OP 的一组特定要求。
  • 乐观回答:可以使用加密,因为这是一个 Intranet 站点。悲观的回答:不。简而言之:基于意见。

标签: asp.net query-string


【解决方案1】:

假设这些是您想要保护的资源,只要通过 id 对资源的请求都经过身份验证和授权,则不会有风险。这意味着您应该验证请求来自已登录用户,并且该用户有权访问该资源。

所以如果我属于公司 5,我应该无法打开 /companies/4。

否则没有问题,也没有我知道的替代方法。 (我的意思是你必须以某种方式提供一个标识符)

【讨论】:

  • “没有替代方法”你读过这个问题吗?它实际上提到了其中两个。
  • @mason 我的意思是除了提供标识符之外别无选择。如果您不识别资源,则无法请求资源。虽然操作人员特别询问查询字符串,但他的担忧似乎是暴露 id/允许 id 请求资源时的安全风险。我要说的是没有办法那样做。
  • 当然有。您只是不将其公开给客户。只要您可以将每个客户端绑定到一个单独的会话,您就可以在服务器端存储这种信息。它不会带来良好的用户体验,但绝对可行。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-02-07
  • 2012-05-21
  • 1970-01-01
  • 1970-01-01
  • 2015-11-27
  • 2019-11-18
相关资源
最近更新 更多