Django之中间件与CSRF

文章目录

一、什么是中间件
二、中间件有什么用
三、Django自定义中间件
- 中间件中主要方法及作用
- `创建自定义中间件的步骤：`
- process_request与process_response方法
- process_view方法
- process_exception
- process_template_response（不常用）
四、CSRF_TOKEN
- CSRF是什么
- CSRF攻击原理
- CSRF攻击防范
五、CSRF跨站请求伪造详解
六、CSRF跨站请求伪造
七、CSRF相关校验策略
- 一、form表单CSRF策略：
- 二、Ajax请求CSRF策略
八、CSRF装饰器相关操作
- FBV添加装饰器方式
- CBV添加装饰器的多种方式

流程图介绍中间件
在这里插入图片描述

一、什么是中间件

Django中间件类似于django的门户，所有的请求来和响应走走必须经过中间件

中间件顾名思义，是介于request与response处理之间的一道处理过程，相对比较轻量级，并且在全局上改变django的输入与输出。因为改变的是全局，所以需要谨慎实用，用不好会影响到性能

Django官方中间件的定义：

	Middleware is a framework of hooks into Django’s request/response processing. It’s a light, low-level “plugin” system for globally altering Django’s input or output.

中间件它的执行位置在web服务网关接口之后，在路由匹配之前执行的

二、中间件有什么用

如果你想修改请求，例如被传送到view中的HttpRequest对象。或者你想修改view返回的HttpResponse对象，这些都可以通过中间件来实现。

可能你还想在view执行之前做一些操作，这种情况就可以用 middleware来实现。

Django默认的中间件：（在django项目的settings模块中，有一个 MIDDLEWARE_CLASSES 变量，其中每一个元素就是一个中间件，如下）

	'django中自带的有七个中间件'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',]

1.django.middleware.security.SecurityMiddleware

做了一些安全处理的中间件。比如设置XSS防御的请求头，比如做了http协议转为https协议的工作等。

2.django.contrib.sessions.middleware.SessionMiddleware

session中间件。会给request添加一个处理好的session对象。

3.django.middleware.common.CommonMiddleware

通用中间件，会处理一些URL，比如baidu.com会自动的处理成www.baidu.com。

4.django.middleware.csrf.CsrfViewMiddleware

保护中间件，在提交表单的时候必须加入csrf_token，cookie中也会生成一个名叫csrftoken的值，也会在header中加入一个HTTP_X_CSRFTOKEN的值来放置CSRF攻击。SessionMiddleware必须出现在CsrfMiddleware之前。

5.django.contrib.auth.middleware.AuthenticationMiddleware

用户授权中间件。会给reqeust添加一个user对象的中间件。该中间件必须在sessionmiddleware后面。

6.django.contrib.messages.middleware.MessageMiddleware

消息处理中间件。为了在多个模版中可以使用我们返回给模版的变量，并且简化操作。

7.django.middleware.clickjacking.XFrameOptionsMiddleware

防止通过浏览器页面跨Frame出现clickjacking（欺骗点击）攻击出现。

中间件的执行顺序
在这里插入图片描述

每一个中间件在请求来的时候或者响应的时候都具有一定的作用。

三、Django自定义中间件

Django给我们提供了创建自定义中间件的方式，通过创建自定义中间件来实现全局的功能，例如全局用户黑名单校验、全局用户访问频率校验、网站全局用户身份校验等等。

中间件中主要方法及作用

	'中间件类必须继承自django.utils.deprecation.MiddlewareMixin类'process_request(self,request)用途：过滤请求'''1.请求来的时候会按照配置文件中注册了的中间件，从上往下依次执行每一个中间件里面的porcess_request方法，如果没有则直接跳过2.该方法如果返回了HttpResponse对象，那么请求不会再往后执行，原路返回'''process_view(self, request, callback, callback_args, callback_kwargs)用途：用于代码层面的替换和过滤，这个方法可以拿到视图函数的参数'''当路由匹配成功之后，执行视图函数之前，自动触发'''process_template_response(self,request,response)'''当视图函数返回的数据对象中含有render属性对应render函数才会触发'''process_exception(self, request, exception)用途：用于一般用于捕获发生的异常，并将其邮件发送给开发人员'''当视图函数报错之后，自动触发'''process_response(self, request, response)'''1.响应走的时候会按照配置文件中注册了的中间件，从下往上依次执行每一个中间件里面的process_response方法，如果没有则直接跳过2.该方法有两个形参request和response，并且默认情况下应该返回response3.该方法也可以自己返回HttpResponse对象，相当于狸猫换太子'''
'如果请求的过程中process_request方法直接返回了HttpResponse对象那么会原地执行同级别process_response返回后直接返回(flask则不同)'

`创建自定义中间件的步骤：`

	1.在项目名下或者任意的应用名下创建一个文件夹2.在该文件夹内创建一个任意名称的py文件3.在该py文件中编写一个自定义的中间件类，并且必须继承MiddlewareMixin4.紧接着去settings配置文件中注册中间件

process_request与process_response方法

当用户发起请求的时候会依次执行经过的所有中间件，这个时候的请求首先进入process_request，最后到达views的函数中，views函数处理后，在依次穿过中间件，这个时候是process_response，最后返回给请求者。

我们要自己定义中间件的话，需要写一个类，并且继承MiddlewareMixin

	from django.utils.deprecation import MiddlewareMixin

第一步：需要建立一个py文件夹来编写我们自定义的中间件，建议在应用层下面创建。
app-------》Middleware-----》middle.py

	from django.utils.deprecation import MiddlewareMixinclass MyMiddleware1(MiddlewareMixin):def process_request(self,request):print('这是第一个中间件的process_request')def process_response(self,request,response):  # 响应print('这是第一个中间件的process_response')return responseclass MyMiddleware2(MiddlewareMixin):def process_request(self,request):print('这是第二个中间件的process_request')def process_response(self,request,response):  # 响应print('这是第二个中间件的process_response')return response

第二步：在settings.py文件里面加入我们自定义的中间件

	MIDDLEWARE = [# settings这个列表中存储的其实就是一个个中间件的路径'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',#下面两个就是自定义的中间件路径地址'app.Middleware.middle.MyMiddleware1','app.Middleware.middle.MyMiddleware2',]

第三步：定义视图函数

	'记得别忘记配置路由'def func(request):print('from func')return HttpResponse('from func')

当我们浏览器朝服务端发送请求，必定会经过我们刚才定义的中间件
在这里插入图片描述

而process_request方法的request则是请求，response则是视图函数返回的内容到了中间件里面，然后由中间件return出去。所以我们是可以在process_response里面不写return视图函数返回的内容，自己定义内容返回。

从下图看，正常的情况下按照绿色的路线进行执行，假设中间件1有返回值，则按照红色的路线走，直接执行该类下的process_response方法返回，后面的其他中间件就不会执行。
在这里插入图片描述

也就是说中间件的process_request方法使用了return，那么其后面的中间件将不再执行，直接执行该中间件和其上面中间件的process_response方法，最终将某个process_request里面的return值返回给请求者。

由此总结：

中间件的process_request方法是在执行视图函数之前执行的。
当配置多个中间件时，会按照MIDDLEWARE中的注册顺序，也就是列表的索引值，从前到后依次执行的。
不同中间件之间传递的request都是同一个对象

多个中间件中的process_response方法是按照MIDDLEWARE中的注册顺序倒序执行的，也就是说第一个中间件的process_request方法首先执行，而它的process_response方法最后执行，最后一个中间件的process_request方法最后一个执行，它的process_response方法是最先执行的。

process_view方法

该方法格式：process_view(request, view_func, view_args, view_kwargs)

process_view方法的四个参数：

request：HTTPRequest对象
view_func：Django即将调用的视图函数
view_args：将传递给视图的位置参数的元组
view_kwargs：是将传递给视图的关键字参数的字典

view_args和view_kwargs都不包含第一个视图函数(request)

process_view方法是在视图函数之前，process_request方法之后执行的。

它应该返回None或一个HttpResponse对象，如果返回None，Django将继续处理这个请求，执行任何其他中间件的process_view方法，然后在执行相应的视图。如果它返回一个HttpResponse对象，Django不会调用适当的视图函数。它将执行中间件的process_response方法并将应用到该HttpResponse并返回结果。

自定义中间件:

	记得需要注册自定义中间件from django.utils.deprecation import MiddlewareMixinclass Md1(MiddlewareMixin):def process_request(self,request):print('M1请求来时，校验')def process_response(self,reqeust,response):print('M1返回数据时，对数据进行处理')return responsedef process_view(self,request,view_func,view_args,view_kwargs):print('我在只给你view函数前执行！')class Md2(MiddlewareMixin):def process_reqeust(self,request):print('M2请求来时，校验')def process_response(self,request,response):print('M2返回数据时，对数据进行处理')return responsedef process_view(self,request,view_func,view_args,view_kwargs):pass执行结果》》》》：M1请求来时，校验我在只给你view函数前执行！from funcM2返回数据时，对数据进行处理M1返回数据时，对数据进行处理

下图分析上面代码的执行过程：
在这里插入图片描述

当最后一个中间件的process_reqeust到达路由关系映射之后，返回到中间件1的process_view，然后依次往下，到达views函数，最后通过process_response依次返回到达用户。

注意：process_view如果有返回值，会越过其他的process_view以及视图函数，但是所有的process_response都还会执行。

process_exception

process_exception(self, request, exception)

该方法两个参数:

一个HttpRequest对象
一个exception是视图函数异常产生的Exception对象。

这个方法只有在视图函数中出现异常了才执行，它返回的值可以是一个None也可以是一个HttpResponse对象。如果是HttpResponse对象，Django将调用模板和中间件中的process_response方法，并返回给浏览器，否则将默认处理异常。如果返回一个None，则交给下一个中间件的process_exception方法来处理异常。它的执行顺序也是按照中间件注册顺序的倒序执行。

视图函数制造错误

	def index(request):print('index视图函数执行了')lis = [1,2,3]lis[4]

自定义中间件：

	class Md1(MiddlewareMixin):def process_request(self,request):print("Md1请求")def process_response(self,request,response):print("Md1返回")return responsedef process_view(self, request, callback, callback_args, callback_kwargs):print("md1 process_view...")def process_exception(self,request,exception):print("md1 process_exception...")class Md2(MiddlewareMixin):def process_request(self,request):print("Md2请求")def process_response(self,request,response):print("Md2返回")print(response.content)return responsedef process_view(self, request, view_func, view_args, view_kwargs):print("md2 process_view...")def process_exception(self, request, exception):print("md2 process_exception...")return HttpResponse(exception)执行结果》》》》：Md1请求Md2请求md1 process_view...md2 process_view...index视图函数执行了md2 process_exception...Md2返回b'list index out of range'Md1返回

当process_exception进行return HttpResponse后，process_response方法就会拿到其返回的数据。

当views出现错误时流程图如下：
在这里插入图片描述

process_template_response（不常用）

该方法对视图函数返回值有要求，必须是一个含有render方法类的对象，才会执行此方法。

process_template_response 函数是在视图函数执行完后立即执行的

视图

	def index(request):print("这里是 index 页面")repsponse = HttpResponse("这里是主页面 index")def render():print("这里是 index 函数里的 render 方法")return HttpResponse("index")repsponse.render = renderreturn repsponse

自定义中间件

	class Md2(MiddlewareMixin):def process_request(self,request):print("Md2请求")def process_response(self,request,response):print("Md2返回")return responsedef process_view(self, request, view_func, view_args, view_kwargs):print(view_func)print("md2 process_view...")def process_template_response(self, request, response):print("视图函数执行完毕，且返回了render")return response执行结果》》》》：Md2请求md2 process_view...这里是 index 页面视图函数执行完毕，且返回了render这里是 index 函数里的 render 方法Md2返回

四、CSRF_TOKEN

CSRF是什么

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性

也可以这样来理解：

攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。如下：其中Web A为存在CSRF泄露的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户

CSRF攻击原理

如下图：
在这里插入图片描述
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

登录受信任网站A，并在本地生成Cookie
在不登出A的情况下，访问危险网站B

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站
你不能保证你关闭浏览器之后，你的本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了…）
上图中所谓的攻击往回走哪，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

CSRF攻击防范

目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证

（1）验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。

这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。

然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值。如果 bank.example 网站支持 IE6 浏览器，黑客完全可以把用户浏览器的 Referer 值设为以 bank.example 域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。

即便是使用最新的浏览器，黑客无法篡改 Referer 值，这种方法仍然有问题。因为 Referer 值会记录下用户的访问来源，有些用户认为这样会侵犯到他们自己的隐私权，特别是有些组织担心 Referer 值会把组织内网中的某些信息泄露到外网中。因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，网站会因为请求没有 Referer 值而认为是 CSRF 攻击，拒绝合法用户的访问。

（2）在请求地址中添加 token 并验证

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。而对于 POST 请求来说，要在 form 的最后加上，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。

（3）在 HTTP 头中自定义属性并验证

这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。

五、CSRF跨站请求伪造详解

CSRF（Cross-Site Request Forgery）跨站请求伪造是一种常见的网络攻击
攻击者通过诱导受害者访问恶意网站或点击恶意链接
- 将恶意请求发送到目标网站上
- 利用受害者在目标网站上已登录的身份来执行某些操作
- 从而达到攻击的目的。

举个例子
1. 假设受害者在一家网银网站上登录账户，然后继续浏览其他网页。
2. 同时，攻击者通过电子邮件等方式向受害者发送了一封包含恶意链接的邮件。
3. 当受害者点击该链接时，潜在的危险就会变得非常现实。
4. 该链接指向一个由攻击者操纵的网站，该网站上的恶意代码会自动向网银网站发送一个请求，请求转账到攻击者的账户。
5. 由于受害者在网银网站中已经登录，所以该请求会被认为是合法的，这样攻击者就可以成功地进行转账操作。

要保护自己免受CSRF攻击，网站开发者可以采取以下措施：
- 使用CSRF令牌：
  - 在用户的请求中添加随机生成的令牌，并将该令牌保存在用户会话中。
  - 每次提交请求时都会验证该令牌，以确保请求是合法的。
- 启用SameSite属性：
  - 将Cookie的SameSite属性设置为Strict或Lax，以限制跨站请求。
  - 这可以在一定程度上缓解CSRF攻击。
- 严格验证请求来源：
  - 服务器端可以验证请求的来源是否为预期的网站域名
  - 例如检查HTTP Refere头部
    *使用验证码：
  - 在敏感操作（如转账、更改密码等）上使用验证码
  - 增加用户身份验证的防护

六、CSRF跨站请求伪造

我们可以通过模拟一下钓鱼网站的操作来测试，首先在一台计算机上面设置两个服务端不同的端口启动，钓鱼网站提交地址改为正规网站。（不过首先需要给中间件django.middleware.csrf.CsrfViewMiddleware注释掉）

下面就简单的做一个基于form表单的post请求的大概转账功能的例子

1. 首先先搭建一个正规网站的转账功能(简略版)

	'配置urls.py路由设置'from app import viewsurlpatterns = [path('admin/', admin.site.urls),path('index/', views.index),]'配置views.py视图'from django.shortcuts import render,HttpResponse,redirectdef index(request):if request.method == 'POST':username = request.POST.get('username')target_user = request.POST.get('target_user')money = request.POST.get('money')print(f"用户{username}给用户{target_user}转账了{money}元")return render(request,'index.html')'配置template模版层HTML页面'<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><title>Title</title><script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.7.1/jquery.min.js"></script><link href="https://cdn.bootcdn.net/ajax/libs/twitter-bootstrap/3.4.1/css/bootstrap.min.css" rel="stylesheet"><script src="https://cdn.bootcdn.net/ajax/libs/twitter-bootstrap/3.4.1/js/bootstrap.min.js"></script></head><body><div class="container"><div class="row"><div class="col-md-8 col-md-offset-2"><form action="" method="post"><h1 class="text-center">转账页面</h1><p>username: <input type="text" name="username" class="form-control"></p><p>target_user: <input type="text" name="target_user" class="form-control"></p><p>money：<input type="number" name="money" class="form-control"></p><input type="submit" value="提交" class="btn btn-block btn-success"></form></div></div></div></body></html>

然后我们输入一下转账用户和被转账用户信息加转账金额试试看。
在这里插入图片描述
结果可以看到服务端是可以收到请求数据的。

2. 在搭建一个钓鱼网站，直接仿照正规网站一模一样。这里路由层就不多写了，一模一样即可

视图层可以修改一点点，也可以原封不动都行

	'视图层也是一样，当然你可以看把那些获取的操作去掉，只需要能让访问到URL地址即可'def index(request):return render(request,'index.html')注意：记得把端口号更改到别的端口，因为我们是在模拟所以避免端口冲突起不起来，我就设置一个8001端口

下图是修改端口号的操作
在这里插入图片描述

最后就是模型层的HTML文件需要调整一些

	'template模版层HTML'<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><title>Title</title><script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.7.1/jquery.min.js"></script><link href="https://cdn.bootcdn.net/ajax/libs/twitter-bootstrap/3.4.1/css/bootstrap.min.css" rel="stylesheet"><script src="https://cdn.bootcdn.net/ajax/libs/twitter-bootstrap/3.4.1/js/bootstrap.min.js"></script></head><body><div class="container"><div class="row"><div class="col-md-8 col-md-offset-2"><form action="http://127.0.0.1:8000/index/" method="post"><h1 class="text-center">转账页面</h1><p>username: <input type="text" name="username" class="form-control"></p><p>target_user: <input type="text" class="form-control"><input type="text" name="target_user"  value="盗取者ankn" style="display:none;" class="form-control"></p><p>money：<input type="number" name="money" class="form-control"></p><input type="submit" value="提交" class="btn btn-block btn-success"></form></div></div></div></body></html>

我们知道使用post请求提交数据的时候，需要在标签里面写入name属性，否则无法提交到后端。

在这里插入图片描述
来试试效果吧，我们打开钓鱼网站的URL地址后写入转账者账户和被转账者账户然后提交。

结果可以看到正规网站收到了转账者申请转入盗取者ankn一笔钱
在这里插入图片描述

从上述案例可以看到钓鱼网站直接给正规网站发送了请求，那么我们该让正规网站区分是否是钓鱼网站发送的请求呢？我们可以使用CSRF校验策略

七、CSRF相关校验策略

CSRF校验策略，可以让我们在访问官方网站时，我们需要访问一些核心页面(post请求)的时候，会给核心页面(post请求)做唯一的标识，当核心页面朝官方网站发送的请求时，官方会根据唯一标识做判断，没有标识则有可能是恶意网站。

CSRF策略：通过在返回的页面上添加一个独一无二的标识信息，从标识信息中查看返回的信息是否一致，如果不一样说明有人截取了该消息，正规网站发现消息不一致则拒绝接受，此现象叫做403Forbidden与此相关的策略就是我们中间件之前呗注释掉的一行代码（MIDDLEWARE = [django.middleware.csrf.CsrfViewMiddleware]）

一、form表单CSRF策略：

	form表单csrf策略在form表单内部添加{% csrf_token %}eg:<div class="container"><div class="row"><div class="col-md-8 col-md-offset-2"><form action="" method="post"><h1 class="text-center">真正的转账页面</h1>{% csrf_token %}<p>username: <input type="text" name="username" class="form-control"></p><p>target_user: <input type="text" name="target_user" class="form-control"></p><p>money：<input type="number" name="money" class="form-control"></p><input type="submit" value="提交" class="btn btn-block btn-success"></form></div></div></div>

现在我们在用上述制作的钓鱼网站试试，能不能提交请求到正规网站。

在这里插入图片描述
可以看到假冒的提交请求已经报403Forbidden错误了。我们在回到正规转账服务端看看是否接收到了转账成功请求数据。

在这里插入图片描述

可以看到是被拦截了，因为正规转账页面设置了CSRF_Token，它会在后端服务器在渲染表单时生成一个CSRF_Token，并将其存储在会话中或者其他方式关联到当前用户。当用户提交表单时，前端将CSRF_Token的值包含在请求中。后端在验证表单数据时，检查请求中的CSRF_Token是否与存储的Token匹配，如果不匹配，则拒绝请求。

总结：form表单中进行CSRF校验会进行：

添加CSRF Token字段：
- 在form表单中添加一个隐藏字段，用于存储CSRF Token的值。
- 后端服务器在渲染表单时生成一个CSRF Token，并将其存储在会话中或者以其他方式关联到当前用户。
- 当用户提交表单时，前端将CSRF Token的值包含在请求中。
- 后端在验证表单数据时，检查请求中的CSRF Token是否与存储的Token匹配，如果不匹配，则拒绝请求。
设置Cookie：
- 后端服务器在渲染表单时，在客户端设置一个包含随机生成的CSRF Token的Cookie。
- 当用户提交表单时，表单数据会被一同发送到服务器，并自动包含该Cookie。
- 后端在验证表单数据时，检查请求中的CSRF Token是否与Cookie中的值匹配，如果不匹配，则拒绝请求。
双重Cookie校验：
- 后端服务器在渲染表单时，在Cookie中设置一个随机生成的CSRF Token，并将其存储在会话中或以其他方式关联到当前用户。
- 当用户提交表单时，表单数据会被一同发送到服务器，请求头或请求参数中携带一个包含CSRF Token的自定义字段。
- 后端在验证表单数据时，同时检查请求中的CSRF Token和Cookie中的值是否匹配，如果不匹配，则拒绝请求。

二、Ajax请求CSRF策略

方式一：

利用标签查找获取页面上的随机字符串
键必须叫csrfmiddlewaretoken

	先编写csrf模板语法 然后利用标签查找和值获取 手动添加 需要添加 {% csrf_token %}<div class="container"><div class="row"><div class="col-md-8 col-md-offset-2"><form action="" method="post"><h1 class="text-center">转账页面</h1>{% csrf_token %}<p>username: <input type="text" name="username" class="form-control"></p><p>target_user: <input type="text" name="target_user" class="form-control"></p><p>money：<input type="number" name="money" class="form-control"></p></form><button  class="btn btn-block btn-success">提交</button></div></div></div><script>$('.btn').click(function (){$.ajax({url:'',type:'post',{#利用标签查找获取页面上的随机字符串#}data:{'csrfmiddlewaretoken':$('input[name="csrfmiddleewaretoken"]').val()},success:function(args){}})})</script>

方式二：

利用模板语法进行快捷引入

	<script>$('.btn').click(function (){$.ajax({url:'',type:'post',{#利用模版语法自动获取(一定要用引号引起来)#}data:{'csrfmiddlewaretoken':'{{ csrf_token }}'},success:function(args){}})})</script>

方式三：

定义一个js文件并引入
导入该配置文件之前，需要先导入jQuery，因为这个配置文件内的内容是基于jQuery来实现的

官网提供的：https://docs.djangoproject.com/en/1.11/ref/csrf/

	直接引入一个js脚本即可(官网提供的)function getCookie(name) {var cookieValue = null;if (document.cookie && document.cookie !== '') {var cookies = document.cookie.split(';');for (var i = 0; i < cookies.length; i++) {var cookie = jQuery.trim(cookies[i]);// Does this cookie string begin with the name we want?if (cookie.substring(0, name.length + 1) === (name + '=')) {cookieValue = decodeURIComponent(cookie.substring(name.length + 1));break;}}}return cookieValue;}var csrftoken = getCookie('csrftoken');function csrfSafeMethod(method) {// these HTTP methods do not require CSRF protectionreturn (/^(GET|HEAD|OPTIONS|TRACE)$/.test(method));}$.ajaxSetup({beforeSend: function (xhr, settings) {if (!csrfSafeMethod(settings.type) && !this.crossDomain) {xhr.setRequestHeader("X-CSRFToken", csrftoken);}}});

将上述的文件配置到项目的静态文件中,在html页面上通过导入该文件即可自动帮我们解决ajax提交post数据时校验csrf_token的问题，导入配置文件必须先导入jQuery，因为上述文件的内容时基于jQuery来实现的

	<script>$('.btn').click(function (){$.ajax({url:'',type:'post',{#利用模版语法自动获取(一定要用引号引起来)#}data:{},success:function(args){}})})</script>

八、CSRF装饰器相关操作

CSRF是一个唯一标识，只有在进行第二次请求的时候才会去校验（如get请求就不会校验），校验的位置在settings里面，就是post请求注释掉的哪个位置：MIDDLEWARE = ['django.middleware.csrf.CsrfViewMiddleware']

当我们有不一样的要求时：

整个django项目都校验CSRF，但是某些个视图函数/类不想校验
整个django项目都不校验CSRF，但是某些个视图函数/类需要校验

这个时候就需要使用到Django提供的两个装饰器

	from django.views.decorators.csrf import csrf_protect,csrf_exemptcsrf_protect表示检验csrf		csrf_exmpt表示不检验csrf

csrf_protect装饰器：
- csrf_protect装饰器用于需要进行CSRF保护的视图函数或类视图。
- 当一个视图呗csrf_protect装饰器修饰时，Django会对该视图接收到的所有POST、PUT、DELETE等非安全HTTP方法的请求进行CSRF校验。
- 如果请求中没有有效的CSRF令牌或令牌校验失败，Django将返回403 Forbidden响应。

csrf_exempt装饰器：
- csrf_exempt装饰器用于不需要进行CSRF保护的视图函数或类视图。
- 当一个视图被csrf_exempt装饰器修饰时，Django将不会对该视图接收到的任何请求进行CSRF校验。
- 这个装饰器主要用于一些特殊情况，比如与第三方系统进行集成、开发API接口等。

FBV添加装饰器方式

与正常函数添加装饰器一致

	views.py视图层from django.views.decorators.csrf import csrf_protect,csrf_exempt# @csrf_exempt  # 全局csrf校验时，该装饰器作用是不校验此函数@csrf_protect  # 注释掉csrf，该装饰器还是会校验此函数def mys(request):if request.method == 'POST':return HttpResponse('okok')return render(request,'login.html')templates模版层<div class="container"><div class="row"><div class="col-md-8 col-md-offset-2"><h1 class="text-center">登录页面</h1><hr><form action="" method="post"><p>username：<input type="text" class="form-control" name="username"></p><p>password：<input type="password" class="form-control" name="password"></p><input type="submit" value="登录" class="btn btn-block btn-success"></form></div></div>
</div>

局部禁用CSRF

在MIDDLEWARE中间件里面的CSRF中间件代表全局启用，只要接收处理POST请求必须校验请求里面的CSRF，但是我们也可以局部禁用掉CSRF的处理（也就是某个视图函数处理POST请求不需要校验CSRF）

	@csrf_exemptdef test(reqeust):return HttpResponse('okok')

此时就算开启了CSRF校验中间件，那么我们这个视图函数还是可以避免CSRF校验，不携带相关的token值也是可以访问的。

局部启用CSRF

当我们在MIDDLEWARE中间件注释掉了CSRF相关的中间件，那么就代表全局禁用了CSRF，但是Django依旧提供给了我们针对某块区域启用CSRF校验的方法。

	@csrf_protectdef test(reqeust):return HttpResponse('okok')

此时就算不开始CSRF校验中间件，我们这个视图函数还是需要提交POST请求时携带csrf相关的token且必须是由当前服务端生成响应的才合法。

当我们没有注释掉csrf校验中间件的时候，可以在函数头上加上 @csrf_exempt 忽视校验
当我们注释掉csrf校验中间件的时候，可以在函数头上加上 @csrf_protect 强制启动校验

CBV添加装饰器的多种方式

与正常情况不一致，需要引入method_decorator模块

	from django.views import Viewfrom django.utils.decorators import method_decorator # 引入模块# @method_decorator(csrf_protect,name='post')  # 方式1：单独生效 强制启动校验class my(View):# @method_decorator(csrf_protect) # 方式2：整个类中生效 强制启动校验# @method_decorator(csrf_exempt)  # 忽视校验def dispatch(self, request, *args, **kwargs):return super().dispatch(request,*args,**kwargs)# @method_decorator(csrf_protect) 方式3：单独生效 强制启动校验def post(self,request):return HttpResponse('xxxxx')

注意：有一个装饰器是特例，只能由一种添加方法.>>>：csrf_exempt，只有在dispatch方法添加才会生效

		from django.views import Viewfrom django.utils.decorators import method_decorator # 引入模块class my(View):# @method_decorator(csrf_exempt)  # 忽视校验def dispatch(self, request, *args, **kwargs):return super().dispatch(request,*args,**kwargs)def post(self,request):return HttpResponse('xxxxx')