一.黑客的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);
}
}
})