Django开发中如何防止CSRF跨站请求伪造攻击

CSRF概念

跨站请求伪造（CSRF）。

攻击者窃取您的身份并以您的名义发送恶意请求。这个请求对服务器来说是完全合法的，但是它执行了攻击者期望的功能，比如以你的名义发送电子邮件、发送消息、窃取你的账户、添加管理员甚至购买商品、转移虚拟货币等等。

CSRF攻击原理及流程

用户C打开浏览器，访问可信网站A，输入用户名和密码请求登录网站A；

2。用户信息验证通过后，A网站创建cookie信息并返回给浏览器。此时，用户成功登录A网站，可以正常向A网站发送请求；

用户离开A网站前，在同一浏览器中打开TAB页面访问B网站；

网站B收到用户请求后，返回违规代码，请求访问第三方网站A；

浏览器收到这些违规代码后，在用户不知情的情况下，根据 B 网站的请求向 A 网站发出请求。A 网站并不知道该请求实际上是 B 发起的，因此对请求进行了处理

CSRF攻击示例

受害者Bob在银行有存款。通过向银行网站http://bank.example/withdraw?account=bob&amount=1000000&for=bob2发送请求，Bob可以将1000000的存款转入bob2的账户。通常，当向网站发送请求时，服务器首先检查该请求是否来自合法会话，并且该会话的用户 Bob 已成功登录。

Hacker Mallory 本人也有银行账户，知道上面的网址可以转账。 Mallory 可以自己向银行发送请求：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但这个请求来自Mallory，而不是Bob，Bob无法通过安全认证，所以该请求不起作用。

这时，Mallory想到了使用CSRF攻击方法。他首先自己制作了网站，并在其中添加了以下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并让 Bob 访问他的带有广告的网站。当 Pekka 访问该网站时，上述 URL 会从 Pekka 的浏览器发送到银行，并且该请求会与来自 Bob 浏览器的 cookie 一起发送到银行的服务器。在大多数情况下，请求将失败，因为它需要 Bob 的凭据。但是，如果 Pekka 当时恰巧访问了他的银行，则他的浏览器与银行网站之间的会话尚未过期，并且浏览器 cookie 包含 Bob 的身份验证信息。就在这时，悲剧发生了，URL请求得到了答复，钱在Bob不知情的情况下从Bob的账户转移到了Mallory的账户。后来，鲍勃发现他账户里的钱少了。即使他去银行查看日志，也只能看出他确实是合法的转账请求，没有任何攻击的痕迹。另一方面，马洛里则可以拿到钱后侥幸逃脱惩罚。

如何在Django中阻止CSRF

Django使用特殊的中间件（CsrfMiddleware）来进行CSRF保护。具体原理如下：

1。它修改当前处理的请求并向所有 POST 表单添加隐藏表单字段。用户名是 csrfmiddlewaretoken，值是当前会话令牌加上密钥的哈希值。如果未设置会话 ID，中间件不会更改响应结果，因此不使用会话的请求的性能损失可以忽略不计。

2。对于设置了会话 cookie 的所有传入 POST 请求，它会检查 csrfmiddlewaretoken 是否存在且正确。如果没有，用户将收到 403 HTTP 错误。 403错误页面的内容是检测到跨域请求伪装。结束请求。

此步骤可确保只有来自您站点的表单才能发回数据。

另请注意，不使用会话 cookie 的 POST 请求无法受到保护，但它们不需要受到保护，因为恶意网站可以通过多种方式发出此类请求。为了避免转换非 HTML 请求，中间件在修改响应之前会检查响应的 Content-Type 标头。只有标记为 text/html 或 application/xml+xhtml 的页面才会被编辑。

Django 特定功能，用于防止 CSRF

1。将“django.middleware.csrf.CsrfViewMiddleware”添加到 Django 的 settings.py 文件中的 MIDDLEWARE_CLASSES 列表中（默认已添加）。这个中间件必须在SessionMiddleware之后执行，因此CsrfMiddleware必须列在SessionMiddleware之前（因为响应中间件是从后到前执行的）。同时，它还必须在压缩或解压缩响应之前处理响应结果，因此 CsrfMiddleware 必须在 GZipMiddleware 之后运行。

2.在FORM发送POST方法的页面，添加标签csrf_token，例如：