你的資料如何被偷走？ Web安全篇 - 跨站請求偽造(CSRF )

CRSF攻擊示意圖

1. 登入正常網站，並在未登出期間收到釣魚郵件或者訊息。
2. 點擊該釣魚郵件或訊息所附帶的網址連結。
3. 進入該網站之後，按下駭客所埋藏的偽造請求按鈕。
4. 由於Cookie的特性，按下該按鈕後，釣魚網站透過夾帶Cookie的方式，連結到我們尚未登出的正常網站，此時若駭客掌握了重要資訊的位置，那麼將可以使用這樣的偽造身分方式竊取我們的重要資訊，進而進行下一步的攻擊。

如何防範CSRF？

❗❗❗身為使用者可以做什麼防範？

• 定期清除瀏覽器歷程(所有)，避免保留過多資料，萬一被竊取時，資料越多風險越高。
• 設定瀏覽器封鎖第三方Cookie，雖然Google已經預計2023年底前逐步淘汰Cookie，但目前仍未將之做為預設選項，因此若擔心的朋友，可以自行設定，但某些網站功能可能無法正常使用。
• 盡量不要瀏覽可疑網站，或者點擊信件、網站中不明連結。
• 每次使用完一個網站就登出才到下一個網站，避免登入中的狀態被利用。

身為網站開發者應盡到什麼義務？

• 個資、金流...等重要功能應增設一道牆，多一層的驗證(圖形驗證、簡訊驗證...等)，以保障使用者。
• 表單發送加上CRSF token，並設定為隱藏欄位，每次產生一組令牌，表單發送到後端時，檢查隱藏欄位的令牌是否合法，如此一來就算經過偽造網站，只要偽造網站不知道這組token就無法順利完成動作，但這也是僅防君子不防小人的手法，真正的壞人也能夠駭到我們的CRSF token。

<input type="hidden" name="csrftoken" value=<csrftoken>/>

• 檢測HTTP Refer，因為我們知道CSRF攻擊者通常來自別的站點，因此透過Refer檢查來源，便可知道這次的請求是否合法。

if (request.headers.referer.includes("domain-1.com")){
   ...
}

瀏覽器本身的防禦

Set-Cookie: xxxxxxxx; SameSite=Strict

• Strict：嚴格模式，只有相同來源的網站才能自動帶上Cookie(識別證)，也就是完全禁止第三方來源的Cookie。
• Lex：放寬了一些限制，允許部分的HTML標籤或者HTTP請求，也就是在有限度的情況下可以夾帶第三方的Cookie。
• None：當然也可以告訴瀏覽器，這個通行證可以不用檢查，但對於使用者來說就比較沒有保障囉，也就容易發生CSRF的狀況。

資源參考

• https://zh.wikipedia.org/wiki/跨站请求伪造
• https://owasp.org/www-community/attacks/csrf
• https://blog.techbridge.cc/2017/02/25/csrf-introduction/
• https://tech-blog.cymetrics.io/posts/jo/zerobased-cross-site-request-forgery/