案例演示
正常逻辑
访问:
用户名和密码是写死的: 如果输入成功就重定向到转账界面
来输入用户名和密码:
跳转到转账界面了, 接下来我们输入账号和金额:
点击转账会做什么呢?我们先来看一下:
哦, 原来是执行转账(假装),然后打印一下结果:
伪造逻辑(csrf发生过程)：
现在来一个黑客,要利用csrf来攻击你的转账界面:
那他就先来了解了一下你的转账界面:
知道了你转账的请求的url,就是当前界面
转账所带的参数有to_account和money.
接下来他写了如下攻击程序:
demo代码如下:
模板代码如下: (核心就是这里. 这里也有一个表单,里边请求的action,是转账的网址,参数,请求方式,啥的都一样. 但是to_account就是黑客自己写的了,金钱也是黑客自己写的(意思就是黑客想给谁,转多少钱都可以了.))
运行攻击网站:
访问:
点击领取优惠劵按钮:
发现竟然转账成功了(因为我们转账的网站,已经在当前浏览器登录,已经有cookie了)
如下:
这个红框的校验是可以通过的, 所以就转账成功了.
解决CSRF攻击
具体操作
给A网站的转账界面添加如下hidden隐藏域:
这个csrf_token是由视图函数传递过来的一个随机字符串:
访问:
查看源代码:
多次刷新,这个csrf_token是变化的.
接下来做校验逻辑:
我们在生成csrf_token的时候将他保持到cookie中. 然后在点击转账的时候,进行取出然后校验.
代码写完之后,清除cookie重新来转账:
首先登陆:
然后转账:
此时有一个cookie, 与表单中的隐藏域是一样的:
点击转账:
隐藏域和cookie都会提交到后台视图, 所以校验通过:
来看一下攻击网站:
点领取:
非法请求. 为啥?
因为他这里是没有隐藏域的. 虽然提交的是网站A的url, 浏览器会携带网站A的cookie过去. 但是B是没有办法拿到A的隐藏域的内容进行仿造的.
所以缺少隐藏域,验证失败.