标签：查询 dex http 保护 wrap 客户端 客户 使用 随机
什么是 CSRF
CSRF, Cross Site Request Forgery, 跨站点请求伪造。举例来讲，某个恶意的网站上有一个指向你的网站的链接，如果某个用户已经登录到你的网站上了，那么当这个用户点击这个恶意网站上的那个链接时，就会向你的网站发来一个请求，你的网站会以为这个请求是用户自己发来的，其实呢，这个请求是那个恶意网站伪造的。
经典案例：银行转账：
CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。
比如说，受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdrawaccount=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。
django 第一次响应来自某个客户端的请求时(get方式)，会在服务器端随机生成一个 token，然后把这个 token 写在用户请求的 cookie 里，同时也会给客户端页面发送一个随机的 token (form表单中以{% csrf_token %}方式获取)用以认证。之后客户端每次以 POST 方式向服务端提交请求时，都会带上这个 token，这样就能避免被 CSRF 攻击。
1.在返回的 HTTP 响应的 cookie 里，django 会为你添加一个 csrftoken 字段，其值为一个自动生成的 token；
2.在所有的 POST 表单中，必须包含一个 csrfmiddlewaretoken 字段 （只需要在模板里加一个 tag， django 就会自动帮你生成，见下面）
3.在处理 POST 请求之前，django 会验证这个请求的 cookie 里的 csrftoken 字段的值和提交的表单里的 csrfmiddlewaretoken 字段的值是否一样。如果一样，则表明这是一个合法的请求，否则，这个请求可能是来自于别人的 csrf 攻击，返回 403 Forbidden.
4.在所有 ajax POST 请求里，添加一个 X-CSRFTOKEN header，其值为 cookie 里的 csrftoken 的值
首先，最基本的原则是：GET 请求不要用！有副作用！也就是说任何处理 GET 请求的代码对资源的访问都一定要是“只读“的；
其次，要启用 django.middleware.csrf.CsrfViewMiddleware 这个中间件；
最后，在所有的 POST 表单元素中，需要加上一个 {% csrf_token %} tag。原因：用于csrf在模版渲染过程中，会自动为表单添加一个名为 csrfmiddlewaretoken , type属性为 hidden 的 input。
Django CSRF 应用<基本应用，FBV和CBV不同，ajax应用>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
a. 基本应用： 直接在form表单中添加：就能应用。 {% csrf_token %} -----> 转换成一个hidden属性的input标签 {{ csrf_token }} -----> 直接获取csrf的随机字符串 注意：本地的cookies中也会添加随机字符串 ---> 注意key名 b. 全站禁用： - 整个框架不使用csrf安全机制，直接在settings.py文件中注销，整个网站都不再应用。 # ‘django.middleware.csrf.CsrfViewMiddleware‘, c. 局部禁用：全局使用，但是某些函数不需要应用。 - settings.py文件中不注销，在项目的views.py函数中导入模块，给函数或是类加上对应方法的装饰器： ‘django.middleware.csrf.CsrfViewMiddleware‘, from django.views.decorators.csrf import csrf_exempt,csrf_protect @csrf_exempt #不再做检测！其他没加装饰器的函数还是会检测 def csrf1(request): if request.method == ‘GET‘: return render(request,‘csrf1.html‘) else: return HttpResponse(‘ok‘) d. 局部使用：全局不使用，但是某些函数需要应用。 # ‘django.middleware.csrf.CsrfViewMiddleware‘, from django.views.decorators.csrf import csrf_exempt,csrf_protect @csrf_protect #全站不用，某个函数需要使用认证的时候 def csrf1(request): if request.method == ‘GET‘: return render(request,‘csrf1.html‘) else: return HttpResponse(‘ok‘) e. 特殊CBV：在CBV应用中，有些特殊！ django 不认给类内的函数名上添加装饰器，只能是在类上添加。 同时django限制若是应用装饰器，必须用它的方法去添加，同时添加的语法格式也有限制。 from django.views import View from django.utils.decorators import method_decorator #必须使用这个方法 - 语法：@method_decorator(装饰器函数名称或方法,name=‘被装饰的函数名‘) #先导入方法，然后装饰器以参数的形式添加,其次指定要添加这个方法的函数名<样式：name="函数名"> @method_decorator(csrf_protect,name=‘dispatch‘) class Foo(View): #请求来了，都是先执行类View的内置函数dispatch，然后再映射到对应的方法上！ #所以给dispatch添加上就相当于给所有的方法添加了 def get(self,request): pass def post(self,request): pass PS：CBV中添加装饰器 #自定义的装饰器 def wrapper(func): def inner(*args,**kwargs): return func(*args,**kwargs) return inner # 1. 指定方法上添加装饰器 class Foo(View): @method_decorator(wrapper) #先导入方法，然后装饰器以参数的形式添加 def get(self,request): pass def post(self,request): pass # 2. 在类上添加 @method_decorator(wrapper,name=‘dispatch‘) class Foo(View): def get(self,request): pass def post(self,request): pass f.Ajax提交数据时候，携带CSRF： a. 以post方式提交，放置在data中携带 <form method="POST" action="/csrf1.html"> {% csrf_token %} <input id="user" type="text" name="user" /> <input type="submit" value="提交"/> <a onclick="submitForm();">Ajax提交</a> </form> <script src="/static/jquery-1.12.4.js"></script> <script> function submitForm(){ var csrf = $(‘input[name="csrfmiddlewaretoken"]‘).val(); var user = $(‘#user‘).val(); $.ajax({ url: ‘/csrf1.html‘, type: ‘POST‘, data: { "user":user,‘csrfmiddlewaretoken‘: csrf}, #注意csrf随机字符串，后台有固定的名字接收,这种方式是通过标签获取的对应值 success:function(arg){ console.log(arg); } }) } </script> b. POST方式提交，信息放在请求头中，从cookies中获取的csrf随机字符串 <form method="POST" action="/csrf1.html"> {% csrf_token %} <input id="user" type="text" name="user" /> <input type="submit" value="提交"/> <a onclick="submitForm();">Ajax提交</a> </form> <script src="/static/jquery-1.12.4.js"></script> <script src="/static/jquery.cookie.js"></script> <script> function submitForm(){ var token = $.cookie(‘csrftoken‘); var user = $(‘#user‘).val(); $.ajax({ url: ‘/csrf1.html‘, type: ‘POST‘, headers:{‘X-CSRFToken‘: token}, #注意csrf随机字符串后台有固定的名字接收 data: { "user":user}, success:function(arg){ console.log(arg); } }) } </script> |
注意一定注意：ajax POST提交的时候，csrf-token 随机字符串 直接放在data数据中的方式为：data:{csrfmiddlewaretoken:"{{ csrf_token }}"}
若是导入自己写的JS文件，那上述方法就不能获取到Django后台发送的随机字符串，而是需要利用上面介绍的两种方式获取(页面写上{% csrf_token %}，通过隐藏的input标签取value值写在POST提交的data数据中；或是从cookie中获取，写在头文件中。)
使用django框架时：
每次初始化一个项目时都要看看 django.middleware.csrf.CsrfViewMiddleware 这个中间件
每次在模板里写 form 时都需要加一个 {% csrf_token %} tag
每次发 ajax POST 请求，都需要加一个 X_CSRFTOKEN 的 header
流程:
用户第一次访问页面，肯定是get请求，此时服务端就会给客户端发送一段随机字符串的数据，当客户提交数据的时候，常在POST请求中带回，就会发送随机字符串给服务端（上一次请求获取的数据）用于验证。
服务端给客户端发送的随机字符串作为一种安全机制，客户端往服务端发送请求时再携带回来，用于匹配认证。
可以从form表单中接收，也可以在cookies中查看，注意：这两个的随机字符串是不同的！
如果开启了csrf认证，后台没有拿到对应的字符串的话就会报错---> 403
标签：查询 dex http 保护 wrap 客户端 客户 使用 随机
原文地址：https://www.cnblogs.com/fan-1994716/p/11209260.html
