Django中CSRF防御全过程解析以及中间件作用机制
前言
XSS和CSRF攻击的基础原理这里就不介绍了，之前写了一篇文章单独介绍的很详细了，传送门，这里我们直接以Django为分析对象，分析中间件csrf生成原理以及防范Token如何运作的。
Settings文件
Setting.py中有茫茫多的配置选项。传送门
CSRF中间件
官方文档介绍的也是表面，本文通过源码层面直接分析流程
官方文档针对CSRF的介绍以及参数配置 传送门
Django全流程中间件参与过程
- 是一个轻量级，底层的插件系统，可以介入Django的请求和响应处理过程，修改Django的输入和输出
- 激活:添加到Django配置文件的
MIDDLEWARE中
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
上面的第四个就是我们这里要详细分析的CSRF中间件。
Django中中间件最多可以定义五个方法：
process_request(self,request)
process_view(self, request, view_func, view_args, view_kwargs)
process_template_response(self,request,response)
process_exception(self, request, exception)
process_response(self, request, response)
Django工作流程中中间件执行顺序：
1.请求进入到Django后，Django接收到第一个请求会调用中间件的初始化方法
__init__，处理请求之前会按中间件的注册顺序执行每个中间件中的process_request方法。如果所有的中间件的process_request方法return None，则进入路由映射，进行url匹配，通过规则确认请求由哪个视图处理,如果是return HTTPResponse，则调用process_response返回到客户端
2.依次按顺序执行中间件中的process_view方法
如果某个中间件的process_view方法没有return HttpResponse，则根据第1步中匹配到的URL执行对应的视图函数或视图类（process_view）在views.py执行之前
如果某个中间件的process_view方法中返回了return HttpRespons，则后面的视图函数或视图类不会执行,程序会执行process_response返回客户端
3.视图函数或者视图类接收Request，通过模型Model与数据库交互，获取数据交给模板引擎进行渲染，如果视图函数或视图类中使用render()方法来向客户端返回数据，则会触发中间件中的process_template_response方法,response函数都是通过注册的逆序进行调用，必须返回response才能继续转发，否则程序排除异常
4.随后视图函数或视图类执行计算渲染，如果没有任何异常，会按照中间件的注册顺序逆序执行中间件中的process_response方法
如果中间件中定义了return response，程序会正常执行，把视图函数或视图类的执行结果返回给客户端，否则程序会抛出异常
5.在第三步，程序在视图函数或视图类的正常执行过程中
如果出现异常，则会执行按顺序执行中间件中的process_exception方法，该方法也是逆序执行的，如果某个中间件的process_exception方法中定义了return语句，则终端传递中间件中的process_exception函数，转发给process_response处理后返回给客户端
单个CSRF中间件详细流程图如下
根据上面的步骤，验证了一下多个中间件组合调用的顺序
# 两个中间件代码
from django.http import HttpResponse
from django.utils.deprecation import MiddlewareMixin
class Exp1(MiddlewareMixin):
def process_request(self,request):
print('Exp1 ---> precess_request %s'%id(request))
def process_response(self, request, response):
print('Exp1 ---> process_response')
return response
def process_view(self, request, view_func, view_args, view_kwargs):
print('Exp1 ---> process_view')
print('Exp1',view_func, view_func.__name__)
def process_exception(self, request, exception):
print('Exp1',exception)
print('Exp1','process_exception')
# return HttpResponse('卧槽，挂了啊')
def process_template_response(self, request, response):
print('Exp1','process_template_response')
return response
class Exp2(MiddlewareMixin):
def process_request(self, request):
print('Exp2 ---> precess_request %s'%id(request))
print()
def process_response(self, request, response):
print('Exp2 ---> process_response')
return response
def process_view(self, request, view_func, view_args, view_kwargs):
print('Exp2 ---> process_view')
print('Exp2', view_func, view_func.__name__)
print()
def process_exception(self, request, exception):
print('Exp2', exception)
print('Exp2', 'process_exception')
return HttpResponse('enenenen???')
def process_template_response(self, request, response):
print('Exp2','process_template_response')
return response
# 视图代码
def exrp(request):
# a = [1, 2, 3]
# a[100]
print('views.py-----视图中的代码被执行了')
# return render(request, 'books/cook2.html', {'x':'渲染一下'})
def render():
print("触发 Template render()方法")
return HttpResponse("反悔了啊")
rep = HttpResponse("11123232")
rep.render = render
return rep
# 最后记得在配置文件下写入对应的中间件
访问对应的路径，模拟正常流程下render()渲染的结果
Exp1 ---> precess_request 4385889584
Exp2 ---> precess_request 4385889584
Exp1 ---> process_view
Exp1 <function exrp at 0x1052e2400> exrp
Exp2 ---> process_view
Exp2 <function exrp at 0x1052e2400> exrp
views.py-----视图中的代码被执行了
Exp2 process_template_response
Exp1 process_template_response
触发 Template render()方法
Exp2 ---> process_response
Exp1 ---> process_response
[22/May/2019 16:44:32] "GET /books/exrp/ HTTP/1.1" 200 12
再看一下如果视图渲染的时候错误打印
Exp1 ---> precess_request 4370030264
Exp2 ---> precess_request 4370030264
Exp1 ---> process_view
Exp1 <function exrp at 0x104640400> exrp
Exp2 ---> process_view
Exp2 <function exrp at 0x104640400> exrp
Exp2 list index out of range
Exp2 process_exception
Exp2 ---> process_response
Exp1 ---> process_response
[22/May/2019 16:50:29] "GET /books/exrp/ HTTP/1.1" 200 11
总结：
- 中间件的
process_request和process_view这两个函数是在视图函数之前执行的 - 多个中间件，会按照配置文件的顺序执行，
process_request和process_view是顺序执行，其他三个是逆序执行 - 中间件传递的都是同一个对象
- 如果视图正常渲染，不会执行
process_exception方法，如果不正常，执行顺序逆序，有一个返回HTTPResponse则终端传递，直接传给process_response返回给客户端 - 当我们通过
render()渲染的时候，会触发process_template_response函数，很少用这个方法
两张图详细描述了多个中间件执行顺序，可以配合上面的总概览图看
CSRF中间件原理解析
首先，我们假设settings中的中间件只有一个
'django.middleware.csrf.CsrfViewMiddleware'，根据上面的流程，分析下csrf.py中间件的源码
1.process_request
Django的第一个请求过来，会首先分发到CsrfViewMiddleware中间件模块
class CsrfViewMiddleware(MiddlewareMixin):
def _get_token(self, request):
if settings.CSRF_USE_SESSIONS:
try:
return request.session.get(CSRF_SESSION_KEY)
except AttributeError:
raise ImproperlyConfigured(
'CSRF_USE_SESSIONS is enabled, but request.session is not '
'set. SessionMiddleware must appear before CsrfViewMiddleware '
'in MIDDLEWARE%s.' % ('_CLASSES' if settings.MIDDLEWARE is None else '')
)
else:
try:
cookie_token = request.COOKIES[settings.CSRF_COOKIE_NAME]
except KeyError:
return None
csrf_token = _sanitize_token(cookie_token)
if csrf_token != cookie_token:
# Cookie token needed to be replaced;
# the cookie needs to be reset.
request.csrf_cookie_needs_reset = True
return csrf_token
def process_request(self, request):
csrf_token = self._get_token(request)
if csrf_token is not None:
# Use same token next time.
request.META['CSRF_COOKIE'] = csrf_token
......
无论是GET还是POST，都会进入该流程，假定我们是一个未登录的时候的GET请求，会首先调用__get_token方法（注意：这里调用的私有方法，不是外部的get_token方法，这两个有很大的区别）。可以看到会先在settings中拿CSRF_USE_SESSIONS参数，这里用到了懒加载的机制，该机制会单独开一片文章介绍TODO一下。文章上面放出了官方文档settings的所有参数介绍，这里的两个分支获取token是根据以下两个值配置的。
CSRF_USE_SESSIONS or CSRF_COOKIE_HTTPONLY
这两个值是配套出现的，默认不出现，也就是都是False。那么HTTP报文是这样的
除了sessionid之外，还把csrftoken作为key，也存储在cookies中一并返回给客户端。
前者代表是否把token存入session，如果存入，那么cookies就不在存放csrftoken这个key，而是直接存储sessionid，通过sessionid查出来在从session中获取csrf_token。那么配套的就是把CSRF_COOKIE_HTTPONLY设置成YES，告诉浏览器Cookies只能浏览器默认行为获取，脚本是无法获取的。默认值之外，两者都是True的话，我们可以看Cookies中的报文就只剩sessiondid了。
流程继续，还是按默认值走，我们会从request.COOKIES[settings.CSRF_COOKIE_NAME]中获取，其中CSRF_COOKIE_NAME默认是csrftoken。一开始肯定是None。这里没有return _reject，因此进入URLConf进行路径匹配
from django.contrib import admin
from django.urls import path, include, re_path
urlpatterns = [
path('admin/', admin.site.urls),
path('polls/', include('polls.urls')),
re_path(r'^books/', include('books.urls', namespace='books'))
]
一层层匹配后会有一个对应的视图函数接收，接收之前，来到了第二步。
2.process_view
def process_view(self, request, callback, callback_args, callback_kwargs):
if getattr(request, 'csrf_processing_done', False):
return None
# 如果装饰器 @csrf_exempt生效，则不处理
if getattr(callback, 'csrf_exempt', False):
return None
# Assume that anything not defined as 'safe' by RFC7231 needs protection
if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
if getattr(request, '_dont_enforce_csrf_checks', False):
# 中间件关闭
return self._accept(request)
if request.is_secure():
# 发出的是HTTPS请求，确保我们的url在Refer中
referer = request.META.get('HTTP_REFERER')
if referer is None:
return self._reject(request, REASON_NO_REFERER)
referer = urlparse(referer)
# Make sure we have a valid URL for Referer.
if '' in (referer.scheme, referer.netloc):
return self._reject(request, REASON_MALFORMED_REFERER)
# Ensure that our Referer is also secure.
if referer.scheme != 'https':
return self._reject(request, REASON_INSECURE_REFERER)
# If there isn't a CSRF_COOKIE_DOMAIN, require an exact match
# match on host:port. If not, obey the cookie rules (or those
# for the session cookie, if CSRF_USE_SESSIONS).
good_referer = (
settings.SESSION_COOKIE_DOMAIN
if settings.CSRF_USE_SESSIONS
else settings.CSRF_COOKIE_DOMAIN
)
if good_referer is not None:
server_port = request.get_port()
if server_port not in ('443', '80'):
good_referer = '%s:%s' % (good_referer, server_port)
else:
try:
# request.get_host() includes the port.
good_referer = request.get_host()
except DisallowedHost:
pass
# HTTP白名单，可信任来源
good_hosts = list(settings.CSRF_TRUSTED_ORIGINS)
if good_referer is not None:
good_hosts.append(good_referer)
# 禁止跨域
if not any(is_same_domain(referer.netloc, host) for host in good_hosts):
reason = REASON_BAD_REFERER % referer.geturl()
return self._reject(request, reason)
csrf_token = request.META.get('CSRF_COOKIE')
if csrf_token is None:
# POST 一定要有Cookies存储CSRFToken，避免CSRF攻击
return self._reject(request, REASON_NO_CSRF_COOKIE)
# Check non-cookie token for match.
request_csrf_token = ""
if request.method == "POST":
try:
# request.POST.get() 相当于获取request.POST['csrfmiddlewaretoken']的值，
# 若果出错就返回 ''.这里的csrfmiddlewaretoken是提交的表单中的值，在
# 模板中用{% csrf_token %} 生成
request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
except IOError:
# 在我们完成读取POST数据之前处理断开的连接。
# process_view不应该引发任何exception，因此我们将忽略并返回403
# 假设他们仍在监听，他们可能不是因为错误
pass
if request_csrf_token == "":
# ajax中适用'X-CSRFToken'
# CSRF_HEADER_NAME = 'HTTP_X_CSRFTOKEN'
request_csrf_token = request.META.get(settings.CSRF_HEADER_NAME, '')
request_csrf_token = _sanitize_token(request_csrf_token)
# 对比两个csrf_token，一个是表单里隐藏的csrfmiddlewaretoken
# 或者ajax的hearder: X_CSRFTOKEN），另一个是自带的cookies里的csrf_token
if not _compare_salted_tokens(request_csrf_token, csrf_token):
return self._reject(request, REASON_BAD_TOKEN)
return self._accept(request)
源码已经加了注释，如果请求是GET,HEAD,OPTIONS,TRACE中的，返回None，直接渲染模板。如果不是这几个里面的，比如POST，首先判断是否已经禁用CSRF防御，是的话也是直接渲染模板，不是的话判断是否是HTTPS进入，进行域名白名单匹配。如果是POST，会先从Cookies中取csrf_token，如果取不到，直接拒绝403，如果取到了，表单提交，从csrfmiddlewaretoken中取request_csrf_token,如果是Ajax，从X-CSRFToken取。然后进行这两个值的清洗，去除csrf_secret进行对比，相等就渲染模板，反之直接403。这里的两个Token匹配规则后面会详细介绍
3.Views模块中执行render渲染
到这里，肯定会有人好奇，我一个网站下，一直普通Get请求是没有Cookies的，如果添加了模板的{% csrf_token%}就会触发Cookies和csrfmiddleware这两个值，而且上面提到的数据清洗，这些Token是在什么时候赋值上去的，Token生成规则，匹配规则等，我们从render函数切入。
以下是上面两个执行完之后，没有问题，就会渲染模板
return render(request, 'books/test1.html', {'a' : 111111,'b' : request.GET.get('b'), 'c' : request.GET.get('c')})
# render是便利函数，以下是源码
def render(request, template_name, context=None, content_type=None, status=None, using=None):
content = loader.render_to_string(template_name, context, request, using=using)
return HttpResponse(content, content_type, status)
# 继续往下render_to_string， loader是模块名，
def render_to_string(template_name, context=None, request=None, using=None):
if isinstance(template_name, (list, tuple)):
template = select_template(template_name, using=using)
else:
template = get_template(template_name, using=using)
return template.render(context, request)
最后的render必然是模板渲染的，模板也是一个类，在/django/template/backends/jinja2.py中
class Template:
def __init__(self, template, backend):
self.template = template
self.backend = backend
self.origin = Origin(
name=template.filename, template_name=template.name,
)
def render(self, context=None, request=None):
from .utils import csrf_input_lazy, csrf_token_lazy
if context is None:
context = {}
if request is not None:
# 以下就是我们要找的核心的代码
context['request'] = request
context['csrf_input'] = csrf_input_lazy(request)
context['csrf_token'] = csrf_token_lazy(request)
for context_processor in self.backend.template_context_processors:
context.update(context_processor(request))
return self.template.render(context)
这里的context就是我们的参数字典，最终模板渲染的时候会赋值多几个key和value，这里我们就能找到csrf_token，这就是填充到{% csrf_token %}的值，再往下看
from django.middleware.csrf import get_token
from django.utils.functional import lazy
from django.utils.html import format_html
from django.utils.safestring import SafeText
def csrf_input(request):
return format_html(
'',
get_token(request))
csrf_input_lazy = lazy(csrf_input, SafeText, str)
csrf_token_lazy = lazy(get_token, str)
又是懒加载，这里直接用他的原理，后续再开文章介绍，记住，只有当值真正被用的时候才会执行，函数调用是不会执行的。比如csrf_token_lay(request)。注意看这里的核心函数get_token，引用来自django.middleware.csrf，这下就又回到中间件的核心函数了，这就能解释为什么普通的GET请求不会生成Token，只有加载了{% csrf_token %}的模板，在赋值的时候，去中间件获取token值，代码如下
def get_token(request):
if "CSRF_COOKIE" not in request.META:
# 如果request中不存在csrf，先生成一个新的secret，加密赋值到META["CSRF_COOKIE"] 中，
# 后面用来放到set_cookie之中
csrf_secret = _get_new_csrf_string()
request.META["CSRF_COOKIE"] = _salt_cipher_secret(csrf_secret)
else:
# 如果request的cookie中存在了csrf_token，冲洗解密，取出secret csrf_secret = _unsalt_cipher_token(request.META["CSRF_COOKIE"])
csrf_secret = _unsalt_cipher_token(request.META["CSRF_COOKIE"])
request.META["CSRF_COOKIE_USED"] = True
# 返回另外一个加密生成的secret， 由于加密是随机的，所以与上面的META["CSRF_COOKIE"]不一样
return _salt_cipher_secret(csrf_secret)
这里就不贴_get_new_csrf_string,_salt_cipher_secret和 _unsalt_cipher_token了，代码太多影像阅读，首先看个图，为什么Cookies中的值csrfmiddleware中的值不同，而且刷新的时候Cookies一直不变，csrfmiddleware会一直变，而且还能匹配上？
这个函数会在渲染模板的时候调用，具体来说是由csrf context processor调用。
如果request.META["CRSF_COOKIE"]不存在，就调用_get_new_csrf_string()函数来生成一串随机字符（32个字符，大小写字母和数字），赋给csrf_secret，再调用_salt_cipher_secret(scrf_secret)和随机生成的32位salt一起生成64个字符的字符串赋给request.META[“CSRF_COOKIE”]，而这个request.META["CSRF_COOKIE"]之后用来设置COOKIE 的csrf_token。
最后的返回值_salt_cipher_secret(csrf_secret)就渲染到POST表单的csrfmiddlewaretoken。值得一提的是_salt_cipher_secret(csrf_secret)每次的返回值都不一样，而csrf_secret == _unsalt_cipher_token(_salt_cipher_secret(csrf_secret))。
总的来说，涉及到三个值，csrf_token、csrfmiddlewaretoken和csrf_secret，还有两个函数，_unsalt_cipher_token(token)和_salt_cipher_secret(token)。
这就解释了为什么两个值不同，但是这两个值传入的csrf_secret是一样的，只是salt不同，_unsalt_cipher_token解析出来的值就是一样的，这就是核心比较的东西。
When validating the ‘csrfmiddlewaretoken’ field value, only the secret, not the full token, is compared with the secret in the cookie value. This allows the use of ever-changing tokens. While each request may use its own token, the secret remains common to all.
官方文档也说了，我们比较的不是token，而是计算出来的secret，由于salt的存在，每次的csrfmiddlewaretoken是不同的，但是和cookies中的比较secret是一样的。
用图来说明下这两个过程：
- 生成csrf_token和csrfmiddlewaretoken。
- 验证csrf_token和csrfmiddlewaretoken是否一致。
_unsalt_cipher_token和_salt_cipher_secret函数实现图解。而且两次返回的Token不同如何计算出同一个csrf_secret
4.process_response
模板渲染完之后会触发`process_response``
def process_response(self, request, response):
if not getattr(request, 'csrf_cookie_needs_reset', False):
if getattr(response, 'csrf_cookie_set', False):
return response
if not request.META.get("CSRF_COOKIE_USED", False):
return response
# Set the CSRF cookie even if it's already set, so we renew
# the expiry timer.
self._set_token(request, response)
response.csrf_cookie_set = True
return response
def _set_token(self, request, response):
if settings.CSRF_USE_SESSIONS:
if request.session.get(CSRF_SESSION_KEY) != request.META['CSRF_COOKIE']:
request.session[CSRF_SESSION_KEY] = request.META['CSRF_COOKIE']
else:
response.set_cookie(
settings.CSRF_COOKIE_NAME,
# request.META['CSRF_COOKIE']就是在上面赋值的
request.META['CSRF_COOKIE'],
max_age=settings.CSRF_COOKIE_AGE,
domain=settings.CSRF_COOKIE_DOMAIN,
path=settings.CSRF_COOKIE_PATH,
secure=settings.CSRF_COOKIE_SECURE,
httponly=settings.CSRF_COOKIE_HTTPONLY,
samesite=settings.CSRF_COOKIE_SAMESITE,
)
# Set the Vary header since content varies with the CSRF cookie.
patch_vary_headers(response, ('Cookie',))
组装response，设置Cookies，返回response，客户端浏览器完成渲染，这样一次请求就结束了。
5.Django csrf防御过程解析
前几步已经把每一步具体的实现和原理用图和文字都介绍清楚了，现在带着问题，Django是如何验证一个请求不是CSRF的？
当我们普通的访问一个GET页面的时候，没有任何{%csrf_token%},渲染的时候，context['csrf_token']不会被填充，就是不会去触发get_token方法，所以你请求几次都不会有Cookies。当我们开发一个网站的时候，如果启用CSRF防御，用户登录之前需要提交表单，表单的这个页面会嵌入{%csrf_token%}，会先触发当前登录页面的GET请求，页面render的时候，根据上面第三步，会触发lazy的get_token函数，这个函数会自动生成csrf_token，如果cookies中有的话就不生成，用csrf_token清洗出后32位，再解析出秘钥，返回给表单一个新的csrfmiddlewaretoken，至此登录页面的Cookies也已经生成并返回了，而且表单动态生成了一个csrfmiddlewaretoken。
当正式登录的时候，发送POST请求，同源策略浏览器会携带对应的Cookies，而且会携带表单生成的csrfmiddlewaretoken发送给服务端，当服务器接收到的时候转发给Django，又会来到中间层1-4的步骤。这个时候第一步process_request能获取到值，给request.META["CRSF_COOKIE"]设置值，进入URLConfig路径匹配，匹配到进去视图函数之前进入process_view，如果是GET，直接渲染页面，如果是POST，判断是否禁用防御，判断是否HTTPS安全，判断csrf_token是否为空，这些判断有一个失败，就能看到熟悉的403页面。这个时候就进入最核心的CSRF防御的Token验证过程了，首先会去Cookies中拿到csrf_token，然后如果是表单，直接拿出csrfmiddlewaretoken如果是Ajax，就从header里面拿X-CSRF-Token，根据上面的Token算法，这不是比较这两个token，因为肯定不相同，我们需要反向解析清洗出真正的csrf_secret值，对比如果相同，就是正常访问，如果不同，依然是熟悉的403页面，禁止访问。通过之后渲染页面，然后继续执行precess_response,返回给客户端。
下图就是画了半天的流程图，这算是整个框架流程的大致过程了
其他
1.django/middleware/csrf.py文件里有个函数：rotate_token(request)，这个函数用来改变csrf_token这个COOKIE。 在用户登录后（是指 django.contrib.auth这个组件的登录）调用，主要从安全考虑，避免这个COOKIE跟登录前的一样。 如果自己实现的登录逻辑，可以调用这个函数提高点安全性。
一般csrf_token这个COOKIE是不会变的，除了第一点说的登录，和不存在时重新生成一个。有时候会出现登录后csrftoken失效的情况。
2.为什么Django要把csrf_token和csrfmiddlewaretoken设置成不相等，直接生成的时候让它们相等，验证的时候判断是否相等不就好了？个人觉得这样做有个好处，有时候csrftoken这个COOKIE前端不需要获取，可以设置成HTTP ONLY，提高点安全性。 纯属个人理解
3.从上面分析的算法来看，csrf_token跟csrfmiddlewaretoken相同也可以通过CSRF验证。所以在AJAX请求中，直接取csrf_token值加到请求中就好了，当然和表单一样单独再动态下发也行，问题是要改太多地方了，Ajax可以统一获取。
参考文章：
官方文档
官方文档配置文件
Token验证原理简单篇
Django cookies和session
CSRF验证原理中间件核心
CSRF防御原理解析
中间件源码解析
懒加载原理
Django工作流转