问题标签 [csrf]

I am posting a form using HTMLUnit webClient by putting the username and password but it could not logging me in. When i research then found out that they have enable csrf on post request so native web browser is required. Is there any way to login (post form) in csrf enable website using HTMLUnit or any other tool in Java or it is impossible?

默认情况下，Rails 中的表单 post CSRF 保护会为用户创建一个真实性令牌，该令牌仅在用户会话更改时才会更改。我们的一位客户对我们的网站进行了安全审核，并将其标记为问题。

审计员的声明是，如果我们也有一个 XSS 漏洞，攻击者可以获取另一个用户的真实性令牌并利用它进行 CSRF 攻击，直到用户的会话过期。

但在我看来，如果我们有这样的 XSS 漏洞，攻击者可以很容易地获取另一个用户的会话 cookie 并直接登录该用户。或者甚至只是在用户受到攻击时从脚本调用我们的 REST Api。在这种情况下，能够发起 CSRF 攻击似乎并没有变得更糟……问题在于 XSS 漏洞。

我错过了什么吗？Rails 中默认的 CSRF 保护是否存在真正的问题？

在双重提交cookie csrf预防方案中，服务器是否需要提供cookie？

看来我可以让客户端页面上的javascript生成并设置一个cookie“anti_csrf”，然后双重提交（一次作为cookie，由浏览器完成，一次在请求正文中）。

外部域将无法读取或写入“anti_csrf”cookie 以将其包含在请求正文中。

这是安全的，还是我忽略了什么？

谁能告诉我在哪里/如何为 Symfony 1.4 中的表单自定义 CSRF 令牌错误消息。我正在使用 sfDoctrineGuard 进行登录，特别是在这种形式下，每当会话用完并且您仍然打开页面时，它会引发一个非常用户不友好的错误：“检测到 CSRF 攻击”。类似“此会话已过期。请返回主页并重试”之类的内容听起来更好。

在表单类中执行此操作的正确方法是什么？

谢谢。

我将通过 2007 年和 2010 年的OWASP前10名列表。

我偶然发现了跨站点请求伪造（CSRF），这通常被称为会话骑行，因为您让用户使用他的会话来满足您的愿望。

现在对此的解决方案是向每个 url 添加一个令牌，并为每个链接检查这个令牌。

例如，要对产品 x 进行投票，网址将是：

这看起来像是一个可靠的解决方案，因为黑客无法猜测令牌。

但我在考虑以下场景（我不知道是否可能）：

您创建一个带有隐藏 iFrame 或 div 的网站。之后，您可以使用普通的 iFrame 或 ajax 在其中加载我的网站。

当您将我的网站加载隐藏在您的网站内，并且用户有一个存储的会话时，可以执行以下操作。您可以从 URLS 中检索令牌，并且仍然执行所有需要的操作。

有没有可能做这样的事情。或者不可能做这个跨域。

我不明白使用“挑战令牌”会如何增加任何形式的预防：应该将什么值与什么进行比较？

来自OWASP：

通常，开发人员只需为当前会话生成一次此令牌。在初始生成此令牌后，该值将存储在会话中，并用于每个后续请求，直到会话到期。

如果我正确理解了这个过程，就会发生这种情况。

我在http://example.com登录并创建了一个包含此随机令牌的会话/cookie。然后，每个表单都包含一个隐藏输入，该输入还包含来自会话的随机值，该值在表单提交时与会话/cookie 进行比较。

但这有什么作用呢？您不只是获取会话数据，将其放入页面，然后将其与完全相同的会话数据进行比较吗？似乎是循环推理。这些文章一直在谈论遵循“同源策略”，但这没有任何意义，因为所有 CSRF 攻击都与用户同源，只是诱使用户执行他/她不打算执行的操作。

除了将令牌作为查询字符串附加到每个 URL 之外，还有其他选择吗？看起来非常丑陋和不切实际，并且使用户更难添加书签。

更新：GWT 2.3 引入了一种更好的机制来对抗 XSRF 攻击。请参阅http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html

GWT 的 RPC 机制对每个 HTTP 请求执行以下操作 -

1. 设置两个自定义请求标头 - X-GWT-Permutation 和 X-GWT-Module-Base
2. 将内容类型设置为 text/x-gwt-rpc；字符集=utf-8

HTTP 请求始终是 POST，并且在服务器端 GET 方法会引发异常（不支持该方法）。

此外，如果这些标头未设置或具有错误的值，服务器将无法处理并出现异常“可能是 CSRF？” 或类似的东西。

问题是：这足以防止 CSRF 吗？有没有办法在纯跨站点请求伪造方法中设置自定义标头和更改内容类型？

在过去的几天里，我已经阅读了有关如何防止 CSRF 攻击的信息。我将在每个页面加载中更新令牌，将令牌保存在会话中并在提交表单时进行检查。

但是如果用户有，假设我的网站打开了 3 个选项卡，而我只是将最后一个令牌存储在会话中？这将用另一个令牌覆盖该令牌，并且某些后操作将失败。

我是否需要将所有令牌存储在会话中，还是有更好的解决方案来使其正常工作？

我们正在为我们的代码进行 XSRF 修复。我们正在使用会话令牌请求令牌比较方法来实现这一点。如果会话令牌不等于请求令牌，我们将重定向到错误页面。

问题：一旦我们进入主菜单页面，如果用户“刷新”页面，就会抛出 XSRF 问题。 原因：因为不会有任何请求令牌（当我们刷新页面时）。由于请求令牌为 NULL 且不等于会话令牌，因此引发 XSRF 错误。

应用程序的用户对这种方法不是很满意。那么有什么方法可以启用页面刷新吗？还是绝对有必要/重要的是禁用页面刷新（为了安全）？

提前致谢。

我们最近更新了我们的 MVC 2 解决方案，这更新了AntiForgeryToken工作方式。不幸的是，这不再适合我们的 AJAX 框架。

问题是 MVC 2 现在使用对称加密来编码关于用户的一些属性，包括用户的Name属性（来自IPrincipal）。我们能够使用 AJAX 安全地注册新用户，之后后续的 AJAX 调用将无效，因为当用户被授予新的委托人时，防伪令牌将发生变化。还有其他情况可能会发生这种情况，例如用户更新其姓名等。

我的主要问题是为什么 MVC 2 甚至会费心使用对称加密？那么它为什么要关心主体上的用户名属性呢？

如果我的理解是正确的，那么任何随机共享的秘密都可以。基本原则是用户将收到一个带有一些特定数据的cookie（HttpOnly！）。然后需要这个 cookie 来匹配每个可能有副作用的请求（通常是 POST）发回的表单变量。由于这只是为了防止跨站点攻击，因此很容易制作一个可以轻松通过测试的响应，但前提是您可以完全访问 cookie。由于跨站点攻击者无法访问您的用户 cookie，因此您受到保护。

通过使用对称加密，检查 cookie 的内容有什么好处？也就是说，如果我已经发送了一个 HttpOnly cookie，那么攻击者就无法覆盖它（除非浏览器存在重大安全问题），那么为什么我还需要再次检查它呢？

经过考虑，它似乎是那些“增加安全层”的案例之一——但如果你的第一道防线已经下降（HttpOnly），那么攻击者无论如何都会越过第二层，因为他们有完全的访问权限到用户的 cookie 集合，并且可以直接模拟他们，而不是使用间接 XSS/CSRF 攻击。

当然，我可能遗漏了一个主要问题，但我还没有找到它。如果这里有一些明显或微妙的问题，那么我想知道它们。