CSRF
xss***:网站评论里等允许别人写js的时候,别人进行的恶意操作。csrf类似。
CSRF的防护通常有两种方式:
一个是通过Challenge-Response的方式,例如通过Captcha和重新输入密码等方式来验证请求是否伪造,但这会影响用户体验,类似银行付款会采用这样的方式。
另一种是通过随机Token的方式,多数Web系统都会采用这种方式,Django也是用的这种。
Token,就是令牌,最大的特点就是随机性,不可预测。一般***或软件无法猜测出来。
那么,Token有什么作用?又是什么原理呢?
Token一般用在两个地方:
1)防止表单重复提交、 2)anti csrf***(跨站点请求伪造)。
两者在原理上都是通过session token来实现的。
当客户端请求页面时,服务器会生成一个随机数Token,并且将Token放置到session当中,然后将Token发给客户端(一般通过构造hidden表单)。下次客户端提交请求时,Token会随着表单一起提交到服务器端。
然后,如果应用于"anti csrf***",则服务器端会对Token值进行验证,判断是否和session中的Token值相等,若相等,则可以证明请求有效,不是伪造的。
不过,如果应用于"防止表单重复提交",服务器端第一次验证相同过后,会将session中的Token值更新下,若用户重复提交,第二次的验证判断将失败,因为用户提交的表单中的Token没变,但服务器端session中Token已经改变了。
上面的session应用相对安全,但也叫繁琐,同时当多页面多请求时,必须采用多Token同时生成的方法,这样占用更多资源,执行效率会降低。
因此,也可用cookie存储验证信息的方法来代替session Token。比如,应对"重复提交"时,当第一次提交后便把已经提交的信息写到cookie中,当第二次提交时,由于cookie已经有提交记录,因此第二次提交会失败。
不过,cookie存储有个致命弱点,如果cookie被劫持(xss***很容易得到用户cookie),那么又一次gameover。***将直接实现csrf***。
所以,安全和高效相对的。具体问题具体对待吧。
此外,要避免"加token但不进行校验"的情况,在session中增加了token,但服务端没有对token进行验证,根本起不到防范的作用。
还需注意的是,对数据库有改动的增删改操作,需要加token验证,对于查询操作,一定不要加token,防止***者通过查询操作获取token进行csrf***。但并不是这样***者就无法获得token,只是增大***成本而已。
1、csrf原理:
form提交
客户端get请求时,django会生成随机字符串给客户,当客户端提交form表单的时候,如果没有随机字符串,则django不允许,报403错误。
加上{% csrf_token %}在html form里生成了一个
<input type="hidden" name="csrfmiddlewaretoken" value="2DjOYDHPE1zO8A0vQQJFS022UkvkUFTPaFPBEYufVjY0Vru07rzhueJ6zQYvlUva">
在HTML模板中添加 {% csrf_token %}
ajax提交
form提交数据需要带随机字符串过去,Ajax提交也需要带着过去。
客户端get请求时,django会生成随机字符串给Cookie,浏览器审查元素 –> Network –> Cookies 里也能找到随机字符串。
所以ajax提交的时候,只需要把cookie里的随机字符串拿到,放到请求头里面发过去就可以了
<script>
$(function(){
$.ajaxSetup({
beforeSend: function(xhr,settings){
xhr.setRequestHeader('X-CSRFtoken', $.cookie('csrftoken'));
}
}); //可以为之后所有的事件header中加入csrf_token《=====》等价于下一个事件中被注释掉的行
$('#btn1').click(function () {
$.ajax({
url: '/login/',
type:"GET",
data: {'user': 'root', 'pwd': '123'},
// headers: {'X-CSRFtoken': $.cookie('csrftoken')}, //此行
success:function(arg){
}
})
});
})
</script>
转载于:https://blog.51cto.com/11736068/2091198