django csrf 保护机制深度解析：双重token防御跨站攻击
本文深入剖析 Django 的 CSRF（跨站请求伪造）保护机制，解答开发者关于其工作原理的常见疑问，例如：为什么需要两个 Token？它们如何协同运作？以及如何有效抵御 CSRF 攻击？
不少开发者误以为 Django 的 CSRF 防御仅仅是对比请求头和请求体中的两个相同 Token。 实际上，Django 使用了两个 不同 的 Token：csrftoken 和 csrfmiddlewaretoken。
csrftoken 存储于浏览器 Cookie 中，由服务器在用户首次访问网站时设置，并在后续请求中自动添加到请求头。 此 Token 在同一会话中保持不变（除非用户登录或注销），具有持久性，确保同一会话内的所有请求都携带相同的 csrftoken。
csrfmiddlewaretoken 则为动态生成的 Token，嵌入服务器生成的 HTML 表单中（例如 ）。每次 GET 请求页面时，服务器都会生成一个新的 csrfmiddlewaretoken 并将其插入表单。用户提交表单（POST 请求）时，浏览器会自动将此 Token 包含在请求体中。
Django 服务器处理 POST 请求时，会同时验证请求头中的 csrftoken 和请求体中的 csrfmiddlewaretoken 的字面量是否完全一致。 匹配则请求合法；不匹配则请求被拒绝，从而有效防止 CSRF 攻击。
攻击者难以同时获取并伪造这两个 Token。 浏览器同源策略阻止攻击者直接从一个域获取另一个域的 Cookie（csrftoken）。即使攻击者通过其他途径获取 csrftoken，也无法预测服务器动态生成的 csrfmiddlewaretoken。 因此，即使伪造 POST 请求，由于 csrfmiddlewaretoken 不匹配，Django 服务器仍会拒绝该请求。
浏览器同源策略固然可以阻止部分跨域请求，但并不能完全防止 CSRF 攻击。 CSRF 攻击通常利用用户已登录的网站，通过精心设计的链接或脚本，诱导用户在不知情的情况下发送恶意请求。 Django 的 CSRF 保护机制正是为了弥补浏览器同源策略的不足，提供更全面的安全防护。
