本地py向远程django发起post请求，cookie中加了csrftoken，但是校验不成功

Question

我在本地使用python的Requests先发起get请求，获取csrftoken，将csrftoken加入到headers中{'Cookie':'csrftoken=获取到的token值'}再发起post请求，但是一直是403.

难道是需要在view.py中手动检验吗，但是我使用浏览器post完全没问题（网页中有{% csrf_token %}）。

刚刚接触django，百度了好久一直没能解决问题，希望大佬可以解答疑惑。

Answer 1

文档
Search:

Getting Help 

语言： zh-hans 

文档版本： 4.2 

跨站请求伪造保护¶

The CSRF middleware and template tag provides easy-to-use protection against Cross Site Request Forgeries. This type of attack occurs when a malicious website contains a link, a form button or some JavaScript that is intended to perform some action on your website, using the credentials of a logged-in user who visits the malicious site in their browser. A related type of attack, 'login CSRF', where an attacking site tricks a user's browser into logging into a site with someone else's credentials, is also covered.

The first defense against CSRF attacks is to ensure that GET requests (and other 'safe' methods, as defined by RFC 9110#section-9.2.1) are side effect free. Requests via 'unsafe' methods, such as POST, PUT, and DELETE, can then be protected by the steps outlined in 如何使用 Django 提供的 CSRF 防护功能.
工作方式¶

CSRF 保护是基于以下几点：

A CSRF cookie that is a random secret value, which other sites will not have access to.

CsrfViewMiddleware sends this cookie with the response whenever django.middleware.csrf.get_token() is called. It can also send it in other cases. For security reasons, the value of the secret is changed each time a user logs in.

A hidden form field with the name 'csrfmiddlewaretoken', present in all outgoing POST forms.

In order to protect against BREACH attacks, the value of this field is not simply the secret. It is scrambled differently with each response using a mask. The mask is generated randomly on every call to get_token(), so the form field value is different each time.

这一部分是由模板标签来完成的。

对于所有不使用 HTTP GET、HEAD、OPTIONS 或 TRACE 的传入请求，必须存在一个 CSRF cookie，并且“csrfmiddlewaretoken”字段必须存在且正确。如果不存在，用户将得到一个 403 错误。

当验证“csrfmiddlewaretoken”字段值时，只有密钥，而不是完整的令牌，会与 cookie 值中的密钥进行比较。这允许使用不断变化的令牌。虽然每个请求都可能使用自己的令牌，但密钥对所有请求都是通用的。

这个检查是由 CsrfViewMiddleware 完成的。

CsrfViewMiddleware 根据当前主机和 CSRF_TRUSTED_ORIGINS 的设置，验证 Origin header ，如果是由浏览器提供的。这提供了对跨子域攻击的保护。

此外，对于 HTTPS 请求，如果没有提供 Origin 头，CsrfViewMiddleware 会执行严格的来源检查。这意味着，即使一个子域可以设置或修改你的域名上的 cookie，它也不能强迫用户向你的应用程序发布，因为该请求不会来自你自己的确切域名。

这也解决了在 HTTPS 下使用独立于会话的密钥时可能出现的中间人攻击问题，这是因为 HTTP Set-Cookie 头会被客户接受（不幸的是），即使他们在 HTTPS 下与一个网站对话。对 HTTP 请求不进行 Referer 检查，因为 HTTP 下 Referer 头的存在不够可靠）。

如果设置了 CSRF_COOKIE_DOMAIN 设置，则会将 referer 与之进行比较。你可以通过包含一个前导点号来允许跨子域请求。例如，CSRF_COOKIE_DOMAIN = '.example.com' 将允许来自 www.example.com 和 api.example.com 的 POST 请求。如果没有设置，那么 referer 必须与 HTTP Host 头匹配。

通过 CSRF_TRUSTED_ORIGINS 设置，可以将接受的 referer 扩展到当前主机或 cookie 域之外。