一.黑客的csrf攻击方式:
黑客构造网站后台某个功能接口的请求地址,诱导用户去点击或者用特殊方法让该请求地址自动加载。
如果近期用户登录过被攻击网站(假设未开启防护),cookie还没过期. 那么这个黑客的请求将会合法通过.---------本质是黑客利用用户的cookie数据.
二.防护方式与原理
防护方式----------设置token >>>>cookie 一个token,body 里表单一个token, 两个token对上了才能通过验证.
为什么cookie和body分别加一个token,就能起到防护呢?黑客拿到token写进表单里不就可以了吗?
防护原理-----原因是浏览器的同源策略.
>>>>浏览器执行一个脚本的时候会检查这个脚本是属于哪个页面的,检查是否同源,不同源则拒绝执行.这样cookie中的token就是安全的.
黑客拿不到cookie中的token,就无法在body中伪造token了.
三.flask中的csrf防护
依赖于flask-wtf
防护 post put delete patch | 不防护 GET
后端:
创建app函数中 CSRFProtect(app) 开启防护.
提供静态资源视图函数中
随机token值 csrf_token = csrf.generate_csrf()
设置到cookie response.set_cookie("csrf_token",csrf_token)
前端:
获取cookie中的token>>>>> js函数>>>>>
function getCookie(name) {
var r = document.cookie.match("\\b" + name + "=([^;]*)\\b");
return r ? r[1] : undefined;
}
post的请求体数据如果是表单格式的,后端的csrf机制能直接从请求题中取csrf_token的值.
>>>>如果post的数据不是表单格式,后端无法自动的从请求体中获取csrf_token的值,前端可以在请求头中添加字段 X-CSRFToken>>>
例 :
//向后端发送注册请求
var reqDate = {
mobile:mobile,
sms_code:phoneCode,
password:passwd,
password2:passwd2
};
// $.post("",reqData) 表单格式数据
// "mobile=13750000000=xxxx=xxx..."
var reqJsonStr = JSON.stringify(reqDate);
$.ajax({
url:"/api/v1.0/users", //后端的接口网址
type:"post", //请求方式
data:reqJsonStr, //请求体数据
contentType:"application/json", //说明请求体的数据格式是json
dataType:"json", //指明后端返回的数据格式
headers:{ // 自定义请求头
"X-CSRFToken": getCookie("csrf_token") //配合后端的csrf防护机制
},
success:function (resp) { //成功的回调函数
if (resp.errno == "0"){
//表示注册成功
//跳转到主页
location.href = "/index.html";
} else {
alert(resp.errmsg);
}
}
})
下一篇:不使用flask-wtf 手动实现csrf防护