csrf 作為一箇中間件 當客戶端發起post請求伺服器,由於攜帶請求body,csrf會驗證

如果請求中包含請求體body, csrf會驗證,才會進入檢視函式

驗證機制:

從cookie中獲取一個csrf_token,

從請求體中獲取一個csrf_token的值

兩者值進行對比, 如果相同則檢驗通過,可以進入到檢視函式中執行

不同則,檢驗失敗,會向前端返回狀態碼400錯誤.

黑客是如何發動CSRF攻擊的?

csrf驗證 在傳送的資料中,除了cookie包含csrf_token, body中也放一個csrf_token.這樣銀行能知道 這個body也是原使用者的body

那黑客也去造一個 csrf_token呢?

如果我無法造這個csrf_token,那我去寫個js指令碼,查詢這個cookie中的值呢?為什麼?

不行, 因為同源策略, 即不同源的網站不能相互操作資源,以ip地址,埠號,及協議來唯一認定.

銀行 192.168.1.2 黑客是1.3 .不同源 ,瀏覽器限制你js讀取資料.

思考

1. CSRF在哪?一共有幾個csrf_token? 分別從哪來? 這個值是我們自己設定的?

2. 哪些傳送方式帶有請求體?

答案:

1. CSRF在請求和傳送端之間作為一箇中間件.一共有2個csrf_token 分別取自發送端的cookie和body, 是

2. POST, PUT, DELETE都可以帶有請求體