互聯網的時代中我們幾乎都離不開網路，那如果能夠對於Web具備基礎的知識，就能夠讓我們在使用網路的過程中提升風險意識，以減少被竊取、盜用的風險，進而保護個人資產，因此多一份知識在身上也就等於多了一份防身的武器，一天學一點，透過微習慣讓我們享受複利的效應。
在前幾篇我們介紹了「同源政策(Same Origin Policy)」與「Web - 跨來源資源共用（CORS）」的基本概念之後，大致上已經了解瀏覽器如何做個守門員，攔截非法的請求/回應，接下來我們就來談談駭客如何繞過「同源政策(Same Origin Policy)」進行跨站請求偽造(CSRF )。
CRSF全名為「Cross Site Request Forgery」中文為跨站請求偽造，相信我們都搭過交通運輸工具，那麼基本上的機制就是認票/卡不認人，假設我們的票/卡片在不知情狀況下被盜取，那麼對方就能直接進入，這套用到網站也是相似的概念，在還未登出的狀況下，Cookie(通行證)被盜用，就能進入你在瀏覽的網站，進而竊取個人資訊，進行下一次的滲透攻擊。CRSF攻擊示意圖
原則上HTTP是屬於無態的，因此正常狀況下，並不會將正常網站的資訊帶到偽造網站，但由於Cookie的特性，會被附加在每個HTTP的請求中，因此才會產生如下圖般被偽造的風險。
- 登入正常網站，並在未登出期間收到釣魚郵件或者訊息。
- 點擊該釣魚郵件或訊息所附帶的網址連結。
- 進入該網站之後，按下駭客所埋藏的偽造請求按鈕。
- 由於Cookie的特性，按下該按鈕後，釣魚網站透過夾帶Cookie的方式，連結到我們尚未登出的正常網站，此時若駭客掌握了重要資訊的位置，那麼將可以使用這樣的偽造身分方式竊取我們的重要資訊，進而進行下一步的攻擊。
🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔
如何防範CSRF？
在談論如何防範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")){
...
}
瀏覽器本身的防禦
chrome在51版之後對於Cookie加入了SameSite的屬性，在夾帶Cookie時，會檢查這個屬性的配置，若符合規則，才能自動夾帶Cookie，讓網站開發者可以設定Cookie在什麼情況下才能自動夾帶，設定方式也非常簡單，只要在原本Set-Cookie之後加上SameSite即可：
Set-Cookie: xxxxxxxx; SameSite=StrictSameSite具備兩種模式，若未指定則預設為Strict
- Strict：嚴格模式，只有相同來源的網站才能自動帶上Cookie(識別證)，也就是完全禁止第三方來源的Cookie。
- Lex：放寬了一些限制，允許部分的HTML標籤或者HTTP請求，也就是在有限度的情況下可以夾帶第三方的Cookie。
- None：當然也可以告訴瀏覽器，這個通行證可以不用檢查，但對於使用者來說就比較沒有保障囉，也就容易發生CSRF的狀況。
詳細說明請參考這裡。
🔔還沒成為Potato會員的朋友點這裡加入哦，撰寫文章還能挖礦打造被動收入 🔔
