在 URL 中披露 CSRF 令牌与在 POST 请求中包含令牌答案

【问题标题】：Disclosure of CSRF Token in URL vs including the token in POST request在 URL 中披露 CSRF 令牌与在 POST 请求中包含令牌
【发布时间】：2017-01-11 15:18:52
【问题描述】：

我正在尝试在我的一个项目中使用 CSRF 令牌实现 CSRF 保护。我是新手，正在阅读有关在向服务器的请求中发送 CSRF 令牌的信息，发现建议通过 GET 将 CSRF 令牌作为 HTTP POST 发送。我的问题是：

如果 HTTP URL 在 GET 请求中暴露了 CSRF 令牌，并且潜在的攻击者可以使用这个 CSRF 令牌创建 CSRF 请求并使用 Javascript 进行攻击，那么当 CSRF 令牌存储为隐藏字段时，为什么他不能这样做以一种形式？如果我的网站存在 XSS 漏洞，那么攻击者可以从隐藏字段中获取令牌并将请求与该令牌一起发送。

提前致谢！！

【问题讨论】：

为什么需要对 get 请求进行 csrf 保护？
我不需要它，但将来我可能想在暴露为简单锚标记的 URL 中发送令牌。
你为什么要这样做？它有什么意义呢？相关：stackoverflow.com/questions/3477333/…
另外我建议阅读 CSRF 是什么，因为没有（需要）JS（被）参与。

标签： security csrf-protection

【解决方案1】：

这个问题的答案来自Same-Orign Policy。简而言之：恶意网站上的 JavaScript 无法读取另一个网站上的表单内容。就好像 StackOverflow.com 可以在 gmail.com 上阅读您的电子邮件一样，谢天谢地，这是不可能的。

通过 GET 发送的 CSRF 令牌被认为是有害的，因为 HTTP 引用者可以将数据泄漏到第 3 方域。为了使其工作，攻击者需要嵌入图像或可点击的链接。

还可以考虑查看CSRF Prevention Cheat Sheet。

【讨论】：

是的，但是如果我的站点存在 XSS 漏洞并且攻击者注入 javascript 来读取该令牌，则数据（CSRF 令牌）也可能被泄露。对吧？
@Vikas Mangal 当然，因为 XSS 是一个完整的 SOP 绕过。请参阅 CSRF 预防备忘单，因为更详细地介绍了 XSS 绕过 CSRF 保护策略的能力。
GET-CSRF 令牌将登陆服务器日志，然后可能通过链接 HTTP 引用 + 开放重定向攻击来利用。 MitM 和对服务器日志的访问是过于强大的攻击，它们本身比简单的 csrf 令牌泄漏更严重。但是“HTTP referer + 开放重定向攻击”是一种有效的攻击媒介。你可以只为这个特定的 GET 请求使用一个不同的令牌，并且每次都更新它 - 如果它泄漏......没问题 - 你只会从服务器获得一个新的。