前言

用过Django 进行开发的同学都知道，Django框架天然支持对CSRF攻击的防护，因为其内置了一个名为CsrfViewMiddleware的中间件，其基于Cookie方式的防护原理，相比基于session的方式，更适合目前前后端分离的业务场景，但美中不足的是，其生成的csrf_token在一个session周期中是不变，这对于一些特定的业务场景，显然有点遗憾。

为了弥补这个遗憾，本文介绍一种不用修改CsrfViewMiddleware中间件源码的方式，实现基于请求的csrf_token更新方式，详文如下。

实现过程

1、Django csrf 校验的两个场景

在业务场景中，有两种不同的csrf防护场景，一种是基于Form 表单提交数据的防护，一种是基于ajax 异步请求数据的防护。

对于Form 表单，可以通过在表单中内置`{% csrf_token %}` 实现在提交数据时一起携带csrf_token提交上去，从而通过后端csrf 校验。

这里顺便提下 Django模板引擎是如何渲染`{% csrf_token %}`的，其实就是将`{% csrf_token %}` 替换成csrf_input的返回值（这点可从Django 模板引擎源码中找到），如下：

而get_token则是从request.META['CSRF_COOKIE']中获取：

对于ajax 请求，需要在提交请求的时候，添加一个名为x-csrftoken的头部（这个头部是Django源码中内定的），值为从cookie中提取的指定name的值，这个name可自定义，比如下图为`csrf-bastion`：

2、Django csrf token 的生成流程

主要关注下CsrfViewMiddleware 中间件的process_view和process_response。

process_view的主要功能之一就是从请求的cookie中提取指定name的（通过settings.CSRF_COOKIE_NAME指定）cookie值为：csrf token，然后赋值给request.META['CSRF_COOKIE']，如果从请求头中提取不到，则重新生成，如下图：

process_response 中会有更新csrf token cookie的功能，如下：

3、 通过在视图中修改request.META['CSRF_COOKIE']值实现csrf token 的更新

通过1和2我们就可以知道只要在在response返回之前更新request.META['CSRF_COOKIE']的值，便可以实现每次请求的csrf token 都不一样，当然可以通过修改CsrfViewMiddleware中间件源码的方式实现，不过这种方式的入侵性太大，最好的选择是在视图中修改，因为视图处理流程是在response之前进行，如下：

这里的rotate_token则是CsrfViewMiddleware 中间件提供的更新csrf token的接口，如下：

总结

本文提到的这个方法确实可以实现基于请求对csrf_token值进行更新，而不是原先的基于session的，这样更新之后，对于ajax请求倒是没有什么问题，不过对于From表单中csrf_token值的更新是需要进行后端渲染更新的，对于前后端分离的请求，这个不足是可以让后端提供个token 获取接口来实现前端页面中form表单的csrf_token值更新实现，当然也可以对form表单的提交行为进行监听，然后异步提交，这样直接走ajax那条路线，就没啥问题了。