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

[[83508]]

Jesus Rodriguez發(fā)問：

我的問題涉及JavaScript安全性。

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

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

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

聽起來似乎有機(jī)可乘，那么通過修改變量來達(dá)成訪問到底可不可行？

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

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

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

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

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

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

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

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

另辟蹊徑

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

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

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

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

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

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

備注：

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

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

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

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

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

任何人都不可信

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

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

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