【问题标题】：Django CSRF cookie accessible by javascript?javascript可以访问Django CSRF cookie吗？
【发布时间】：2013-07-31 06:11:56
【问题描述】：

在 django 网站上，https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ 声明：

The CSRF protection is based on the following things:

1. A CSRF cookie that is set to a random value (a session independent nonce, as it is called), which other sites will not have access to.
2. ...

然后，它还声明可以通过javascript从cookie中获取csrf令牌：

var csrftoken = $.cookie('csrftoken');

这两种说法不冲突吗？假设有Cross Origin攻击，那么攻击者可以从cookie中获取CSRF token，然后在header中使用CSRF token进行POST请求？有人可以解释一下吗？

更新

我现在意识到，只有来自同一来源的 javascript 才被允许访问 cookie。一个后续问题是：

如果 POST 请求自动添加 cookie 作为请求的一部分，并且 django 的 csrf cookie 值与 csrf token 相同，那么恶意跨源请求仍然会有正确的 CSRF token 吗？（在 cookie 中）

【问题讨论】：

What is CSRF Protection really for (in Django)?的可能重复

标签： django django-csrf

【解决方案1】：

我相信this post 回答了您更新后的问题：

由于同源策略，攻击者确实无法访问cookie。但正如您所提到的，浏览器无论如何都会将 cookie 添加到 POST 请求中。出于这个原因，还必须从代码中发布 CSRF 令牌（例如，在隐藏字段中）。在这种情况下，攻击者必须知道在受害者创建恶意表单时存储在受害者 cookie 中的 CSRF 令牌的值。由于她无法访问 cookie，因此她无法在恶意代码中复制令牌，因此攻击失败。

现在，人们可能会想像在 cookie 中存储令牌的其他方式。关键是攻击者一定无法得到它。并且服务器必须有一种方法来验证它。您可以想象将令牌与会话一起保存在服务器端，并以某种“安全”的方式在客户端存储令牌（“安全”意味着攻击者无法访问它）。

这是来自 OWASP 的引述：

一般来说，开发者只需要为当前会话生成一次这个令牌。在初始生成此令牌后，该值存储在会话中，并用于每个后续请求，直到会话到期。当最终用户发出请求时，服务器端组件必须验证请求中令牌的存在和有效性与会话中找到的令牌相比。如果在请求中未找到令牌或提供的值与会话中的值不匹配，则应中止请求，应重置令牌并将事件记录为正在进行的潜在 CSRF 攻击。

最终，安全需要两件事：

CSRF 令牌必须从代码中发送，这意味着恶意代码必须知道它。
CSRF 令牌必须存储在某个“安全”的地方以进行比较（cookie 很方便）。

我不是专家，但这是我对问题的理解。希望对您有所帮助。

【讨论】：

【解决方案2】：

从名称 CSRF (Cross Site Request Forgery) 中，您已经可以猜到攻击者必须执行来自“跨站点”（其他站点）的请求。

“理解 CSRF 攻击的关键是要认识到网站通常不会验证请求是否来自授权用户。相反，它们仅验证请求来自授权用户的浏览器。” - quoted here

所以对于不阻止 CSRF 攻击的网站，攻击者可以从任何地方发送恶意请求：浏览器、电子邮件、终端……由于网站不检查请求的来源，它认为经过授权的用户提出了请求。

在这种情况下，在每个 Django 表单中，您都有一个名为“CSRF 令牌”的隐藏输入。此值在表单呈现时随机且唯一地生成，并将在发出请求后进行比较。所以请求只能从授权用户的浏览器发送。攻击者无法（据我所知）获取此令牌并执行 Django 后端可以接受的恶意请求。

够清楚吗？

【讨论】：