是否只对查看页面的CSRF采取预防措施?

时间:2014-03-27 16:00:38

标签: security csrf csrf-protection

CSRF攻击的所有示例都倾向于针对处理传入请求的页面。

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

我正在寻找的情况@:

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

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

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

为什么我要问:我希望敏感数据页面的网址有一个“简单”的网址,允许用户通过电子邮件将该链接发送给其他人(他们将需要会话查看页面)。我在大多数CSRF解决方案中看到的基于令牌的解决方案消除了这种可能性,因此如果可能的话我想避免它们。

2 个答案:

答案 0 :(得分:3)

  

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

在CSRF方面更正。

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

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

  

为什么我要问:我希望带有敏感数据的网页的网址有一个“简单”的网址,该网址允许用户通过电子邮件将链接通过电子邮件发送给其他人(他们将需要会话才能查看该网页)。我见过的基于令牌的解决方案对于大多数CSRF解决方案都消除了这种可能性

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

正常做法不是将CSRF保护放在无副作用的行动上。

答案 1 :(得分:2)

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

  

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

因此,CSRF是一般请求意图真实性问题。

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