如何挫敗攻擊者的入侵企圖。

Jesus Rodriguez發(fā)問(wèn)：

我的問(wèn)題涉及JavaScript安全性。

請(qǐng)大家想象一下，如果您正在某種認(rèn)證系統(tǒng)中使用JavaScript框架（例如Backbone或者AngularJS），而且需要端點(diǎn)驗(yàn)證機(jī)制以保障安全。這樣的情景似乎沒(méi)什么難度，畢竟決定權(quán)始終掌握在服務(wù)器手中、而且在我們進(jìn)行任何操作前都會(huì)通過(guò)驗(yàn)證檢查其是否符合規(guī)定。

但是如果整個(gè)流程不涉及服務(wù)器，對(duì)安全性的要求還能不能成為現(xiàn)實(shí)？

舉例來(lái)說(shuō)，如果您擁有一套客戶(hù)端路由系統(tǒng)而且打算通過(guò)保護(hù)具體線路來(lái)鞏固用戶(hù)登錄的安全性。在這種情況下，大家需要首先向服務(wù)器發(fā)送ping指令來(lái)查詢(xún)自己是否有權(quán)訪問(wèn)受保護(hù)的線路，接著再執(zhí)行后續(xù)操作。問(wèn)題在于，當(dāng)我們ping向服務(wù)器時(shí)，系統(tǒng)會(huì)將服務(wù)器響應(yīng)結(jié)果保存為一個(gè)變量。這樣在下一次使用這條專(zhuān)有線路時(shí)，系統(tǒng)會(huì)自動(dòng)檢查您是否已經(jīng)登錄（而不再重復(fù)ping向服務(wù)器），而僅僅通過(guò)上一次響應(yīng)結(jié)果決定您的申請(qǐng)是否通過(guò)。

聽(tīng)起來(lái)似乎有機(jī)可乘，那么通過(guò)修改變量來(lái)達(dá)成訪問(wèn)到底可不可行？

坦白講，我對(duì)于安全及JavaScript方面的知識(shí)了解不太多，但這樣變量只存在于模塊模式中的專(zhuān)有部分而非全局環(huán)境當(dāng)中。這里只涉及獲取方而無(wú)關(guān)于設(shè)定方，如果看來(lái)，我們似乎有機(jī)會(huì)針對(duì)其加以破解。

發(fā)送機(jī)密數(shù)據(jù)

Joachim Sauer的回答（獲得66票支持）：

破解過(guò)程非常簡(jiǎn)單：任何依賴(lài)于客戶(hù)端的安全機(jī)制都會(huì)按我們的要求進(jìn)行操作，因此只要攻擊者獲得控制權(quán)、接下來(lái)的入侵任務(wù)將手到擒來(lái)。

大家可以在客戶(hù)端上進(jìn)行安全檢查，但檢查的對(duì)象實(shí)際上只涉及“緩存”內(nèi)容（這是為了避免與服務(wù)器之間的高昂往返成本，如果客戶(hù)端已經(jīng)了解到響應(yīng)內(nèi)容為‘否’，那么直接從緩存內(nèi)讀取結(jié)果即可、無(wú)需再與服務(wù)器進(jìn)行通信）。

如果大家希望保障一組用戶(hù)的安全，請(qǐng)確保這些用戶(hù)的客戶(hù)端永遠(yuǎn)無(wú)法獲取服務(wù)器響應(yīng)信息。因?yàn)橐坏┐蠹蚁蚩蛻?hù)端發(fā)送“機(jī)密數(shù)據(jù)”，那么即使是加上了“請(qǐng)不要顯示其內(nèi)容”的指示，攻擊者也能夠輕松通過(guò)禁用對(duì)應(yīng)代碼對(duì)請(qǐng)求內(nèi)容進(jìn)行檢查。

如大家所見(jiàn)，這項(xiàng)答案并沒(méi)有真正提到任何與JavaScript及瀏覽器有關(guān)的細(xì)節(jié)。這是因?yàn)闊o(wú)論您所使用的是哪一種客戶(hù)端，其基本概念都是相通的。事實(shí)上，無(wú)論是胖客戶(hù)端（即傳統(tǒng)客戶(hù)端-服務(wù)器應(yīng)用）、傳統(tǒng)的Web應(yīng)用程序還是承載著大量客戶(hù)端JavaScript信息的單頁(yè)面應(yīng)用，都適用于前面所提到的假設(shè)。

一旦數(shù)據(jù)離開(kāi)服務(wù)器端，大家必須做好攻擊者有能力對(duì)其進(jìn)行全面訪問(wèn)的準(zhǔn)備。

另辟蹊徑

Benjamin Gruenbaum的回答（獲得17票支持）：

在首先閱讀Joachim的答案，然后再轉(zhuǎn)到這里。前一條答案涵蓋了客戶(hù)端安全漏洞的一般性出現(xiàn)原因，現(xiàn)在我們一起來(lái)看Benjamin對(duì)于解決這項(xiàng)問(wèn)題的建議。

這是一項(xiàng)無(wú)需手動(dòng)將每條請(qǐng)求發(fā)送至服務(wù)器端進(jìn)行驗(yàn)證的客戶(hù)端-服務(wù)器通信安全規(guī)劃：

大家仍然允許服務(wù)器擁有掌控權(quán)，服務(wù)器也仍然對(duì)客戶(hù)端發(fā)來(lái)的請(qǐng)求進(jìn)行驗(yàn)證，但整個(gè)過(guò)程都以透明化形式進(jìn)行。

假設(shè)通過(guò)HTTPS協(xié)議防止MITM（即中間人）攻擊。

• 客戶(hù)端與服務(wù)器間進(jìn)行首次握手時(shí)，服務(wù)器會(huì)針對(duì)客戶(hù)端生成一個(gè)公共密鑰，同時(shí)生成一個(gè)私有密鑰，從而構(gòu)成一套非對(duì)稱(chēng)式加密方案。客戶(hù)端在本地保存的是服務(wù)器的“公共”密鑰，并利用一條不會(huì)保存在任何位置的安全密碼進(jìn)行加密。
• 客戶(hù)端現(xiàn)在已經(jīng)離線?？蛻?hù)端希望執(zhí)行受信操作?？蛻?hù)端通過(guò)輸入密碼以獲取服務(wù)器的公共密鑰。
• 客戶(hù)端現(xiàn)在會(huì)根據(jù)對(duì)數(shù)據(jù)的了解執(zhí)行操作，并在服務(wù)器對(duì)應(yīng)公共密鑰的輔助下對(duì)每項(xiàng)操作進(jìn)行加密。
• 當(dāng)客戶(hù)端處于在線狀態(tài)時(shí)，客戶(hù)端會(huì)向受公共密鑰加密的服務(wù)器發(fā)送自身ID以及所有相關(guān)操作。
•  服務(wù)器負(fù)責(zé)對(duì)操作進(jìn)行加密，如果加密格式無(wú)誤，則信任這些操作確實(shí)來(lái)自客戶(hù)端。

備注：

• 我們絕不能將客戶(hù)端的密碼保存在任何位置，否則攻擊者將有機(jī)會(huì)取得密鑰并實(shí)施自己的惡意操作。這套方案的安全性依賴(lài)于服務(wù)器為客戶(hù)端所生成的密鑰的完整性。當(dāng)需要使用該密鑰時(shí)，服務(wù)器仍然會(huì)對(duì)客戶(hù)端進(jìn)行驗(yàn)證。
• 我們實(shí)際上仍然需要仰仗服務(wù)器的安全機(jī)制而非客戶(hù)端，客戶(hù)端執(zhí)行的每項(xiàng)操作都需要經(jīng)過(guò)服務(wù)器的驗(yàn)證。
•  我們可以在Web Workers中運(yùn)行外部腳本。請(qǐng)注意，每一條JSONP請(qǐng)求如今都有可能引發(fā)嚴(yán)重的安全問(wèn)題。我們需要不計(jì)一切代價(jià)保護(hù)密鑰。一旦密鑰丟失，攻擊者可以輕而易舉地偽裝成用戶(hù)并實(shí)施惡意活動(dòng)。
•  這樣的處理方式符合“不ping向服務(wù)器”的要求。攻擊者無(wú)法簡(jiǎn)單利用偽造數(shù)據(jù)模仿HTTP請(qǐng)求，只要密鑰沒(méi)有泄露、一切惡意活動(dòng)都不可能實(shí)現(xiàn)。
•  Joachim的回答仍然正確，我們事實(shí)上仍然將所有驗(yàn)證工作留給了服務(wù)器。惟一的區(qū)別在于，現(xiàn)在我們不必在每次操作時(shí)都要求服務(wù)器驗(yàn)證密碼。大家只需要在提交內(nèi)容或者更新數(shù)據(jù)時(shí)才直接面向服務(wù)器。我們所做的一切工作都是為了在客戶(hù)端保存受信密鑰，并且保證客戶(hù)端重新驗(yàn)證的順利進(jìn)行。
•  對(duì)于單頁(yè)面應(yīng)用（例如Angular）而言，這是一套相當(dāng)通行的控制方案。
•  我之所以將服務(wù)器的公共密鑰稱(chēng)為“公共”，是因?yàn)镽SA等方案使用過(guò)同樣的形容字眼，而且意味著該密鑰屬于敏感信息、應(yīng)該受到嚴(yán)格保護(hù)。
•  我不會(huì)把密碼保存在任何存儲(chǔ)機(jī)制當(dāng)中。我需要確保用戶(hù)每一次運(yùn)行離線代碼時(shí)都必須提交“離線”密碼。
• ?不要使用自己的加密機(jī)制：請(qǐng)務(wù)必使用知名度較高的可靠加密庫(kù)，例如斯坦福大學(xué)的認(rèn)證機(jī)制。

請(qǐng)認(rèn)真閱讀并掌握這套推薦方案。在大家將此認(rèn)證機(jī)制推向?qū)嶋H操作之前，請(qǐng)先向安全專(zhuān)家咨詢(xún)其可行性及潛在影響。這項(xiàng)問(wèn)題非常嚴(yán)重，實(shí)施過(guò)程并不輕松而且很容易在執(zhí)行中出現(xiàn)錯(cuò)誤。

最關(guān)鍵的一點(diǎn)在于，千萬(wàn)不要讓其它腳本介入到頁(yè)面當(dāng)中，這意味著我們只能通過(guò)Web Workers引入外部腳本。我們絕不能輕信其它外部腳本，因?yàn)槠渲泻芸赡軡摲赡茉谟脩?hù)登陸時(shí)截獲密碼的惡意內(nèi)容。

如果大家無(wú)法完全肯定腳本安全性或者推遲其執(zhí)行（也就是說(shuō)，該腳本不應(yīng)該成為事件的訪問(wèn)對(duì)象，而只作為同步代碼），請(qǐng)務(wù)必向用戶(hù)發(fā)出提示而且不要使用內(nèi)嵌密碼字段。另外，不要把密碼內(nèi)容保存在變量當(dāng)中——再次強(qiáng)調(diào)，只有百分之百確信用戶(hù)的計(jì)算機(jī)不存在安全漏洞后才能這么做（當(dāng)然，這又會(huì)涉及到服務(wù)器對(duì)客戶(hù)端的驗(yàn)證）。

我還是要再次提醒各位，我們要以懷疑的態(tài)度審視客戶(hù)端，這一點(diǎn)在Joachim的回答中也已經(jīng)表達(dá)得非常清楚。在新機(jī)制下，我們只不過(guò)可以在工作開(kāi)始之前擺脫ping服務(wù)器這一步驟。

任何人都不可信

nvoigt的回答（獲得7票支持）：

游戲行業(yè)有一句名言：“客戶(hù)端掌握在敵人手中”。任何運(yùn)行在外部安全區(qū)域（例如服務(wù)器）中的代碼都有遭到侵襲的可能。要不要真正運(yùn)行我們提供的“安全代碼”完全由客戶(hù)端決定，用戶(hù)只能在有限的范圍內(nèi)做出選擇。不過(guò)在本地代碼方面，我們至少可以通過(guò)自動(dòng)混淆機(jī)制保護(hù)代碼內(nèi)容；也就是說(shuō)，必須是擁有出色編程能力的攻擊者才有可能跨過(guò)這道障礙，從混淆機(jī)制的重重迷霧下看清JS與純文本信息的真面目。

攻擊活動(dòng)所需要的準(zhǔn)備工作非常簡(jiǎn)明：一臺(tái)代理服務(wù)器外加一個(gè)文本編輯器，基本上已經(jīng)足夠了。誠(chéng)然，攻擊者需要對(duì)編程擁有相當(dāng)程度的了解，但利用文本編輯器修改腳本內(nèi)容可比直接編寫(xiě)一套可以執(zhí)行的注入代碼簡(jiǎn)單得多。

本文標(biāo)題：在瀏覽器中攻破JavaScript到底有多輕松？
文章位置：http://uogjgqi.cn/article/dhijihh.html