Django中间件及csrf跨站请求伪造
Django中间件及csrf跨站请求伪造
摘要
- Django中间件
- csrf跨站请求伪造
一、Django中间件：
什么是中间件？
官方的说法：中间件是一个用来处理Django的请求和响应的框架级别的钩子。它是一个轻量、低级别的插件系统，用于在全局范围内改变Django的输入和输出。每个中间件组件都负责做一些特定的功能。
但是由于其影响的是全局，所以需要谨慎使用，使用不当会影响性能。
说的直白一点中间件是帮助我们在视图函数执行之前和执行之后都可以做一些额外的操作，它本质上就是一个自定义类，类中定义了几个方法，Django框架会在请求的特定的时间去执行这些方法。
我们一直都在使用中间件，只是没有注意到而已，打开Django项目的Settings.py文件，看到下图的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',
]
MIDDLEWARE配置项是一个列表(列表是有序的，记住这一点，后面你就知道为什么要强调有序二字)，列表中是一个个字符串，这些字符串其实是一个个类，也就是一个个中间件。
我们之前已经接触过一个csrf相关的中间件了？我们一开始让大家把他注释掉，再提交post请求的时候，就不会被forbidden了，后来学会使用csrf_token之后就不再注释这个中间件了。
那接下来就学习中间件中的方法以及这些方法什么时候被执行。
Django默认有七个中间件，但是django暴露给用户可以自定义中间件并且里面可以写五种方法
中间件可以定义五个方法，分别是：（主要的是process_request和process_response）
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)
以上方法的返回值可以是None或一个HttpResponse对象，如果是None，则继续按照django定义的规则向后继续执行，如果是HttpResponse对象，则直接将该对象返回给用户。
自定义中间件：
自定义中间件需要在Django配置文件中告诉Django去哪找这个自定义的中间件，默认可以放在项目的对应app中，新建一个文件夹middleware,在此文件夹中新建文件my_middleware.py，然后在此文件中自定义五个方法中的任意一个或多个：
tip：中间件的本质就是含有五个可以修改的内置方法的类，所以自定义的时候需要做的就是先继承一个Django提供的中间件混合的父类。
-
process_request方法：
process_request有一个参数，就是request，这个request和视图函数中的request是一样的（在交给Django后面的路由之前，对这个request对象可以进行一系列修改操作）。
由于request对象是一样的，所以我们可以对request对象进行操作，包括给其增加属性，修改属性，这样就可以在后续的视图函数中通过这个request获取到我们在中间件添加的值。
它的返回值可以是None，按正常流程继续走，交给下一个中间件处理，如果是HttpResponse对象，Django将不执行视图函数，，而将响应对象返回给浏览器。
# 导入MiddlewareMixin模块 from django.utils.deprecation import MiddlewareMixin #定义中间件的类，它继承MiddlewareMixin class Md1(MiddlewareMixin): def process_request(self, request): print('Md1里面的process_request') class Md2(MiddlewareMixin): def process_request(self, request): print('Md2里面的process_request')在settings.py的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', 'app01.middleware.my_middleware.Md1', 'app01.middleware.my_middleware.Md2', ]此时访问一个视图，查看终端打印内容：
根据结果可以知道：执行顺序Md1、Md2、视图函数内容
接着打印每个自定义中间件Md1和Md2中的request，发现是一个request对象
**总结：
## 中间件的process_request方法是在执行视图函数之前执行的
## 当配置多个中间件时，执行顺序按照Django配置文件中的MIDDLEWARE列表中的顺序依次由上至下执行
## 不同的中间件之间传递的request其实都是同一个对象
ps:当前端发来请求，Django会执行每个中间件中的process_request,执行顺序按照配置文件由上至下执行。
-
process_response方法：
*当Django处理完请求，发出返回相应的返回结果时候，process_response方法就会执行，同时多个中间件中的process_response方法是按照MIDDLEWARE中的注册顺序倒序执行的，也就是说当请求走的时候，process_response方法会由下至上依次执行每个中间件的该方法
**定义process_response方法时，必须给方法传入两个形参，request和response。request就是上述例子中一样的对象，response是视图函数返回的HttpResponse对象(也就是说这是Django后台处理完之后给出一个的一个具体的视图)。该方法的返回值(必须要有返回值)也必须是HttpResponse对象。如果不返回response而返回其他对象，则浏览器不会拿到Django后台给他的视图，而是我的中间件中返回的对象***
在Md1和Md2中定义process_response方法，然后执行一个视图函数*
# 导入MiddlewareMixin模块 from django.utils.deprecation import MiddlewareMixin #定义中间件的类，它继承MiddlewareMixin class Md1(MiddlewareMixin): def process_request(self, request): print('Md1里面的process_request') def process_response(self, request, response): print('Md1中的process_response') return response class Md2(MiddlewareMixin): def process_request(self, request): print('Md2里面的process_request') def process_response(self, request, response): print('Md2中的process_response') return response
总结：
## process_response方法是在视图函数之后执行的，并且顺序是Md2比Md1先执行,也就是执行顺序从下到上
-
process_view 方法：
-
路由匹配成功执行视图函数之前自动触发（从上到下依次执行每个中间件中的该方法）
详情：
process_view
-
process_exception 方法：
-
当视执行视图函数报错时，自动触发该方法（从下往上依次执行）*
*详情：*
***process_exception
-
*process_template_response 方法 ：*
-
*视图函数返回的对象有一个render()方法***
-
*（或者表明该对象是一个TemplateResponse对象或等价方法）(从下往上依次执行)详情：
***process_template_response
中间件的执行流程：
上一部分，我们了解了中间件中的5个方法，它们的参数、返回值以及什么时候执行，现在总结一下中间件的执行流程。
请求到达中间件之后，先按照正序执行每个注册中间件的process_request方法，process_request方法返回的值是None，就依次执行，如果返回的值是HttpResponse对象，不再执行后面的process_request方法，而是执行当前对应中间件的process_response方法(注意不是掉头执行所有的process_response方法)，将HttpResponse对象返回给浏览器。也就是说：如果MIDDLEWARE中注册了6个中间件，执行过程中，第3个中间件返回了一个HttpResponse对象，那么第4,5,6中间件的process_request和process_response方法都不执行，顺序执行3,2,1中间件的process_response方法。
[
process_request方法都执行完后，匹配路由，找到要执行的视图函数，先不执行视图函数，先执行中间件中的process_view方法，process_view方法返回None，继续按顺序执行，所有process_view方法执行完后执行视图函数。假如中间件3 的process_view方法返回了HttpResponse对象，则4,5,6的process_view以及视图函数都不执行，直接从最后一个中间件，也就是中间件6的process_response方法开始倒序执行。
process_template_response和process_exception两个方法的触发是有条件的，执行顺序也是倒序。总结所有的执行流程如下：
中间件版登录验证：
*中间件版的登录验证需要依靠session，所以数据库中要有django_session表。
*
中间件版的登录验证
附：Django请求流程图
总结：django中间件能够帮我实现 网站全局的身份验证，黑名单，白名单，访问频率限制，反爬相关
**二、csrf跨站请求伪造 **
啥叫跨站请求伪造：
首先：创造2个Django项目，模拟2个web服务框架：一个假设是正规转账服务框架，一个是钓鱼网站服务框架
正规转账服务框架（Django项目1，端口默认8000）：
# 交易页面trade.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>官方网站</title>
</head>
<body>
<h1>官方网站交易页面</h1>
<form action="http://127.0.0.1:8000/trade/" method="post">
<p>用户名:<input type="text" name="username"></p>
<p>转账金额:<input type="text" name="money"></p>
<p>转账目标账户名:<input type="text" name="target_account"></p>
<input type="submit">
</form>
</body>
</html>
# 交易视图函数：
def trade(request):
if request.method == 'POST':
user_name = request.POST.get('username')
money = request.POST.get('money')
target_account = request.POST.get('target_account')
# 模拟转账成功后的提示
res = '%s 给 %s 转账了 %s，成功！' % (user_name, target_account, money)
return HttpResponse(res)
return render(request, 'trade.html')
(记得配路由，注释掉setting文件中的crsf中间件)
**钓鱼网站服务框架（Django项目2，端口改为8001）：
**
# trade.html页面
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>钓鱼网站</title>
</head>
<body>
<h1>钓鱼网站伪造的交易页面</h1>
<form action="http://127.0.0.1:8000/trade/" method="post">
<p>用户名:<input type="text" name="username"></p>
<p>转账金额:<input type="text" name="money"></p>
<p>转账目标账户名:<input type="text"></p>
<input type="text" name="target_account" value="Sgt" style="display:none">
<input type="submit">
</form>
</body>
</html>
(记得配路由)
以上过程就是跨站请求伪造的过程，主要就是仿照和银行一模一样的的网站，里面的用户名和转账的接口都是指向银行的，只是在网站上form表单处做了手脚，让用户选择的转账用户以为是转给他了，但是实际上是转给了隐藏input标签预设好的账户，达到一种不正当的目的。
当然此处仅仅是展现一下钓鱼的基本简单过程，也就是它实现的基础。
当我们知道存在这种安全隐患的时候，就可以认识这个csrf中间件的作用了，它的作用就是给每一个post请求创造一个按照它的规则和用户制作出来的特殊字符串，每当用户在提交post请求时候都会拿这个字符串与Django中的进行比对，如果不一样则拒绝请求，如果一样则允许该请求进行路由对应的视图函数操作。**
**
接下来就可以将setting配置文件中的中间件部分的csrf部分取消注释，让他生效，只要每次在前端页面提交post请求出加上一行{% csrf_token %}就可以了。这样就完美解决了用户post请求的安全性。
（它的实现过程实际上是在post请求处，比如form表单里加上标签：，value是动态生成的，每一次刷新都不一样）
当使用ajax发送post请求的时候csrf校验该如何进行：
<h1>正经的网站</h1>
<form action="/index3/" method="post">
{% csrf_token %}
<p>username:<input type="text" name="username"></p>
<p>money:<input type="text" name="money"></p>
<p>others:<input type="text" name="others"></p>
<input type="submit">
</form>
<button>ajax</button>
<script>
$('button').click(function () {
$.ajax({
url:'',
type:'post',
data:{'name':'jason','csrfmiddlewaretoken':$('[name="csrfmiddlewaretoken"]').val()},
success:function (data) {
console.log(data)
}
})
})
</script>
也可以自定义那个视图函数需要csrf校验和不需要csrf校验：
from django.views.decorators.csrf import csrf_exempt, csrf_protect
# csrf_protect设置校验crsf
# csrf_exempt设置不校验crsf
from django.utils.decorators import method_decorator
from django.views import View
@csrf_exempt # 不校验csrf
def index1(request):
return HttpResponse('ok')
@csrf_protect # 校验csrf
def index2(request):
return HttpResponse('ok')
'''
csrf装饰CBV需要注意(** ** ** )
csrf_protect
跟正常的CBV装饰器一样
三种
csrf_exempt
只能有下面两种方式
'''
@method_decorator(csrf_exempt, name='dispatch') # 第一种
class Index3(View):
# @method_decorator(csrf_exempt) # 第二种
def dispatch(self, request, *args, **kwargs):
super().dispatch(request, *args, **kwargs)
# 其实都是给dispatch加
