筆記一下研究 csrf 查到的資料，有些小地方網路上的資料都滿模糊的真的查有夠久 XD

CSRF (Cross-site request forgery) 基本原理

基本原理就是使用者在某個 A 網站認證(登入帳號之類的)後瀏覽器把 cookie 存下來，攻擊者利用發送 request 會自動帶上 cookie 的這個動作來讓使用者誤發一些奇怪的 request 去某 A 網站。

舉個簡單的範例
像是一個網站 XXX 提供 API 可以刪除文章
/posts/delete?id=12
但需要使用者用帳號密碼登入後，打這個 API 時在 cookie 中帶著上 session id 才可以刪除

那壞壞的網站可能會有這樣的東西
<a href='http://XXX/posts/delete?id=12'>hi</a>
如果你之前登入過XXX網站，而且該網站又沒有做好防護，點下去文章就會被砍掉拉

注意的是攻擊者看不到 cookie 的內容，只是讓受害者無意間使用了。

網路上有更詳細的介紹這邊就不多講，總之攻擊的方式五花八門，不管是換成POST，或是後端只收 json 之類的方法都是有辦法破解 (但我不會

這篇主要想記錄一些比較常用的防禦方法的運作

圖形驗證碼或簡訊密碼

很多比較敏感的操作都會要求這些，因為這類的攻擊無法得到驗證碼資訊所以防禦成功
但對使用者來說這是一個麻煩

Samesite cookie

是一種設定 http cookie 可以設定的屬性
長得像這樣
Set-Cookie: session_id=123; SameSite=Strict

基本上可以去設定瀏覽器在跨站的 request 是否會自動帶 cookie。
設定成不會自動帶的時候就防住了 csrf

詳細請參考下面連結，裡面有說明了怎樣算是跨站以及不同 SameSite 設定的影響
https://medium.com/@azure820529/chrome-80-%E5%BE%8C%E9%87%9D%E5%B0%8D%E7%AC%AC%E4%B8%89%E6%96%B9-cookie-%E7%9A%84%E8%A6%8F%E5%89%87%E8%AA%BF%E6%95%B4-default-samesite-lax-aaba0bc785a3

目前很多東西都是前後端分離架在不同地方，這些都是跨站的 request。

因為 samesite 和 same-origin policy 名字太像了我就順便看了一下同源政策，結果根本是不同的東東。
同源政策是瀏覽器上的功能，主要做的是 cross-origin 發出請求後，收到回應時瀏覽器會看看同源政策的設定是否 OK，不 OK 的話會把回應擋掉。
不過實際上 request 還是有發出去，所以要是像前面那種攻擊例子也擋不住
詳細請參考：https://blog.techbridge.cc/2017/05/20/api-ajax-cors-and-jsonp/
還有J個 youtube.com/watch?v=KaEj_qZgiKY&ab_channel=LiveOverflow

Synchronizer Token Pattern

因為 Samesite cookie 不是每個瀏覽器都支援
我們還是需要別的方法來判別送 req 的到底是不是使用者

Synchronizer Token Pattern 就是當瀏覽器跟 server 要網頁的時候，server 偷偷在表單中塞一個隨機產生且隱藏的 csrf token，並自己存一份。server 收到 request 時會比對自己存的與收到的是否相同。
詳細請參考：https://medium.com/cross-site-request-forgery-csrf/synchronizer-token-pattern-63871b4c83ad

提一下如果沒有同源政策弄好，受害者在惡意網站發了 request，惡意網站可以看到回來的 response，csrf token 就被看到嚕

前後端分離的狀況下可能要把同源政策設好，只讓合法前端看到 token，前端再送 req 時順便帶上

double submit cookie

這個東西是我查比較久才搞清楚的

運作流程是
server 把 csrf token 設到瀏覽器的 cookie 內，瀏覽器在送 request 時可以把這個 token 從 cookie 拿出來，放到 header (或是 form 裡面都可以) 裡面一起送給 server。
這時進行了 csrf 攻擊，這個攻擊 request 其實還是會帶著 cookie 的 (如果沒設 samesite 的話拉)，但 csrf 攻擊者是看不到 cookie 的，自然也就不知道要放什麼 token 到 header 裡面，認證失敗。

詳細：https://medium.com/cross-site-request-forgery-csrf/double-submit-cookie-pattern-65bb71d80d9f

還有其他的變形像是讓前端自己產生 token 放到 cookie 裡面也行 (送req時放到 header 一起帶去 server)
總之只要攻擊者無法讀到 cookie，他就無法在 header 放入一樣的東西

這種方法 server 不用存 token

前後端分離且在完全不同網域的情況下，把 token 從 cookie 拿出來這段可能會有困難，或許可以在第一次收到 token 時就存在 local storage 之類的地方，但也感覺很容易被盜

差不多寫完了，我也不知道為啥我沒在寫網頁還研究這個