Django上的网站，https://docs.djangoproject.com/en/dev/ref/contrib/csrf/它指出：Django CSRF cookie可以通过javascript访问？
然后，还规定了CSRF令牌可以从饼干用JavaScript来实现获得：
var csrftoken = $.cookie('csrftoken');
是不是这两个语句冲突的？假设存在Cross Origin攻击，那么攻击者只能从cookie获取CSRF令牌，然后在头中使用CSRF令牌发出POST请求？有人可以解释这个吗？
我现在认识到，只有来自同一产地的JavaScript被允许访问该cookie。后续问题是：
如果POST请求自动添加cookie作为请求的一部分，和Django的CSRF cookie值是一样的CSRF令牌，然后一个恶意的跨源请求将仍然有正确的CSRF令牌无论如何？ （在cookie中）
我相信this post回答您的问题更新：
因为同源策略的，攻击者无法确实访问该cookie。但正如你所提到的那样，浏览器无论如何都会将Cookie添加到POST请求中。出于这个原因，必须从代码中发布CSRF令牌（例如在隐藏字段中）。在这种情况下，攻击者必须知道在创建恶意表单时CSRF令牌的值存储在受害者的cookie中。由于她无法访问Cookie，因此她无法在其恶意代码中复制该令牌，并且攻击失败。
现在，人们可能会想象存储令牌的其他方式比在cookie中。关键是攻击者一定不能得到它。服务器必须有一种方法来验证它。您可以设想将令牌与服务器端的会话一起保存，并在客户端以某种“安全”方式存储令牌（“安全”意味着攻击者无法访问它）。
下面是OWASP报价：
一般情况下，开发人员只需要在当前会话生成一次此标记。在初始生成该令牌之后，该值存储在会话中，并用于每个后续请求，直到会话过期。当最终用户发出请求时，服务器端组件必须验证请求中令牌的存在性和有效性，与会话中找到的令牌相比较。如果在请求中找不到令牌，或者提供的值与会话中的值不匹配，则应中止请求，应重置令牌并将事件记录为正在进行的潜在CSRF攻击。
最后，安全需要两两件事：
我不是专科医生，但这是我对这个问题的理解。希望能帮助到你。
从名称CSRF（Cross Site Request Forgery）中，您已经可以猜测攻击者必须执行来自“跨站点”（其他站点）的请求。
“理解CSRF攻击的关键是要认识到，网站通常没有验证的请求从授权用户来了。相反，他们只核查请求来自授权用户的浏览器来了。” - quoted here
因此，对于那些不阻止CSRF攻击的网站，攻击者可以从任何地方发送恶意请求：浏览器，电子邮件，终端...由于网站不检查请求的来源，它认为授权用户提出了请求。
在这种情况下，在每个Django表单中，都有一个名为“CSRF令牌”的隐藏输入。该值在表单呈现时随机且唯一地生成，并将在请求完成后进行比较。所以请求只能从授权用户的浏览器发送。没有办法（我知道的）攻击者可以获得这个令牌并执行可以被Django后端接受的恶意请求。
够清楚？
可能重复[什么是CSRF保护真的（在Django中）？]（http://stackoverflow.com/questions/10242263/what-is-csrf-protection-really-for-in-django） –