[技術分享] Cross-site Request Forgery (Part 2)－就是資安

在上一篇的文章中，我們了解到何謂 CSRF 以及其運作原理，在這篇的文章中我想要談談網站開發者與使用者該如何做才能避免 CSRF 的威脅。

要避免 CSRF 的攻擊，目前公認最有效的方式就是所謂的 Synchronizer Token Pattern。簡單來說，Synchronizer Token Pattern 指的是每次使用者發出請求時 (不管是透過 POST 還是 GET) 都必須傳回一個網站系統所指定的亂數，而這個亂數可以設計成適用於整個 Session 階段，也可以設計為只能使用一次。以安全性而言，後者的作法確實可以達到相當好的效果，但是卻也會為使用者帶來極大的不便性，所以在大部分的情況下前者反而是比較常用的作法。其實後者的作法除了應用在增加安全性之外，也常被用來作為避免使用者重複發出請求的保護措施。使用者重複發出請求尤其容易出現在反應較慢的系統中，使用者因為失去耐心或不知所措之下往往只好重複之前的動作 (請求)。

等等，在使用 GET 的情形下，Synchronizer Token 不就等於直接擺在 URL 參數中讓人取用，那怎麼還有安全性可言？別忘了在 CSRF 攻擊中，通常駭客是無法取得受害者與目標網站之間溝通的訊息，所以這樣的作法依舊大幅增加駭客產生合法請求的困難度。再加上 Synchronizer Token 的有效期僅存在單一 Session、甚至是單一請求中，因此就算駭客取得 Synchronizer Token 後也往往無濟於事了。此外，透過 SSL 進行連線可以讓 Synchronizer Token 被”看到”的機會大大降低。

Synchronizer Token 的一個特例就是直接把 Session Token 當作 Synchronizer Token 使用，這種方法又稱之為 Double Submit Cookies。使用 Double Submit Cookies 的好處是比較方便，網站系統不需要另外維護一份 Synchronizer Token 的對應關係表，但是這樣做卻會讓 Session Token 處於一個較危險的狀況，增加了 Session Hijacking 攻擊的成功機會。

除了 Synchronizer Token 外，還有一些其他的手法也會被用於應付 CSRF，像是只接受 POST 的方式、檢查 Referer 標頭、將單一請求就可以完成的流程拆成多個請求、URL 重導、秘密的 Cookie (Secret cookie) 等方式。然而這些方法頂多增加 CSRF 攻擊的困難度，甚至有些方法對於應付 CSRF 並沒有任何的助益，在使用上必須多加小心。話雖如此，上述手法中有一個手法被很多網站系統所應用，那就是將單一請求就可以完成的流程拆成多個請求。然而這個手法在實際應用上必須稍加變形，也就是在後面的請求中加上一個駭客 (或瀏覽器) 無法知悉的秘密。沒錯，我講的就是現在很多網站系統會在使用者進行重要請求時 (例如修改密碼) 要求使用者再次輸入密碼。因為駭客無法得知使用者的密碼，再加上密碼並不存在於瀏覽器之內 (記得要關閉瀏覽器記憶密碼的功能)，所以可以有效避免使用者遭受 CSRF 攻擊。需要特別注意的是，就算採用了再次輸入密碼的保護措施，依舊不可遺漏了 Synchronizer Token Pattern 的使用。

以上這些方法都是針對網站系統開發人員而言，那麼一般使用者該怎麼做才能保護自己免於 CSRF 的攻擊呢？OWASP 對此有三項建議：

不使用網站服務時儘快登出 (Logoff immediately after using a web application)。
嚴格來說，要做到這點越來越不容易，因為現在大部分網站系統就是強調 Alwasy On，努力增加使用者停留的時間。所以之間如何取捨，可就得由使用者自行衡量了。好消息是像網路銀行這類重要的網路系統通常在使用者停止操作後就會在很短的時間內自動登出，以減少遭受攻擊的機會。
不要使用瀏覽器記憶帳號/密碼的功能，也不要使用網站的”記住我”(Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login)。
針對一般性的網路瀏覽與存取重要網站服務採用不同的瀏覽器。如果不能採用不同的瀏覽器，至少應該使用不同的視窗，也就是不要使用分頁的方式 (Do not use the same browser to access sensitive applications and to surf freely the Internet; If you have to do both things at the same machine, do them with separate browsers)。
瀏覽器的選擇除了受到電腦環境的限制外，往往還跟使用者的習慣有很大的關係，因此採用不同的瀏覽器說起來很容易，但是卻很少使用者會這麼勤勞。好在現在已經有部分瀏覽器 (Firefox、Chrome) 推出所謂私密瀏覽的功能，我們可以使用標準模式來進行一般性的網路瀏覽，並透過私密瀏覽來存取重要的網站服務。因為私密瀏覽是一個獨立的空間，與標準模式下的空間彼此互不相干，簡單來說就是在私密瀏覽內的登入資訊 (如 Session Token) 在標準模式下是不存在的。使用私密瀏覽除了可以避免 CSRF 的攻擊外，也可以避免留下任何存取的紀錄與軌跡，這點在使用公共電腦上網時顯得格外重要。

最後，OWASP 提供了 Java、.NET 與 PHP 的 Synchronizer Token Pattern 實作範例，有需要的讀者就請自行參考與取用了。

相關連結：