【问题标题】:are precautions against CSRF needed for view-only pages?仅查看页面需要针对 CSRF 的预防措施吗?
【发布时间】:2014-05-06 17:50:21
【问题描述】:

所有 CSRF 漏洞利用示例都倾向于针对处理传入请求的页面。

如果页面没有表单处理方面,我需要担心 CSRF 吗?

我正在寻找的情况@:

  • 相关页面包含敏感数据
  • 因此用户需要建立会话才能查看页面

...我的理解是,恶意页面将能够通过嵌入指向该页面的链接将客户端重定向到该页面,但是由于目标没有执行任何操作,因此不会造成任何伤害,对吧?

上述恶意网站无法查看敏感页面,对吗?

我问的原因:我希望包含敏感数据的页面的 url 有一个“简单”的 URL,它允许人们通过电子邮件将链接发送给其他人(他们反过来需要一个会话来查看页面)。我在大多数 CSRF 解决方案中看到的基于令牌的解决方案消除了这种可能性,因此我希望尽可能避免使用它们。

【问题讨论】:

  • 根据incompleteness.me/blog/2007/01/01/…,这意味着浏览器上的脚本可能会将页面内容重定向到另一台服务器,从而导致数据泄露。但是我认为同源政策可以防止这种泄漏,不是吗? 我错过了什么?

标签: security csrf csrf-protection


【解决方案1】:

一般来说,CSRF 与请求是否引起任何副作用无关。 CWE describes CSRF (CWE-352)如下:

Web 应用程序没有或不能充分验证提交请求的用户是否有意提供了格式正确、有效、一致的请求。

所以CSRF是一个通用的请求意图真实性问题。

然而,尽管 CSRF 在没有数据检索以外的任何影响的情况下并非真正可行,因为同源策略限制攻击者访问响应,但攻击者也可以利用另一个漏洞从仅检索请求中获利并获得访问权限敏感数据。

【讨论】:

  • 其实你是对的——“攻击者可以利用另一个漏洞”涵盖了很多,做这种事情的人比我想象的要聪明。所以我的计划就这样了:-)
  • 这取决于您的数据采用什么格式。您喜欢的 Gmail 攻击是因为 GET 请求在 JavaScript 函数中返回数据。普通的 HTML 页面通常是安全的(但建议使用 HTTPS),否则您在 Internet 上阅读的任何页面都可能被在其他选项卡中打开的网站所破坏。
【解决方案2】:

上述恶意网站无法查看敏感页面,对吗?

在 CSRF 方面是正确的。

您链接的博客正在谈论跨源脚本包含,这是一种不同的动物。要容易受到 XOSI 的攻击,您的敏感页面必须可以解释为 JavaScript,并且您必须在没有正确 HTML MIME 类型的情况下提供它,或者浏览器必须是不强制类型检查的旧浏览器在脚本上。

您还可能担心点击劫持,即另一个网站将您的网站包含在一个框架中并覆盖误导性 UI 元素。有一些偷偷摸摸的方法已被用于提取敏感数据(请参阅 next generation clickjacking 论文和 Firefox 中的 this 有趣的信息泄漏),因此您可能希望禁止使用 X-Frame-Options 标头进行框架。

我问的原因:我希望包含敏感数据的页面的 url 有一个“简单”的 URL,它允许人们通过电子邮件将链接发送给其他人(他们反过来需要会话来查看页面)。我在大多数 CSRF 解决方案中看到的基于令牌的解决方案消除了这种可能性

您绝对不应该将 CSRF 令牌放入 GET URL 中。除了丑陋和导航损坏之外,URL 还很容易从浏览器或其他基础设施中泄漏,可能会损害令牌的机密性。

通常的做法是不将 CSRF 保护放在无副作用的操作上。

【讨论】:

    猜你喜欢
    • 2021-05-01
    • 2019-01-04
    • 2015-01-12
    • 1970-01-01
    • 2014-09-29
    • 1970-01-01
    • 2011-03-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多