摘要：下面就是對(duì)這種攻擊原理的介紹以及預(yù)防方法。針對(duì)該漏洞的特點(diǎn)，通過(guò)覆蓋數(shù)組構(gòu)造函數(shù)以竊取暴露返回?cái)?shù)組，而現(xiàn)在大多數(shù)瀏覽器還無(wú)法防范這種攻擊。在上周的挪威開發(fā)者大會(huì)上，我做了一個(gè)針對(duì)劫持漏洞的演示。

注：作者發(fā)表這篇文章的時(shí)間較早，某些方法可能并不是最好的解決方案，但針對(duì)這種漏洞進(jìn)行的攻擊還依然可見(jiàn)，如早期的：QQMail郵件泄露漏洞。直到現(xiàn)在，你在某些郵箱打開一個(gè)外部鏈妝，依然會(huì)有安全警告提示。下面就是對(duì)這種攻擊原理的介紹以及預(yù)防方法。

不久之前，我寫了一篇文章《一個(gè)微妙的JSON漏洞》，文中講到這個(gè)漏洞可能會(huì)導(dǎo)致敏感信息泄露。針對(duì)該漏洞的特點(diǎn)，通過(guò)覆蓋JavaScript數(shù)組構(gòu)造函數(shù)以竊取(暴露)JSON返回?cái)?shù)組，而現(xiàn)在大多數(shù)瀏覽器還無(wú)法防范這種攻擊。

然而，通過(guò)和微軟的Scott Hanselman交流，我了解到另外一個(gè)方法可能會(huì)影響更多的瀏覽器。在上周的挪威開發(fā)者大會(huì)上，我做了一個(gè)針對(duì)Json劫持漏洞的演示。

在我進(jìn)一步講之前，我先說(shuō)一說(shuō)，這個(gè)漏洞可能帶來(lái)的影響。

在以下條件下，會(huì)出現(xiàn)這個(gè)漏洞：首先暴露JSON服務(wù)，并且該服務(wù)會(huì)返回敏感數(shù)據(jù)；返回JSON數(shù)組；對(duì)GET請(qǐng)求做出響應(yīng)；發(fā)送這個(gè)請(qǐng)求的瀏覽器啟用了JavaScript并且支持defineSetter方法。

如果我們不使用JSON發(fā)送敏感數(shù)據(jù)，或者只對(duì)報(bào)文請(qǐng)求做出響應(yīng)，那么我們的網(wǎng)站就不存在這個(gè)漏洞。

我不喜歡用流程圖展示這個(gè)過(guò)程，我會(huì)盡量用圖表描述。在第一頁(yè)截圖上，我們可以看到不知情的受害者登陸漏洞網(wǎng)站，漏洞網(wǎng)站返回了一個(gè)身份認(rèn)證的cookie。

我們都可能收到過(guò)一些垃圾郵件，郵件中附有鏈接，發(fā)送者聲稱這有一段搞笑視頻。這些大量的垃圾郵件都是一些別有用心的人發(fā)的。

但是實(shí)際上，這些鏈接指向的是那些壞家伙自己網(wǎng)站。當(dāng)我們點(diǎn)擊了鏈接，接下來(lái)的兩個(gè)步驟會(huì)迅速進(jìn)行。第一，我們的瀏覽器向這些網(wǎng)站發(fā)送請(qǐng)求。

第二，那些網(wǎng)站會(huì)響應(yīng)一些包含JavaScript的HTML。這些JavaScript會(huì)帶一個(gè)script標(biāo)記。當(dāng)瀏覽器檢測(cè)到script標(biāo)記，它就會(huì)向那些漏洞網(wǎng)站再發(fā)一個(gè)下載腳本的GET請(qǐng)求，攜帶著身份驗(yàn)證的cookie。

這樣，那些壞家伙就偽裝成了受害者的瀏覽器，利用其身份發(fā)出了一個(gè)包含敏感數(shù)據(jù)的JSON請(qǐng)求。接著，把JSON加載為可執(zhí)行的JavaScript，這樣以來(lái)，那些黑客就能夠獲取到這些數(shù)據(jù)。
為了加深理解，我們可以看看一個(gè)攻擊的實(shí)際代碼。假如漏洞網(wǎng)站返回帶有敏感數(shù)據(jù)的JSON響應(yīng)通過(guò)如下方式發(fā)送：

[Authorize]
publicJsonResultAdminBalances(){
    varbalances=new[]{
        new{Id=1,Balance=3.14},
        new{Id=2,Balance=2.72},
        new{Id=3,Balance=1.62}
    };
    returnJson(balances);
}

需要說(shuō)明的是，上面的演示不是專門針對(duì)ASP.NET或者ASP.NET MVC，我僅僅是恰巧用ASP.NET MVC來(lái)演示這個(gè)漏洞而已。
假如這是HomeController的一種方法，我們通過(guò)對(duì)/Home/AdminBalances發(fā)送了一個(gè)GET請(qǐng)求，并且返回如下JSON文本：

[{“Id”:1,”Balance”:3.14},{“Id”:2,”Balance”:2.72},{“Id”:3,”Balance”:1.62}]

注意，我定義這個(gè)方法時(shí)使用了Authorize屬性，用來(lái)驗(yàn)證請(qǐng)求者的身份。所以一個(gè)匿名的GET請(qǐng)求將不會(huì)得到敏感數(shù)據(jù)。
重要的是：這是一個(gè)JSON數(shù)組。包含JSON數(shù)組的文本是一個(gè)有效的JavaScript腳本，并且可以被執(zhí)行。僅僅包含JSON對(duì)象的腳本不是一個(gè)有效的JavaScript可執(zhí)行文件。
舉個(gè)例子，如果我們有一個(gè)包含如下JSON代碼的JavaScript文檔：

{“Id”:1,”Balance”:3.14}

并且有一個(gè)指向這個(gè)文檔的腳本標(biāo)簽：

這樣，我們會(huì)在HTML頁(yè)中得到一個(gè)JavaScript錯(cuò)誤。然而，倘若存在一個(gè)不幸的巧合，如果我們有一個(gè)script標(biāo)簽，這個(gè)標(biāo)簽指向僅僅含有一個(gè)JSON數(shù)組的文檔，這樣的話，這個(gè)標(biāo)簽就會(huì)被誤認(rèn)為是有效的JavaScript，并且數(shù)組會(huì)生效。
下面就讓我們看看那些別有用心的人的服務(wù)器上的HTML頁(yè)。

注*這里我們可以看到使用 Json Object 而不是Json Array返回你的數(shù)據(jù)，可以在一定程度上預(yù)防這種漏洞。

...


Object.prototype.__defineSetter__("Id",function(obj){alert(obj);});

看到了什么？黑客正在改變對(duì)象的原型，用defineSetter這種特殊方法，覆蓋JSON對(duì)象（Object）原本應(yīng)有的默認(rèn)行為。。
在這個(gè)例子中，一個(gè)命名合適的ID在任何時(shí)候都可以被設(shè)置到任何對(duì)象上時(shí)，一個(gè)匿名的函數(shù)將會(huì)被調(diào)用，這個(gè)函數(shù)將會(huì)利用alert 函數(shù)顯示屬性值。注意，這時(shí)腳本僅僅會(huì)將數(shù)據(jù)發(fā)回給那些壞家伙，而不會(huì)發(fā)送敏感數(shù)據(jù)。
就像之前提到的，壞家伙需要使我們?cè)诘卿浡┒淳W(wǎng)站后不久并且在會(huì)話仍舊有效時(shí)，訪問(wèn)他的惡意的網(wǎng)頁(yè)。通過(guò)含有惡意網(wǎng)站鏈接的郵件進(jìn)行釣魚攻擊的方式是很典型的。

如果你仍舊點(diǎn)擊鏈接登錄原網(wǎng)站，瀏覽器將會(huì)在加載腳本標(biāo)簽中引用的腳本并向網(wǎng)站發(fā)送你的身份驗(yàn)證cookie。直到連接上原網(wǎng)站，我們對(duì)JSON數(shù)據(jù)發(fā)出一 個(gè)有效的身份驗(yàn)證請(qǐng)求，并且會(huì)收到在我們?yōu)g覽器中響應(yīng)的有效數(shù)據(jù)。這些話可能聽著很熟悉，因?yàn)樗且粋€(gè)真的變種偽造跨站請(qǐng)求，之前我寫過(guò)這種情況。

因?yàn)樵贗E8上defineSetter是一個(gè)無(wú)效的方法，所以在IE8上看不到現(xiàn)象。我在Chrome和Firefox上都試過(guò)，都可以。
避免這個(gè)漏洞也很簡(jiǎn)單：或者從不發(fā)送JSON數(shù)組，或者只訪問(wèn)HTTP POST以獲得需要的數(shù)據(jù)。舉個(gè)例子：在ASP.NET MVC中，你可以用AcceptVerbsAttribute來(lái)實(shí)現(xiàn)：

[Authorize]
[AcceptVerbs(HttpVerbs.Post)]
publicJsonResultAdminBalances(){
    varbalances=new[]{
        new{Id=1,Balance=3.14},
        new{Id=2,Balance=2.72},
        new{Id=3,Balance=1.62}
    };
    returnJson(balances);
}

這個(gè)方法的一個(gè)問(wèn)題就是：像jQuery這樣的很多JS庫(kù)默認(rèn)都是用GET方式發(fā)送JSON請(qǐng)求，而不是POST。舉個(gè)例子，$.getJSON 默認(rèn)發(fā)起的是GET請(qǐng)求。所以，當(dāng)進(jìn)行這種JSON訪問(wèn)時(shí)，我們需要確信我們是用客戶端庫(kù)發(fā)起的POST請(qǐng)求。
ASP.NET和WCF JSON服務(wù)端實(shí)際上在對(duì)象中用了“d”屬性，包裹了他們的JSON，這我在另一篇文章中討論過(guò)：

必須經(jīng)過(guò)這些屬性獲得數(shù)據(jù)，似乎有些奇怪，但這需要通過(guò)一個(gè)客戶端代理來(lái)實(shí)現(xiàn)來(lái)去除“d”屬性，，以便不影響最終用戶。
在ASP.NET MVC下，絕大多數(shù)開發(fā)者沒(méi)有生成客戶端代理，而是使用jQuery和其他類似的庫(kù)，這樣一來(lái)使用“d”屬性的就有些尷尬。

注: 其實(shí)MVC的方法有點(diǎn)復(fù)雜，到這里我們可以看出，JSON劫持漏洞是要以在受豁者的瀏覽器上執(zhí)行JSON返回對(duì)象為前提的，其實(shí)Google使用了一種更加聰明的方法，通過(guò)添加“死循環(huán)”命令，防止黑客運(yùn)行這段腳本，可參見(jiàn)這篇文章：為什么谷歌的JSON響應(yīng)以while(1);開頭？

一些人可能會(huì)有疑問(wèn)：“為什么不在響應(yīng)一個(gè)GET請(qǐng)求之前，用一個(gè)特殊的首部對(duì)JSON服務(wù)進(jìn)行檢查？就像X-Requested- With:XMLHttpRequest或者Content-Type:application/json”。我認(rèn)為這可能是個(gè)過(guò)渡，因?yàn)榇蠖鄶?shù)的客戶端 庫(kù)會(huì)發(fā)送一種或兩種Header，但是瀏覽器響應(yīng)腳本標(biāo)簽的GET請(qǐng)求不這樣。

問(wèn)題是：在過(guò)去某個(gè)時(shí)候，用戶可能會(huì)發(fā)出合法的JSON GET請(qǐng)求，在這種情況下，這個(gè)漏洞可能會(huì)隱藏在用戶瀏覽器的正常請(qǐng)求之間。也是在此種情況下，當(dāng)瀏覽器發(fā)出GET請(qǐng)求，這種請(qǐng)求可能會(huì)緩存在瀏覽器和代 理服務(wù)器的緩沖區(qū)。我們可以嘗試著設(shè)置No-Cache header，這樣，我們信任瀏覽器和所有的代理服務(wù)器能夠正確地實(shí)現(xiàn)高速緩存并且信任用戶也不會(huì)被意外地覆蓋。

當(dāng)然，如果我們用SSL提供JSON文本，這個(gè)特定的緩存問(wèn)題將會(huì)很容易被解決。

注: 這里我們可以看到最好不要cache你的ajax請(qǐng)求，不過(guò)目前似乎所有的js庫(kù)默認(rèn)都是不啟用cache的。

Mozilla Developer Center發(fā)表的一篇文章中寫道：對(duì)象和數(shù)組初始化設(shè)定項(xiàng)在賦值時(shí)不應(yīng)該調(diào)用setters方法。這一點(diǎn)我同意。盡管有評(píng)論認(rèn)為：也許瀏覽器真的不應(yīng)該執(zhí)行腳本。

但 是在一天結(jié)束的時(shí)候，分派責(zé)任并不能使你的網(wǎng)站更加安全。這些瀏覽器的怪癖毛病將會(huì)時(shí)不時(shí)地出現(xiàn)。我們作為網(wǎng)站的開發(fā)者需要解決這些問(wèn)題。 Chrome2.0.172.31和Firefox3.0.11也有這個(gè)軟肋。IE8沒(méi)有這個(gè)問(wèn)題，因?yàn)樗恢С诌@種方法，我也沒(méi)有在IE7或者IE6中 試驗(yàn)過(guò)。

在我看來(lái)，在當(dāng)前的客戶端庫(kù)下，安全訪問(wèn)JSON的默認(rèn)方式應(yīng)該是POST，并且我們應(yīng)該選擇GET,而不是其他方式。您覺(jué)得呢？您所了解的其他平臺(tái)是怎么解決這個(gè)問(wèn)題的呢？我很想聽聽大家的想法。

原文：JSON Hijacking
翻譯：Tianyi_Ting 校對(duì)批注：newghost
轉(zhuǎn)自：OurJS