【问题标题】:Resources like images and securing them图像等资源并保护它们
【发布时间】:2013-05-10 15:47:05
【问题描述】:

我一直在思考这个问题,并在 Facebook 上进行了快速测试。假设您有一个类似 Facebook 的网站,并将其分解为图像和个人资料。您选择与朋友分享或不分享的图像。显然,在数据库中,如果元数据是否共享,则在元数据上应用值,与谁共享,等等。

现在假设我查看了一个特定的图像,所以我现在有一个用于该资源的 HTTPS URL(本例中的图像)。此时,无需登录或拥有任何类型的令牌即可查看资源。您有 URL,将其加载到任何浏览器中,您就会看到该资源。当然,它是在 SSL 层中提供的,它们的名称相当长、复杂,但我可以在不进行身份验证的情况下查看它。

我不禁想,这是可以做到的最好的吗?这种类型的内容能否得到保护,因此如果您有一个直接 URL,您将无法加载它?那些可能更敏感的文件呢?如果有人有路径,他们现在可以永远访问该资源吗?在这种情况下,OAuth 可以提供帮助吗?

我想我只是在大声思考如何保护这些资源,所以如果我直接点击一个 URL,我不会总是在没有经过身份验证的情况下获得该资源。是否有其他我可能遗漏的过程或方法?如果是这样,性能和安全性之间的正确平衡是什么?权衡是什么?希望研究可扩展的选项。

【问题讨论】:

  • 否决这个问题有点傻。
  • 又一票否决?真的。也许人们实际上应该评论或添加到这篇文章。有趣的是,我认为堆栈溢出是为了分享想法......
  • 同意。如果您对此投反对票,请留言说明原因。 IMO 这个问题没有错。安全性对于软件开发很重要,这完全是主题。
  • +1 表示一个很好的问题,该问题产生了良好的对话并暴露了著名 Web 应用程序中存在问题的安全漏洞

标签: web-services security oauth webserver


【解决方案1】:

在您描述的资源访问实现中,这将被视为漏洞。几乎每个 Web 应用程序都可以控制以确保请求的资源仅交付给经过身份验证和授权的用户。唯一不会出现这种情况的情况是使用不进行会话跟踪的简单服务器。很遗憾,Facebook 或任何知名网站在 2013 年都容易受到此攻击。这是我在 90 年代和 2000 年代初看到的很多漏洞。

大多数网络应用程序以某种形式维护用户会话的状态。当请求资源(例如通过 URL 的图像)时,会检查会话令牌(或其他方法)以确保用户已通过身份验证,并且用户有权在返回该资源之前请求该资源(访问控制) .如果用户不检查,则请求被拒绝。

【讨论】:

  • 如果您在 facebook 上有资源的 url,无论权限是什么,即使您没有经过身份验证,您都可以查看它。要自己测试它,请上传图像并将其设置为仅对您可见。在 chrome 中打开开发人员工具,然后转到网络选项卡。然后,您可以查看所请求资源的 URL。退出 Facebook,清除缓存或打开您从未使用过 Facebook 身份验证的浏览器。您将能够查看该图像。所以上面的问题和 cmets 仍然成立。您是否有办法保护您已经知道其 URL 的资源?在这种情况下,图像
  • @Michael 我相信你认为 Facebook 很脆弱,但我所说的仍然有效。这是一个不常见的漏洞。 Facebook 很脆弱,这让我感到震惊,但我可以向你保证,这并不常见。您必须了解服务器/Web 应用程序是如何工作的。仅仅因为请求资源并不意味着它被返回。一个 HTTP 请求通过并传递到 Web 应用程序。 Web 应用程序可以随心所欲地响应,没有任何东西强迫它返回请求的资源。在 ASP.NET 中,我根据经过身份验证的用户的 HashMap 检查请求者的会话 ID。
  • 身份验证后,我检查资源的 ACL 以查看用户是否被授权。如果这两个都检查,那么我会按要求返回资源。如果有问题,我会返回 HTTP 403 Forbidden。
  • 我根本没有那样做,所以不用担心:)。事情似乎很开放。我的想法是由于内容的类型,决定不再有额外的资源(硬件和开发时间)来进一步保护它们。如果您进行一些挖掘,就会发现大量不安全的数据。通过默默无闻提高安全性。
  • 我听说了,我去过那里。也许这就是为什么投票被否决的原因:)。
猜你喜欢
  • 2012-11-23
  • 1970-01-01
  • 2011-09-03
  • 1970-01-01
  • 2021-02-15
  • 1970-01-01
  • 2021-04-24
  • 2011-09-14
  • 2015-08-10
相关资源
最近更新 更多