GWT RPC - 它是否足以防止 CSRF？答案

【问题标题】：GWT RPC - Does it do enough to protect against CSRF?GWT RPC - 它是否足以防止 CSRF？
【发布时间】：2011-02-06 06:42:41
【问题描述】：

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

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

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

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

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

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

【问题讨论】：

标签： security gwt csrf gwt-rpc

【解决方案1】：

如果浏览器正在使用这个 GWT RPC，那么它 100% 容易受到 CSRF 的攻击。内容类型可以在 html <form> 元素中设置。 X-GWT-Permutation 和 X-GWT-Module-Base 不在 Flash 的 banned headers 黑名单上。因此，可以使用 Flash 进行 CSRF 攻击。您可以信任的 CSRF 保护的唯一标头元素是“引用者”，但这并不总是最好的方法。尽可能使用基于令牌的 CSRF 保护。

以下是我编写的一些漏洞利用，它们应该能够对我所描述的晦涩攻击有所了解。用于此的 Flash 漏洞利用看起来像 this 和 here 是一个改变内容类型的 js/html 漏洞。

我的漏洞利用是为 Flex 3.2 编写的，而 Flex 4 (Flash 10) 中的规则发生了变化。这里是 latest rules，大多数标头只能针对请求 POST 进行操作。

将navigateTo() 用于 CSRF 的 Flash 脚本： https://github.com/TheRook/CSRF-Request-Builder

【讨论】：

XmlHttpRequest、Flash 和许多其他技术可以设置自定义浏览器标头——但同源策略会启动并阻止另一个站点发出请求。除非服务器有一个宽松的 crossdomain.xml，或者将 Access-Control-Allow-Origin 返回到任意网站，否则请求将如何工作？这只给我们留下了表单/图像/ iframe等，其中same-origin-policy不适用。但我不知道他们可以设置自定义 http 标头的方式。那么，它是如何脆弱的呢？
.. 是的，我同意基于令牌的 csrf 保护是最好的方法，但我想了解他们方法的缺陷。
@sri 非常好的问题。为了成功利用这个漏洞，您必须利用 flash 的一个鲜为人知的特性。我已经发布了 2 个漏洞，这些漏洞可以实现我所描述的，我鼓励您使用它们。（如果您至少没有易受攻击的软件，您可以看到 POST 请求正在发送到另一个域，但由于 S.O.P.，脚本无法“看到”响应）
不，我不依赖 crossdomain.xml 文件或“Access-Control-Allow-Origin”标头。
感谢您的指点。我使用了代码，卡住了，做了一些研究和一些调整，最后意识到除非服务器明确允许，否则 flash 不允许您设置自定义 http 请求标头（请参阅下面的注释）。但我可以通过 flash 设置自定义内容类型标头，从而绕过最流行的 GWT RPC 版本。所以总的来说，我同意你的回答和建议。谢谢！

【解决方案2】：

我不确定是否有简单的方法（我也非常有兴趣找到它！），但至少似乎有一些高级方法可以实现带有任意标头的任意跨站点请求： http://www.springerlink.com/content/h65wj72526715701/论文我没买，但是摘要和介绍听起来很有趣。

也许这里有人已经阅读了论文的完整版，可以稍微扩展一下吗？

【讨论】：

我提交了我编写的 Flash 源代码，该代码修改了 http 标头并发布以利用 csrf 漏洞。
@rook : 但请重新发布。

【解决方案3】：

我知道我问过这个问题，但经过大约一天的研究（感谢 Rook 的指点！），我想我有了答案。

GWT 提供的开箱即用不会保护您免受 CSRF 的影响。您必须采取Security for GWT Applications 中记录的步骤以确保安全。

GWT RPC 将“content-type”标头设置为“text/x-gwt-rpc; charset=utf-8”。虽然我没有找到使用 HTML 表单进行设置的方法，但在 flash 中这样做很简单。

自定义标头 - X-GWT-Permutation 和 X-GWT-Module-Base 有点棘手。不能使用 HTML 设置它们。此外，它们不能使用 Flash 设置，除非您的服务器明确允许在 crossdomain.xml 中进行设置。见Flash Player 10 Security。

此外，当 SWF 文件希望在任何地方发送自定义 HTTP 标头除了它自己的宿主，必须有一个策略文件请求的 HTTP 服务器被发送。此策略文件必须枚举 SWF 文件的宿主来源（或更大的主机集）为被允许发送自定义请求标头到该主机。

现在 GWT 的 RPC 有两种风格。有旧的自定义序列化格式 RPC，以及新的基于 JSON 的 de-RPC。 AFAICT，客户端代码始终设置这些请求标头。旧式 RPC 现在不在服务器端强制执行这些标头，因此可能会发生 CSRF 攻击。新样式的 de-RPC 强制执行这些标头，因此可能会也可能不会攻击它们。

总的来说，如果您关心安全性，请确保您在请求中发送强大的 CSRF 令牌，并且不要依赖 GWT 为您阻止它。

【讨论】：

@sri，这里是设置标题的新规则：eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html你只能在POST上设置它们，常见的被列入黑名单，根据你发布的所有信息“ X-GWT-Permutation" 标头元素可以使用我在跨站点文件上传漏洞中使用的方法来控制 POST 请求。
查看这个更改pragma: no-cache 标头元素的示例代码：eonflex.com/flex/4.1/langref/flash/net/… 如果您在编译我的代码时遇到问题，您应该尝试编译该示例。
您的答案正是我想要的，但它可以追溯到 2010 年。我正在尝试使用现代版本的 flash 编写针对旧式 RPC 的 PoC CSRF 攻击。你知道这是否仍然可能吗？因为目标没有有一个crossdomain,xml。看起来我的 Flash 客户端正在向服务器发送 crossdomain,xml 请求，意识到没有这样的文件，然后没有继续发出我的 CSRF 有效负载。新版本的 Flash 是否从根本上阻止了这种攻击，即使在旧式 RPC 上也是如此？

【解决方案4】：

GWT 2.3 引入了一种更好的机制来对抗 XSRF 攻击。见GWT RPC XSRF protection

【讨论】：

是否有任何独立方验证当前 (GWT 2.8.1) XsrfTokenServlet 实现提供了一种安全的方式来防止 XSRF？