這種方法並非萬無一失，Referer的值是由瀏覽器提供的，雖然HTTP協議上有明確的要求，但是每個瀏覽器對於Referer的具體實現可能有差別，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，從理論上來講，這樣並不是很安全。在部分情況下，攻擊者可以隱藏，甚至修改自己請求的Referer。
2014年，W3C的Web應用安全工作組發佈了Referrer Policy草案，對瀏覽器該如何發送Referer做了詳細的規定。截止現在新版瀏覽器大部分已經支持了這份草案，我們終於可以靈活地控制自己網站的Referer策略了。新版的Referrer Policy規定了五種Referer策略：No Referrer、No Referrer When Downgrade、Origin Only、Origin When Cross-origin、和 Unsafe URL。之前就存在的三種策略：never、default和always，在新標準裡換了個名稱。他們的對應關係如下：
根據上面的表格因此需要把Referrer Policy的策略設置成same-origin，對於同源的鏈接和引用，會發送Referer，referer值為Host不帶Path；跨域訪問則不攜帶Referer。例如：aaa.com引用bbb.com的資源，不會發送Referer。
設置Referrer Policy的方法有三種：
- 在CSP設置
- 頁面頭部增加meta標籤
- a標籤增加referrerpolicy屬性
上面說的這些比較多，但我們可以知道一個問題：攻擊者可以在自己的請求中隱藏Referer。如果攻擊者將自己的請求這樣填寫：
那麼這個請求發起的攻擊將不攜帶Referer。
另外在以下情況下Referer沒有或者不可信：
1. IE6、7下使用window.location.href=url進行界面的跳轉，會丟失Referer。
2. IE6、7下使用window.open，也會缺失Referer。
3. HTTPS頁面跳轉到HTTP頁面，所有瀏覽器Referer都丟失。
4. 點擊Flash上到達另外一個網站的時候，Referer的情況就比較雜亂，不太可信。
無法確認來源域名情況
當Origin和Referer頭文件不存在時該怎麼辦？如果Origin和Referer都不存在，建議直接進行阻止，特別是如果您沒有使用隨機CSRF Token（參考下方）作為第二次檢查。
如何阻止外域請求
通過Header的驗證，我們可以知道發起請求的來源域名，這些來源域名可能是網站本域，或者子域名，或者有授權的第三方域名，又或者來自不可信的未知域名。
我們已經知道了請求域名是否是來自不可信的域名，我們直接阻止掉這些的請求，就能防禦CSRF攻擊了嗎？
且慢！當一個請求是頁面請求（比如網站的主頁），而來源是搜索引擎的鏈接（例如百度的搜索結果），也會被當成疑似CSRF攻擊。所以在判斷的時候需要過濾掉頁面請求情況，通常Header符合以下情況：
Accept: text/html
Method: GET
但相應的，頁面請求就暴露在了CSRF的攻擊範圍之中。如果你的網站中，在頁面的GET請求中對當前用戶做了什麼操作的話，防範就失效了。
例如，下面的頁面請求：
GET https://example.com/addComment?comment=XXX&dest=orderId
注：這種嚴格來說並不一定存在CSRF攻擊的風險，但仍然有很多網站經常把主文檔GET請求掛上參數來實現產品功能，但是這樣做對於自身來說是存在安全風險的。
另外，前面說過，CSRF大多數情況下來自第三方域名，但並不能排除本域發起。如果攻擊者有權限在本域發佈評論（含鏈接、圖片等，統稱UGC），那麼它可以直接在本域發起攻擊，這種情況下同源策略無法達到防護的作用。
綜上所述：同源驗證是一個相對簡單的防範方法，能夠防範絕大多數的CSRF攻擊。但這並不是萬無一失的，對於安全性要求較高，或者有較多用戶輸入內容的網站，我們就要對關鍵的接口做額外的防護措施。
CSRF Token
前面講到CSRF的另一個特徵是，攻擊者無法直接竊取到用戶的信息（Cookie，Header，網站內容等），僅僅是冒用Cookie中的信息。
而CSRF攻擊之所以能夠成功，是因為服務器誤把攻擊者發送的請求當成了用戶自己的請求。那麼我們可以要求所有的用戶請求都攜帶一個CSRF攻擊者無法獲取到的Token。服務器通過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開，也可以防範CSRF的攻擊。
原理
CSRF Token的防護策略分為三個步驟：
1. 將CSRF Token輸出到頁面中
首先，用戶打開頁面的時候，服務器需要給這個用戶生成一個Token，該Token通過加密算法對數據進行加密，一般Token都包括隨機字符串和時間戳的組合，顯然在提交時Token不能再放在Cookie中了，否則又會被攻擊者冒用。因此，為了安全起見Token最好還是存在服務器的Session中，之後在每次頁面加載時，使用JS遍歷整個DOM樹，對於DOM中所有的a和form標籤後加入Token。這樣可以解決大部分的請求，但是對於在頁面加載之後動態生成的HTML代碼，這種方法就沒有作用，還需要程序員在編碼時手動添加Token。
2. 頁面提交的請求攜帶這個Token
對於GET請求，Token將附在請求地址之後，這樣URL 就變成 http://url?csrftoken=tokenvalue。 而對於 POST 請求來說，要在 form 的最後加上：
這樣，就把Token以參數的形式加入請求了。
3. 服務器驗證Token是否正確
當用戶從客戶端得到了Token，再次提交給服務器的時候，服務器需要判斷Token的有效性，驗證過程是先解密Token，對比加密字符串以及時間戳，如果加密字符串一致且時間未過期，那麼這個Token就是有效的。
這種方法要比之前檢查Referer或者Origin要安全一些，Token可以在產生並放於Session之中，然後在每次請求時把Token從Session中拿出，與請求中的Token進行比對，但這種方法的比較麻煩的在於如何把Token以參數的形式加入請求。
下面將以Java為例，介紹一些CSRF Token的服務端校驗邏輯，代碼如下：
HttpServletRequest req = (HttpServletRequest)request;
HttpSession s = req.getSession();
// 從 session 中得到 csrftoken 屬性
String sToken = (String)s.getAttribute(“csrftoken”);
if(sToken == null){
// 產生新的 token 放入 session 中
sToken = generateToken();
s.setAttribute(“csrftoken”,sToken);
chain.doFilter(request, response);
} else{
// 從 HTTP 頭中取得 csrftoken
String xhrToken = req.getHeader(“csrftoken”);
// 從請求參數中取得 csrftoken
String pToken = req.getParameter(“csrftoken”);
if(sToken != null && xhrToken != null && sToken.equals(xhrToken)){
chain.doFilter(request, response);
}else if(sToken != null && pToken != null && sToken.equals(pToken)){
chain.doFilter(request, response);
}else{
request.getRequestDispatcher(“error.jsp”).forward(request,response);
}
}
代碼源自：IBM developerworks CSRF
這個Token的值必須是隨機生成的，這樣它就不會被攻擊者猜到，考慮利用Java應用程序的java.security.SecureRandom類來生成足夠長的隨機標記，替代生成算法包括使用256位BASE64編碼哈希，選擇這種生成算法的開發人員必須確保在散列數據中使用隨機性和唯一性來生成隨機標識。通常，開發人員只需為當前會話生成一次Token。在初始生成此Token之後，該值將存儲在會話中，並用於每個後續請求，直到會話過期。當最終用戶發出請求時，服務器端必須驗證請求中Token的存在性和有效性，與會話中找到的Token相比較。如果在請求中找不到Token，或者提供的值與會話中的值不匹配，則應中止請求，應重置Token並將事件記錄為正在進行的潛在CSRF攻擊。
分佈式校驗
在大型網站中，使用Session存儲CSRF Token會帶來很大的壓力。訪問單臺服務器session是同一個。但是現在的大型網站中，我們的服務器通常不止一臺，可能是幾十臺甚至幾百臺之多，甚至多個機房都可能在不同的省份，用戶發起的HTTP請求通常要經過像Ngnix之類的負載均衡器之後，再路由到具體的服務器上，由於Session默認存儲在單機服務器內存中，因此在分佈式環境下同一個用戶發送的多次HTTP請求可能會先後落到不同的服務器上，導致後面發起的HTTP請求無法拿到之前的HTTP請求存儲在服務器中的Session數據，從而使得Session機制在分佈式環境下失效，因此在分佈式集群中CSRF Token需要存儲在Redis之類的公共存儲空間。
由於使用Session存儲，讀取和驗證CSRF Token會引起比較大的複雜度和性能問題，目前很多網站採用Encrypted Token Pattern方式。這種方法的Token是一個計算出來的結果，而非隨機生成的字符串。這樣在校驗時無需再去讀取存儲的Token，只用再次計算一次即可。
這種Token的值通常是使用UserID、時間戳和隨機數，通過加密的方法生成。這樣既可以保證分佈式服務的Token一致，又能保證Token不容易被破解。
在token解密成功之後，服務器可以訪問解析值，Token中包含的UserID和時間戳將會被拿來被驗證有效性，將UserID與當前登錄的UserID進行比較，並將時間戳與當前時間進行比較。
總結
Token是一個比較有效的CSRF防護方法，只要頁面沒有XSS漏洞洩露Token，那麼接口的CSRF攻擊就無法成功。
但是此方法的實現比較複雜，需要給每一個頁面都寫入Token（前端無法使用純靜態頁面），每一個Form及Ajax請求都攜帶這個Token，後端對每一個接口都進行校驗，並保證頁面Token及請求Token一致。這就使得這個防護策略不能在通用的攔截上統一攔截處理，而需要每一個頁面和接口都添加對應的輸出和校驗。這種方法工作量巨大，且有可能遺漏。
驗證碼和密碼其實也可以起到CSRF Token的作用哦，而且更安全。
為什麼很多銀行等網站會要求已經登錄的用戶在轉賬時再次輸入密碼，現在是不是有一定道理了？
雙重Cookie驗證
在會話中存儲CSRF Token比較繁瑣，而且不能在通用的攔截上統一處理所有的接口。
那麼另一種防禦措施是使用雙重提交Cookie。利用CSRF攻擊不能獲取到用戶Cookie的特點，我們可以要求Ajax和表單請求攜帶一個Cookie中的值。
雙重Cookie採用以下流程：
- 在用戶訪問網站頁面時，向請求域名注入一個Cookie，內容為隨機字符串（例如csrfcookie=v8g9e4ksfhw）。
- 在前端向後端發起請求時，取出Cookie，並添加到URL的參數中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
- 後端接口驗證Cookie中的字段與URL參數中的字段是否一致，不一致則拒絕。
此方法相對於CSRF Token就簡單了許多。可以直接通過前後端攔截的的方法自動化實現。後端校驗也更加方便，只需進行請求中字段的對比，而不需要再進行查詢和存儲Token。
當然，此方法並沒有大規模應用，其在大型網站上的安全性還是沒有CSRF Token高，原因我們舉例進行說明。
由於任何跨域都會導致前端無法獲取Cookie中的字段（包括子域名之間），於是發生瞭如下情況：
- 如果用戶訪問的網站為www.a.com，而後端的api域名為api.a.com。那麼在www.a.com下，前端拿不到api.a.com的Cookie，也就無法完成雙重Cookie認證。
- 於是這個認證Cookie必須被種在a.com下，這樣每個子域都可以訪問。
- 任何一個子域都可以修改a.com下的Cookie。
- 某個子域名存在漏洞被XSS攻擊（例如upload.a.com）。雖然這個子域下並沒有什麼值得竊取的信息。但攻擊者修改了a.com下的Cookie。
- 攻擊者可以直接使用自己配置的Cookie，對XSS中招的用戶再向www.a.com下，發起CSRF攻擊。
總結
用雙重Cookie防禦CSRF的優點：
- 無需使用Session，適用面更廣，易於實施。
- Token儲存於客戶端中，不會給服務器帶來壓力。
- 相對於Token，實施成本更低，可以在前後端統一攔截校驗，而不需要一個個接口和頁面添加。
缺點
- Cookie中增加了額外的字段。
- 如果有其他漏洞（例如XSS），攻擊者可以注入Cookie，那麼該防禦方式失效。
- 難以做到子域名的隔離。
- 為了確保Cookie傳輸安全，採用這種防禦方式的最好確保用整站HTTPS的方式，如果還沒切HTTPS的使用這種方式也會有風險。
Samesite Cookie屬性
防止CSRF攻擊的辦法已經有上面的預防措施。為了從源頭上解決這個問題，Google起草了一份草案來改進HTTP協議，那就是為Set-Cookie響應頭新增Samesite屬性，它用來標明這個 Cookie是個“同站 Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite 有兩個屬性值，分別是 Strict 和 Lax，下面分別講解：
Samesite=Strict
這種稱為嚴格模式，表明這個 Cookie 在任何情況下都不可能作為第三方 Cookie，絕無例外。比如說 b.com 設置瞭如下 Cookie：
Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
我們在 a.com 下發起對 b.com 的任意請求，foo 這個 Cookie 都不會被包含在 Cookie 請求頭中，但 bar 會。舉個實際的例子就是，假如淘寶網站用來識別用戶登錄與否的 Cookie 被設置成了 Samesite=Strict，那麼用戶從百度搜索頁面甚至天貓頁面的鏈接點擊進入淘寶後，淘寶都不會是登錄狀態，因為淘寶的服務器不會接受到那個 Cookie，其它網站發起的對淘寶的任意請求都不會帶上那個 Cookie。
Samesite=Lax
這種稱為寬鬆模式，比 Strict 放寬了點限制：假如這個請求是這種請求（改變了當前頁面或者打開了新頁面）且同時是個GET請求，則這個Cookie可以作為第三方Cookie。比如說 b.com設置瞭如下Cookie：
Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
Set-Cookie: baz=3
當用戶從 a.com 點擊鏈接進入 b.com 時，foo 這個 Cookie 不會被包含在 Cookie 請求頭中，但 bar 和 baz 會，也就是說用戶在不同網站之間通過鏈接跳轉是不受影響了。但假如這個請求是從 a.com 發起的對 b.com 的異步請求，或者頁面跳轉是通過表單的 post 提交觸發的，則bar也不會發送。
生成Token放到Cookie中並且設置Cookie的Samesite，Java代碼如下：
private void addTokenCookieAndHeader(HttpServletRequest httpRequest, HttpServletResponse httpResponse) {
//生成token
String sToken = this.generateToken();
//手動添加Cookie實現支持“Samesite=strict”
//Cookie添加雙重驗證
String CookieSpec = String.format("%s=%s; Path=%s; HttpOnly; Samesite=Strict", this.determineCookieName(httpRequest), sToken, httpRequest.getRequestURI());
httpResponse.addHeader("Set-Cookie", CookieSpec);
httpResponse.setHeader(CSRF_TOKEN_NAME, token);
}
代碼源自OWASP Cross-Site_Request_Forgery #Implementation example
我們應該如何使用SamesiteCookie
如果SamesiteCookie被設置為Strict，瀏覽器在任何跨域請求中都不會攜帶Cookie，新標籤重新打開也不攜帶，所以說CSRF攻擊基本沒有機會。
但是跳轉子域名或者是新標籤重新打開剛登陸的網站，之前的Cookie都不會存在。尤其是有登錄的網站，那麼我們新打開一個標籤進入，或者跳轉到子域名的網站，都需要重新登錄。對於用戶來講，可能體驗不會很好。
如果SamesiteCookie被設置為Lax，那麼其他網站通過頁面跳轉過來的時候可以使用Cookie，可以保障外域連接打開頁面時用戶的登錄狀態。但相應的，其安全性也比較低。
另外一個問題是Samesite的兼容性不是很好，現階段除了從新版Chrome和Firefox支持以外，Safari以及iOS Safari都還不支持，現階段看來暫時還不能普及。
而且，SamesiteCookie目前有一個致命的缺陷：不支持子域。例如，種在topic.a.com下的Cookie，並不能使用a.com下種植的SamesiteCookie。這就導致了當我們網站有多個子域名時，不能使用SamesiteCookie在主域名存儲用戶登錄信息。每個子域名都需要用戶重新登錄一次。
總之，SamesiteCookie是一個可能替代同源驗證的方案，但目前還並不成熟，其應用場景有待觀望。
防止網站被利用
前面所說的，都是被攻擊的網站如何做好防護。而非防止攻擊的發生，CSRF的攻擊可以來自：
- 攻擊者自己的網站。
- 有文件上傳漏洞的網站。
- 第三方論壇等用戶內容。
- 被攻擊網站自己的評論功能等。
對於來自黑客自己的網站，我們無法防護。但對其他情況，那麼如何防止自己的網站被利用成為攻擊的源頭呢？
- 嚴格管理所有的上傳接口，防止任何預期之外的上傳內容（例如HTML）。
- 添加Header X-Content-Type-Options: nosniff 防止黑客上傳HTML內容的資源（例如圖片）被解析為網頁。
- 對於用戶上傳的圖片，進行轉存或者校驗。不要直接使用用戶填寫的圖片鏈接。
- 當前用戶打開其他用戶填寫的鏈接時，需告知風險（這也是很多論壇不允許直接在內容中發佈外域鏈接的原因之一，不僅僅是為了用戶留存，也有安全考慮）。
CSRF其他防範措施
對於一線的程序員同學，我們可以通過各種防護策略來防禦CSRF，對於QA、SRE、安全負責人等同學，我們可以做哪些事情來提升安全性呢？
CSRF測試
CSRFTester是一款CSRF漏洞的測試工具，CSRFTester工具的測試原理大概是這樣的，使用代理抓取我們在瀏覽器中訪問過的所有的連接以及所有的表單等信息，通過在CSRFTester中修改相應的表單等信息，重新提交，相當於一次偽造客戶端請求，如果修改後的測試請求成功被網站服務器接受，則說明存在CSRF漏洞，當然此款工具也可以被用來進行CSRF攻擊。
CSRFTester使用方法大致分下面幾個步驟：
- 步驟1：設置瀏覽器代理
CSRFTester默認使用Localhost上的端口8008作為其代理，如果代理配置成功，CSRFTester將為您的瀏覽器生成的所有後續HTTP請求生成調試消息。
- 步驟2：使用合法賬戶訪問網站開始測試
我們需要找到一個我們想要為CSRF測試的特定業務Web頁面。找到此頁面後，選擇CSRFTester中的“開始錄製”按鈕並執行業務功能；完成後，點擊CSRFTester中的“停止錄製”按鈕；正常情況下，該軟件會全部遍歷一遍當前頁面的所有請求。
- 步驟3：通過CSRF修改並偽造請求
之後，我們會發現軟件上有一系列跑出來的記錄請求，這些都是我們的瀏覽器在執行業務功能時生成的所有GET或者POST請求。通過選擇列表中的某一行，我們現在可以修改用於執行業務功能的參數，可以通過點擊對應的請求修改query和form的參數。當修改完所有我們希望誘導用戶form最終的提交值，可以選擇開始生成HTML報告。
- 步驟4：拿到結果如有漏洞進行修復
首先必須選擇“報告類型”。報告類型決定了我們希望受害者瀏覽器如何提交先前記錄的請求。目前有5種可能的報告：表單、iFrame、IMG、XHR和鏈接。一旦選擇了報告類型，我們可以選擇在瀏覽器中啟動新生成的報告，最後根據報告的情況進行對應的排查和修復。
CSRF監控
對於一個比較複雜的網站系統，某些項目、頁面、接口漏掉了CSRF防護措施是很可能的。
一旦發生了CSRF攻擊，我們如何及時的發現這些攻擊呢？
CSRF攻擊有著比較明顯的特徵：
- 跨域請求。
- GET類型請求Header的MIME類型大概率為圖片，而實際返回Header的MIME類型為Text、JSON、HTML。
我們可以在網站的代理層監控所有的接口請求，如果請求符合上面的特徵，就可以認為請求有CSRF攻擊嫌疑。我們可以提醒對應的頁面和項目負責人，檢查或者 Review其CSRF防護策略。
個人用戶CSRF安全的建議
經常上網的個人用戶，可以採用以下方法來保護自己：
- 使用網頁版郵件的瀏覽郵件或者新聞也會帶來額外的風險，因為查看郵件或者新聞消息有可能導致惡意代碼的攻擊。
- 儘量不要打開可疑的鏈接，一定要打開時，使用不常用的瀏覽器。
總結
簡單總結一下上文的防護策略：
- CSRF自動防禦策略：同源檢測（Origin 和 Referer 驗證）。
- CSRF主動防禦措施：Token驗證 或者 雙重Cookie驗證 以及配合Samesite Cookie。
- 保證頁面的冪等性，後端接口不要在GET頁面中做用戶操作。
為了更好的防禦CSRF，最佳實踐應該是結合上面總結的防禦措施方式中的優缺點來綜合考慮，結合當前Web應用程序自身的情況做合適的選擇，才能更好的預防CSRF的發生。
歷史案例
WordPress的CSRF漏洞
2012年3月份，WordPress發現了一個CSRF漏洞，影響了WordPress 3.3.1版本，WordPress是眾所周知的博客平臺，該漏洞可以允許攻擊者修改某個Post的標題，添加管理權限用戶以及操作用戶賬戶，包括但不限於刪除評論、修改頭像等等。具體的列表如下:
- Add Admin/User
- Delete Admin/User
- Approve comment
- Unapprove comment
- Delete comment
- Change background image
- Insert custom header image
- Change site title
- Change administrator's email
- Change Wordpress Address
- Change Site Address
那麼這個漏洞實際上就是攻擊者引導用戶先進入目標的WordPress，然後點擊其釣魚站點上的某個按鈕，該按鈕實際上是表單提交按鈕，其會觸發表單的提交工作，添加某個具有管理員權限的用戶，實現的碼如下：
CSRF Exploit to add Administrator
YouTube的CSRF漏洞
2008年，有安全研究人員發現，YouTube上幾乎所有用戶可以操作的動作都存在CSRF漏洞。如果攻擊者已經將視頻添加到用戶的“Favorites”，那麼他就能將他自己添加到用戶的“Friend”或者“Family”列表，以用戶的身份發送任意的消息，將視頻標記為不宜的，自動通過用戶的聯繫人來共享一個視頻。例如，要把視頻添加到用戶的“Favorites”，攻擊者只需在任何站點上嵌入如下所示的IMG標籤：
攻擊者也許已經利用了該漏洞來提高視頻的流行度。例如，將一個視頻添加到足夠多用戶的“Favorites”，YouTube就會把該視頻作為“Top Favorites”來顯示。除提高一個視頻的流行度之外，攻擊者還可以導致用戶在毫不知情的情況下將一個視頻標記為“不宜的”，從而導致YouTube刪除該視頻。
這些攻擊還可能已被用於侵犯用戶隱私。YouTube允許用戶只讓朋友或親屬觀看某些視頻。這些攻擊會導致攻擊者將其添加為一個用戶的“Friend”或“Family”列表，這樣他們就能夠訪問所有原本只限於好友和親屬表中的用戶觀看的私人的視頻。
攻擊者還可以通過用戶的所有聯繫人名單（“Friends”、“Family”等等）來共享一個視頻，“共享”就意味著發送一個視頻的鏈接給他們，當然還可以選擇附加消息。這條消息中的鏈接已經並不是真正意義上的視頻鏈接，而是一個具有攻擊性的網站鏈接，用戶很有可能會點擊這個鏈接，這便使得該種攻擊能夠進行病毒式的傳播。
參考文獻
- Mozilla wiki. Security-Origin.
- OWASP. Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet.
- Gmail Security Hijack Case. Google-Gmail-Security-Hijack.
- Netsparker Blog. Same-Site-Cookie-Attribute-Prevent-Cross-site-Request-Forgery.
- MDN. Same-origin_policy#IE_Exceptions.
下期預告
前端安全系列文章將對XSS、CSRF、網絡劫持、Hybrid安全等安全議題展開論述。下期我們要討論的是網絡劫持，敬請期待。
劉燁，美團點評前端開發工程師，負責外賣用戶端前端業務。
歡迎加入美團前端安全技術交流群，跟作者零距離交流。如想進群，請加美美同學的微信（微信號：MTDPtech01），回覆：前端安全，美美會自動拉你進群。
閱讀更多 美團技術團隊 的文章
