說說 XSRF 防範

2021-09-11 13:37:10 字數 1461 閱讀 9603

這是我在知乎的乙個回答。原提問是如何在單頁應用下進行 xsrf 防護。

xsrf(csrf) 攻擊的原理是什麼?就是攻擊者能猜測出所有的需要提交的內容以及型別,所以所有的解決方案共同出發點就是加乙個攻擊者也不知道隨機值傳送給後端驗證就可以防範。

有很多解決方案,cookie-session,很不友好的所有表單都得填寫驗證碼,還有一種很少人知道 json web token。

驗證碼(圖形或者手機)這種就不說了吧,這個在網際網路場景中因為使用者體驗原因幾乎沒有應用的。

首先要知道直接讓後端驗證 cookie 是否存在正確是不可取的,因為所有請求都會自動附帶請求所在域的 cookie,當然只驗證 http referer 也是不靠譜的。

正確的方式是當使用者進行登入請求的時候,這時候後端應該把包含 xsrf 欄位的 cookie 儲存在 session 中並且返還給前端,前端需要獲取到 cookie 中的值並且能放入 ajax 請求體或請求頭中,後端把這個值與 session 中的相應值進行判斷就可以了,根據跨域不可訪問不同域的 cookie ,攻擊者也很難猜測出 xsrf 的值,那麼這樣就防範了 xsrf 攻擊。

所以這裡對 xsrf cookie 不能設定 httponly(當然就會有 xss 問題,後面會提),同時提一句所以的 token 必須得讓後端設定 expire 過期時間。

這個 axios 就提供了這個功能,只要設定約定好 xsrf cookie欄位名就可以了,axios 獲取到值後預設是放入 request header 中,這也是業界最流行的方式。

如果不是單頁應用都是後端在表單中加入乙個隱藏的表單域。

type="hidden"

name="_token"

value="lafhb..">

複製**

簡單說,jwt 就是服務端和客戶端約定好乙個token格式,最後用金鑰進行簽名 base64 編碼後放入請求頭即可,客戶端存放這個簽名的內容通常會放在 localstorage 中,也有放在 cookie 中的。jwt應用了雜湊簽名的密碼學技術,相比 cookie-session 的方式就是服務端可以不用(在記憶體或者快取)存放 session,能節省儲存資源,不過同時伺服器需要通過計算來驗證也浪費了計算資源。詳細的說明可以參考:講真,別再使用jwt了!

現有的產品為了更安全還需要考慮 xss 攻擊,這個就是有些惡意指令碼或者外掛程式不存在跨域問題,所以能獲取到 cookie 和 localstorage 的值。

很安全的方式就是把 xsrf token 加入到 jwt 中,並且把 jwt 存放在設定 httponly 的 cookie 中,然後單獨把 xsrf token (一般而言就是乙個隨機值)設定在 httponly=false 的 cookie 中,前端請求時,需要獲取 xsrf token 並放入請求頭(requestheader)。伺服器端可以直接驗證jwt中xsrf的值和xsrf的值即可。因為用了雜湊金鑰簽名的技術,這樣就可以防止篡改內容。

這樣的安全防護就能抵禦所有的 xsrf 攻擊了。

說說 XSRF 防範

這是我在知乎的乙個回答。原提問是如何在單頁應用下進行 xsrf 防護。xsrf csrf 攻擊的原理是什麼?就是攻擊者能猜測出所有的需要提交的內容以及型別,所以所有的解決方案共同出發點就是加乙個攻擊者也不知道隨機值傳送給後端驗證就可以防範。有很多解決方案,cookie session,很不友好的所有...

說說區塊鏈,說說初鏈

別人笑我太瘋癲,我笑他人看不穿。近期很多朋友都找我問區塊鏈 哎,輝哥,聽說你在搞區塊鏈?但大多數都是僅僅知道區塊鏈,數字貨幣這麼個概念,聊起來也基本都是一問二問三懵逼,都聽說這是下乙個風口,也都想湊進來找找機會。今兒得空,好好說說區塊鏈,說說我近期看好的初鏈。這是比較官方的解釋,簡單點理解區塊鏈就是...

防範sql注入

真沒語言了,公司的 都有這個漏洞,明天趕緊把改了 sql注入式攻擊是利用是指利用設計上的漏洞,在目標伺服器上執行sql命令以及進行其他方式的攻擊 動態生成sql命令時沒有對使用者輸入的資料進行驗證是sql注入攻擊得逞的主要原因。比如 如果你的查詢語句是select from admin where ...