一.黑客的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防護

https://blog.csdn.net/he93007/article/details/84650984