CSRF for Web Developer

寫給網頁開發者的 CSRF 理解與防範

@ 網路安全

前言

最近在碰一些資安的東東，發現自己對於這一塊知識都比較薄弱，身為前端工程師資安通常並不是首要關注的職責，但一但有漏洞保證後果不堪設想，於是近期來補足一下這方面的知識。

什麼是 CSRF

CSRF（Cross-Site Request Forgery）跨站請求偽造，意味著攻擊者透過用戶身份發送惡意請求。根據被攻擊用戶的權限有不同程度的影響，如果管理層級的用戶身分被攻擊者利用 CSRF 攻擊，那麼攻擊者就可以任意操作管理者的權限。

具體來說該攻擊利用瀏覽器請求預設會帶上敏感資料的特性，透過各種手段讓瀏覽器發送用戶不知情的請求來達成目的。

舉例來說用戶登入過 A 網站並在瀏覽器留下了敏感資訊，並且又瀏覽了某惡意網站或信件，其中包含了惡意請求代碼，當觸發時就會讓用戶在 A 網站發送意料之外的請求。

  • 可以是點擊連結
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
  • 可以是加載隱藏的圖片
<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0" />
  • 可以是加載隱藏的自動提交表單
<body onload="document.forms[0].submit()">
  <form action="http://bank.com/transfer.do" method="POST">
    <input type="hidden" name="acct" value="MARIA" />
    <input type="hidden" name="amount" value="100000" />
    <input type="submit" value="View my pictures" />
  </form>
</body>

總結大概念即是透過不同方式想辦法偽造用戶在其他網站的請求。

防範 CSRF

要防範 CSRF 在使用者的角度其實是比較難做到的，頂多不要讓任何敏感資訊儲存於瀏覽器藉由每次使用完網站就登出，大多數的防範措施都需要在伺服器端進行。

防範 CSRF 最直接的方式就是「不要相信用戶的請求是來自本人」，勢必要添加一些需要用戶互動的驗證機制或是只有用戶本人才能知道的資訊來確認請求的合法性。

CSRF Token

當用戶發送請求時伺服器需要提供一個隨機生成的 Token，用戶在發送請求時需要將 Token 一併發送比對。這樣一來攻擊者就無法發送有效的請求，因為攻擊者無法知道具體 CSRF Token 的內容。

設置 Cookie 的 SameSite 屬性，限制第三方 Cookie 的訪問，這樣一來就無法透過第三方網站發送請求。不過基於這種作法依賴瀏覽器支援，舉體可以參考 samesite - caniuse🔗。

總結

無論如何都不輕易相信用戶請求即能最大程度防範 CSRF。隨著使用者逐漸使用重視 Cookie 存取安全性的瀏覽器，可以期望 CSRF 可以被更好更簡單的防範。

延伸閱讀