針對Node.js生態系統的隱藏屬性濫用攻擊

如今Node.js憑借其跨平臺、高性能的JavaScript執行環境，被廣泛應用于服務器端和桌面程序（如Skype）的開發。在過去幾年中，有報道稱其他動態編程語言（例如 PHP 和 Ruby）在共享對象方面是不安全的。然而，這種安全風險在 JavaScript 和 Node.js 程序中并沒有得到很好的研究和理解。

在本文中，通過對 Node.js 程序中客戶端和服務器端代碼之間的通信過程進行首次系統研究來填補這一空白。本文廣泛地識別了流行的 Node.js 程序中的幾個新漏洞。為了證明它們的安全含義，本研究設計并開發了一種新穎的可行攻擊，稱為隱藏屬性濫用 (HPA，hidden property abusing)。進一步分析表明，HPA 攻擊與現有的關于利用和攻擊效果的調查結果略有不同。通過 HPA 攻擊，遠程 Web 攻擊者可以獲得危險的能力，例如竊取機密數據、繞過安全檢查和發起 DoS（拒絕服務）攻擊。

為了幫助 Node.js 開發人員針對 HPA 審查他們的程序，本研究設計了一種名為 LYNX 的新型漏洞檢測和驗證工具（https://github.com/xiaofen9/Lynx ），該工具利用混合程序分析來自動揭示 HPA 漏洞，甚至合成漏洞利用。將 LYNX 應用于一組廣泛使用的 Node.js 程序，并確定了 15 個以前未知的漏洞。目前已經向 Node.js 社區報告了所有發現。其中 10 個被分配了 CVE，其中 8 個被評為“嚴重”或“高危”。這表明 HPA 攻擊可能會導致嚴重的安全威脅。

0x01 Introduction

Node.js 是一個跨平臺、高性能的 JavaScript 程序執行環境。它已被廣泛用于開發服務器端和桌面應用程序，例如 Skype、Slack 和 WhatsApp。根據最近的一項研究，Node.js 是連續三年（2017-2019 年）各種開發中使用最廣泛的技術。Node.js 的突出地位使其安全性變得至關重要。具體來說，一旦發現一個廣泛使用的模塊存在漏洞，大量的 Node.js 應用程序可能會因重用現象而受到影響。通過利用這些漏洞，遠程攻擊者可能會在易受攻擊的服務器端應用程序中濫用強大的特權 API 來發起嚴重攻擊，例如竊取機密數據或執行任意惡意代碼。

Node.js 程序是用動態編程語言 JavaScript 構建的。在過去的幾年里，一些動態語言，如 PHP和 Ruby，都面臨著常見的安全風險 CWE-915，其中內部對象屬性被不可信的用戶輸入不當修改。盡管有嚴重的安全后果，但在 JavaScript 和 Node.js 程序中并沒有很好地研究和理解這個問題。在本文中，首次系統地研究了 Node.js 程序中客戶端和服務器端代碼之間的對象共享和通信過程。確認 JavaScript 和 Node.js 程序中也存在上述安全風險。為了證明安全隱患，本文設計了一種名為隱藏屬性濫用 (HPA) 的新型攻擊，它使遠程 Web 攻擊者能夠獲得危險的能力，例如竊取機密數據、繞過安全檢查和發起拒絕服務攻擊。進一步分析表明，HPA 在許多方面與 PHP和 Ruby的現有發現不同，例如漏洞用和攻擊效果。

HPA 攻擊示例如上圖所示，遠程 Web 攻擊者向目標 Node.js 服務器程序發送精心設計的 JSON 數據，其中包含額外的意外屬性“I2”（稱為隱藏屬性）。然后，victim 程序正常處理惡意輸入負載。最后，I2 傳播到內部對象。如紅線所示，輸入的 I2 覆蓋并用沖突名稱替換受害者內部對象的關鍵屬性。因此，攻擊者可能會濫用隱藏屬性的傳播過程（即屬性傳播）來強大地操縱與受感染屬性相關的關鍵程序邏輯，例如通過為輸入的 I2 分配適當的值直接調用特權 API（即，”admin”）。

分析表明，受害者屬性可以是任何類型，例如關鍵函數或關鍵程序狀態。由于此特征，輸入驗證無法阻止攻擊者發起 HPA 攻擊，因為他們可能會通過覆蓋關鍵狀態或刪除所有安全檢查來禁用驗證邏輯。發現這種攻擊場景在實踐中非常普遍。為了幫助 Node.js 開發人員檢測和驗證其 Node.js 應用程序和模塊中新出現的 HPA 問題，設計并實現了一個名為 LYNX的漏洞檢測和驗證工具。LYNX 結合了靜態和動態分析的優點來跟蹤屬性傳播，識別隱藏的屬性，并生成相應的具體漏洞用于驗證目的。

0x02 Hidden Property Abusing

A.威脅模型

假設 Node.js 應用程序和模塊是良性但易受攻擊的。此外，假設目標應用程序正確實現了對象共享（即數據反序列化）。在此設置中，遠程 Web 攻擊者旨在使用 HPA 破壞易受攻擊的服務器端程序。為了利用該漏洞，攻擊者通過合法接口向受害應用程序發送精心設計的有效載荷。當惡意負載到達受害應用程序時，它會被視為正常數據并按常規處理。由于輸入對象和內部對象之間缺乏嚴格隔離，惡意負載會傳播到易受攻擊的 Node.js 模塊的內部對象。最后，一個關鍵的內部對象被破壞并發起攻擊。

B.運行示例

為了說明 HPA 攻擊，介紹了在熱門Node.js 框架“routing-controller”（npm 上每月下載量超過 63,000 次）中發現的真實漏洞。在這個例子中，展示了盡管這個易受攻擊的框架對不安全的外部數據強制執行全局輸入驗證，但攻擊者仍然可以利用 HPA 攻擊來篡改其驗證邏輯并引入任意惡意負載。

上圖顯示了攻擊細節。在第一步中，攻擊者在訪問受害框架的身份驗證 Web API login() 時向輸入對象添加了一個額外的屬性（即隱藏屬性）constructor: false。被調用后，身份驗證模塊將實例化一個名為 param 的對象并將其發送到參數處理程序，該處理程序負責驗證用戶輸入。為此，圖中的函數 transform() 通過將 param 與格式規范對象模式合并來構建驗證候選。如第二步所示，在構建這樣的候選對象時，隱藏屬性 constructor: false 進一步傳播到內部對象schema中。

上述傳播過程使攻擊者能夠通過劫持constructor的繼承鏈來禁用輸入驗證邏輯。在 JavaScript 中，每個對象都有一個指向原型對象的鏈接。當程序想要訪問一個對象的一個屬性時，不僅會在對象上搜索該屬性，還會在對象的原型上搜索該屬性，甚至是原型的原型類型，直到找到一個名稱匹配的屬性成立。因此，每個對象除了自己的屬性外，還有許多繼承的屬性。但是，如果存在位于搜索樹更高級別的沖突名稱屬性，則可以劫持這樣的繼承鏈（注意劫持過程不同于原型污染。

在第三步中，函數validate() 檢查候選對象中的所有屬性，以查看輸入對象是否合法。validate 內部調用函數 getSchema() 從候選中提取格式規范。然而由于劫持，函數 getSchema() 訪問偽造的構造函數（由紅色虛線指向）而不是真正的構造函數（由黑色虛線指向）。結果，用于驗證的最終格式對象由攻擊者通過隱藏屬性控制。要繞過輸入驗證，攻擊者只需將格式設置為無效值，例如 false。最后，如第四步所示，攻擊者可以讓惡意電子郵件通過驗證，并進一步對數據庫模塊進行 SQL 注入攻擊。

C.攻擊向量

遠程攻擊者可以傳播隱藏屬性來篡改某些內部狀態。一般來說，有兩種典型的攻擊向量。第一個稱為特定應用程序屬性操作（App-specifific attribute manipulation），它涉及篡改應用程序開發人員定義的某些內部屬性。二是原型繼承劫持（Prototype inheritance hijacking），劫持原型繼承鏈。值得注意的是，第二個攻擊向量不同于現有的攻擊，如原型污染。原型污染需要對原型進行修改。但是如運行示例所示，HPA 的攻擊者不需要篡改原型。

特定應用程序屬性操作：此攻擊向量針對易受攻擊的代碼，該代碼錯誤地向用戶控制的對象公開某些特定于應用程序的屬性（例如，訪問權限）。前圖中的I2 屬性應該由內部函數初始化和管理。但是，使用 HPA，攻擊者可能會將同名屬性傳播到內部對象，從而訪問敏感 API。此攻擊向量可用于濫用某些服務，例如大型應用程序中的訂單狀態。

原型繼承劫持：此向量劫持原型繼承鏈，以便攻擊者可以誘使易受攻擊的程序引用用戶控制的屬性，而不是從原型繼承的屬性。使用這個向量，攻擊者可以偽造許多內置屬性，甚至嵌套的原型屬性（發現的兩個漏洞是使用嵌套屬性來利用的）。如有必要，他們還可以偽造其他原型屬性，例如constructor.name。這個向量非常有用，因為許多 JavaScript 開發人員傾向于信任從原型繼承的屬性，并基于它們做出許多安全敏感的決定。

D.HPA與相關攻擊比較

在一些動態語言，如Ruby和PHP中，已經發現了修改動態對象屬性(CWE-915)不當的風險。本研究是第一個在 Node.js 中識別此類風險的工作。此外，發現 HPA 在多個方面與現有漏洞不同。

上表總結了 HPA 和 Ruby mass assignment 之間的區別，這是 CWE-915 導致的典型漏洞。首先，它們濫用不同的邏輯來傳遞有效載荷：HPA 利用對象共享將惡意對象傳遞給受害程序，而 Ruby mass分配濫用特定于框架的分配功能來修改分配左側的某些現有屬性。其次，HPA 可以引入具有文字值或嵌套對象的隱藏屬性，而質量分配有效載荷僅僅是文字值。第三，由于 Ruby 是一種強類型語言，大量賦值漏洞無法為受害對象創建新屬性。然而，JavaScript 更靈活，因此 HPA 可以向受害對象注入任意屬性，甚至允許隱藏屬性在到達目標對象之前通過多個變量傳播。運行示例是這樣的：隱藏屬性構造函數從輸入對象傳播到內部模式對象以攻擊輸入驗證邏輯。

值得注意的是，CWE-915 的漏洞不是反序列化錯誤（CWE-502）。具體來說，CWE-915 的范圍更窄，用于對象修改，并不一定利用反序列化過程。例如，HPA 不攻擊對象反序列化的邏輯。相反，它旨在修改內部對象的屬性。

0x03 LYNX Design and Implementation

A.定義

隱藏屬性：給定一個模塊，它包含一個輸入對象 Oinput 和一個內部對象 Ointernal。僅當滿足以下所有三個要求時，Oinput 中才存在隱藏屬性 Phidden：

? Phidden 屬于Ointernal 并且在模塊中被引用。

? 如果在 Oinput 中添加了具有相同名稱（即 Phidden）的沖突屬性，則可以修改 Ointernal 的 Phidden。

? Phidden 不是Oinput 的默認參數。這意味著在使用默認參數調用模塊時，Oinput 的 Phidden 不會被初始化。

為了幫助描述問題，使用“屬性載體”（property carrier）來表示所有帶有隱藏屬性的變量（包括 Ointernal 和 Oinput）。

有害的隱藏屬性：如果攻擊者可以濫用隱藏屬性將意外行為引入模塊，則該隱藏屬性被認為是有害的。在本文中，從以下三個方面考慮潛在的攻擊效果：

? 機密性：隱藏的屬性可能會導致敏感信息在被濫用時泄露。

? 完整性：攻擊者可能會破壞模塊中關鍵屬性的一致性或可信度。

? 可用性：攻擊者可能會違反應用程序對屬性的期望，由于意外錯誤情況導致拒絕服務攻擊。

B.挑戰與解決方案

本研究目標是設計和開發一個端到端系統，可以自動有效地檢測目標 Node.js 程序上的 HPA 安全問題。然而，由于以下兩個挑戰，這不是一項簡單的任務。

C1.如何發現 Node.js 程序的隱藏屬性？

現有技術無法完美解決這個問題。特別是，靜態分析可以輕松獲得目標程序的全貌，但通常會引入很高的誤報，尤其是在處理指向和回調問題時，發現這種情況在 Node.js 程序中非常常見。動態分析，如數據流跟蹤，適用于 1) 跟蹤輸入對象及其所有傳播，以及 2) 發現和標記相關的屬性載體，并將其對應的屬性視為潛在的隱藏屬性。然而，在實踐中發現動態跟蹤經常遺漏許多關鍵執行路徑和隱藏屬性，從而導致漏報。

解決方案：本文設計了一種混合方法，利用動態和靜態分析的優勢來發現隱藏的屬性。首先利用輕量級標簽系統動態跟蹤輸入對象和相關屬性載體，并將屬性載體的所有屬性作為隱藏屬性候選的一部分轉儲。為了發現盡可能多的執行路徑，尤其是關鍵路徑，遞歸地廣泛標記輸入對象并測試目標程序。其次，上述動態測試不可避免地會造成漏報。發現在許多情況下，即使成功標記了相應的屬性載體，關鍵的隱藏屬性仍然被忽略。為了緩解這個問題，通過貪婪地搜索可能被忽略的屬性來引入靜態分析。最后，收集結果并獲得隱藏屬性候選列表。

C2.在海量的隱藏屬性中，如何確定哪一個是有價值的、可被攻擊者利用的？

本文發現在收集到的隱藏屬性候選者中，并非所有候選者都有價值且可被攻擊者利用。其中許多甚至不會造成任何攻擊后果，因此應將其過濾掉。此外，已識別隱藏屬性的相應值通常具有特定要求和約束。因此，給定一個隱藏屬性候選者，攻擊者需要確定其危害性并計算其對應的值。

解決方案：利用符號執行來探索所有相關路徑，收集路徑約束，檢測敏感行為，并最終生成漏洞利用。

C.設計概述

LYNX 架構的概述如下圖所示，本文方法有兩個方面。在第一階段，LYNX 首先動態運行一個標簽系統，用于遞歸跟蹤輸入對象，并識別盡可能多的屬性載體。通過檢測目標 Node.js 代碼來實現動態標簽系統，然后通過使用常規輸入數據（例如測試用例）觸發其 API 來執行檢測的代碼。然后，LYNX 通過收集上述動態分析結果并應用靜態分析來搜索忽略的隱藏屬性，從而獲得候選隱藏屬性。特別地，LYNX 將前面動態分析步驟中記錄的必要信息單元化，分析目標 Node.js 程序的 AST（抽象語法樹），并檢測與屬性訪問相關的操作。最后，根據觀察修剪結果。

在第二階段，LYNX 首先生成帶有檢測到的隱藏屬性候選者的漏洞利用模板。然后，LYNX 運行符號執行來推理隱藏屬性的值并驗證相應的危害和攻擊后果。

D.識別隱藏屬性

（1）發現屬性載體

通過檢測目標 Node.js 程序來實現動態分析。在本節中，首先介紹標記和跟蹤輸入以及檢測屬性載體的檢測細節。然后，討論如何驅動和執行檢測的代碼。

標記和跟蹤輸入：為所有輸入對象添加標簽以跟蹤它們。新添加的標簽是一個新的屬性，它有一個唯一的鍵值對。例如，假設輸入對象 Oinput = {“email”:”a@ gmail.com”}，LYNX 使用新屬性檢測 Oinput。因此，新的輸入對象 O’input 是 {“email”:”a@ gmail.com”, unique_key: unique_value}。

當 Oinput 具有簡單的數據結構時，上述簡單的標簽添加過程有效。但是，當 Oinput 很復雜時，這種方法是不夠的。例如，當 Oinput 具有多個屬性（例如 Oinput .a 和 Oinput .b）時，這些子屬性可能會隨著不同的程序狀態而以不同的方式傳播。如果只為 Oinput 添加一個標簽，將無法跟蹤所有這些子屬性。因此，LYNX 遍歷 Oinput 并遞歸地將標簽注入不同的子屬性。例如，考慮上面具有兩個屬性的 Oinput，LYNX 分別在 Oinput、Oinput .a 和 Oinput .b 的基數中注入了三個不同的標簽。

標記方法在檢測屬性載體方面優于經典的數據流跟蹤（即不改變輸入的透明跟蹤），因為它更好地模擬了 HPA 的攻擊過程。例如，在某些情況下，被測試的程序包含一個按類型分配輸入的調度程序。在分析此類情況時，LYNX 會以與真實攻擊過程相同的方式修改輸入。如果修改改變了輸入類型，輸入可能會觸發另一個路徑。但是，經典方法可能仍會跟蹤原型輸入的路徑。因此，本文方法可以更準確地確定真實 HPA 負載可能觸發的真實執行路徑。

但是，改變原始輸入也可能帶來負面影響。例如，假設有一個檢查函數來清理輸入的某個屬性，如果 LYNX 為該屬性添加了一個標簽，程序可能會引發錯誤并退出。為了緩解這個問題，LYNX 應用了一次一個標簽的策略。在每一輪分析中，LYNX 只為其中一個屬性添加一個標簽，然后多次重復此步驟以測試所有屬性及其子屬性。

識別屬性載體：在向輸入添加標簽后，LYNX 使用新輸入執行程序并觀察標簽屬性如何傳播。如果 LYNX 發現標簽傳播到內部對象，它會將宿主對象標記為屬性載體。為此，通過攔截所有變量讀/寫操作來檢測目標 Node.js 程序。當這樣的操作發生在一個內部對象上時，LYNX 會遞歸地檢查這個對象的所有屬性和子屬性。如果檢測到一個標簽，這個對象會被標記為屬性載體，格式如下：< O,L,S >，其中O記錄屬性載體的對象名稱，L指向包含檢測對象的JavaScript文件，S記錄載體的可見范圍。在 LYNX 中，“.”用于通過連接不同的函數名稱來表示作用域。為了區分函數對象和變量對象，在函數類型作用域中添加了特殊的后綴_fun。有關范圍表示的更多詳細信息如下圖。

運行動態分析：LYNX 根據它們的類型運行檢測的目標 Node.js 程序。更具體地說，如果應用程序是基于 Web 的程序（例如 Web 應用程序），則 LYNX 會直接運行它。如果目標 Node.js 代碼在 Node.js 模塊中，LYNX 需要將其嵌入到一個簡單的 Node.js 測試應用程序中。然后，LYNX 調用目標 Node.js 模塊的公開 API。但是，在這種情況下，LYNX 需要為 API 提供一些適當的輸入，這通常很難自動生成。基于以下觀察緩解了這個問題：發現大多數 Node.js 模塊都是隨用例一起發布的（npm上 50 個最依賴的包中有 45 個具有直接可用的測試用例）。因此，LYNX 可以直接使用它們來驅動分析。

對于觸發 API，LYNX 目前支持兩種類型的對象共享方案。首先是JSON序列化，這也是最常用的方法。第二種方法是查詢字符串序列化。在 Node.js 生態系統中，許多請求解析模塊也支持將 URL 查詢字符串傳遞給對象。例如，一個名為 qs 的請求解析模塊（在 npm 上每月下載 1 億次）將查詢字符串轉換為單個對象（例如，從 ?a=1&b=2 到 {a:1,b:2}）。LYNX 通過記錄和重放 Web 請求來檢測查詢字符串中的隱藏屬性。

運行示例：為了說明 LYNX 如何識別屬性載體，重新審視運行示例。如下圖所示，注入的標簽屬性沿黑色虛線的路徑傳播。通過跟蹤此流程，LYNX 識別出三個屬性載體（值、參數和對象）并為每個屬性記錄載體實體。舉一個實體的例子，展示了對象的實體是如何合成的：首先，為了得到 O，LYNX 檢查標簽屬性的標識位置。在這種情況下，標簽屬性是從對象的基礎標識的。因此，LYNX 直接將 O 設置為“對象”。其次，要獲取L，LYNX 獲取當前腳本的文件路徑。第三，為了得到S，LYNX提取了載體的可見范圍。在這種情況下，載體是從位于第 10 行到第 22 行的匿名函數中找到的。因此，LYNX 將可見性編碼為 anon.10_1.26_1_fun。總的來說，記錄的實體將是 hobject, script_path, anon. 10_1. 22_1. _funi。

（2）查明隱藏屬性候選

動態分析可以有效地檢測屬性載體。然而，它在檢測隱藏屬性時不可避免地存在漏報。發現在某些情況下，即使隱藏的屬性載體已經被發現，重要的隱藏屬性也被忽略了。通過應用靜態分析作為補充來緩解這個問題。在本節中首先討論動態分析出現漏報性的原因。然后介紹靜態分析的設計細節。最后，討論如何修剪分析結果。

靜態分析的必要性：為了解釋動態分析的弱點，使用了一個虛擬的易受攻擊的代碼示例List 1（摘自真實代碼）。在這個例子中，函數 foo() 根據用戶控制的變量輸入（第 2 行）構建了一個內部變量 conf，這使得 conf 成為一個屬性載體。動態方法可以捕獲 propertyA，但如果不滿足條件，它將錯過 propertyB。為了解決這個問題，LYNX 實現了一個過程內靜態句法分析，可以識別索引語法，無論實際代碼是否被執行。

提取隱藏屬性候選：給定一個隱藏屬性載體“< O,L,S >”，LYNX 首先在相應的 AST 中識別它（由 L 指向）。LYNX 搜索 S 中記錄的可見性范圍內的所有對象引用。最后，LYNX 查明所有屬于 O 子屬性的引用，并將它們標記為隱藏屬性候選。由于以下原因，子屬性是潛在的隱藏屬性：報告屬性載體 < O,L,S > 是因為標簽屬性可以傳播到變量 O。因此，O 下的其他屬性也可能被偽造/ 從輸入覆蓋。請注意，由于貪婪策略，并非所有在這里找到的罐子都可以使用輸入來操作。因此，LYNX 將使用下一個組件來驗證每個候選者以確保準確性。

由于 JavaScript 的動態特性，子屬性可能以不同的方式被索引。為了提高該模塊的檢測覆蓋率，LYNX總結并認可了以下三種索引方式：(1) 靜態索引：用文字類型的鍵（例如，obj.k 或 obj[‘k’]）索引的屬性；(2) 函數索引：使用內置函數索引的屬性（例如，obj.hasOwnProperty(‘k’)）。(3) 動態索引：用變量索引的屬性（例如，obj[kvar]）。LYNX 靜態識別前兩種方法：它遍歷 AST 以恢復索引語義。為了識別第三種方法中的屬性，LYNX 從以前的執行跟蹤中提取 kvar 的實際值。值得注意的是，由于 LYNX 依賴之前的動態執行跟蹤來支持動態索引，因此無法保證 100% 覆蓋。也就是說，LYNX 只識別上一步具體索引的動態索引屬性。

運行示例：這里仍然使用前圖中的示例來說明它是如何工作的。以第 11 行的載體對象為例，LYNX 首先搜索其可見范圍內的所有子屬性引用（第 10 行到第 22 行的匿名函數），并檢測到恰好在確定載體的地方。找到該屬性后，LYNX 需要進一步檢查輸入對象是否可以覆蓋該屬性。為此，LYNX 檢查構造函數是否是 O 的子屬性。在此檢查通過后，LYNX 將構造函數識別為隱藏屬性候選者。

（3）修剪結果

如上所述，隱藏屬性候選被發現。然而，發現其中一些是已知參數而不是未知的隱藏屬性。這是因為一些 Node.js 模塊實現了可選參數作為輸入對象的屬性。這些記錄的屬性也可以在上一步中提取。例如，默認情況下，電子郵件模塊接受像 {“from”: .., “to”: ..} 這樣的輸入對象，但也接受更多選項，例如 {“from”: .., “to”: .. ，“cc”：..}。很明顯，這些記錄在案的參數并不是隱藏的屬性。

為了更正結果們引入了一個基于上下文的分析器來自動“推斷”所識別的屬性是否可以證明是一個記錄的參數。分析基于以下觀察：記錄的參數通常由調度程序一起處理（例如，一系列 if-else 語句）。

基于這一觀察，將參數處理過程分為兩類：（1）未使用的參數和使用的參數（即原始輸入中的屬性）由同一個調度程序處理。為了處理這種情況，分析器從公開的 API 的參數中記錄使用的屬性。然后，它確定與使用的參數位于同一調度程序中的隱藏屬性候選。(2) 未使用的參數和使用的參數由不同的調度器處理。為檢測此類參數，分析器會檢查所有候選對象，以查看是否從同一調度員處找到了多個候選。如果 LYNX 檢測到某些候選匹配任何一種情況，它就會將它們從結果中刪除。

E.生成 HPA 漏洞利用

在前面的組件中，LYNX 發現了隱藏屬性的關鍵名稱。通過使用這樣的關鍵注入屬性，攻擊者可能會更改覆蓋/偽造某些內部對象。在本節中，利用符號執行來推理發現的屬性是否可利用。給定一個隱藏屬性候選，首先將其注入到輸入中以構建測試負載。由于其對應的值尚未確定，將其符號化。然后，為了確定隱藏屬性是否有害，探索了盡可能多的路徑并沿著未覆蓋的路徑精確定位敏感sink。

（1）生成漏洞利用模板

在這一步中，LYNX 旨在生成可以到達潛在易受攻擊屬性的輸入數據結構。將此類結構表示為漏洞利用模板，因為 LYNX 將為每個隱藏屬性的值字段指定一個符號值而不是具體值。為了生成模板，LYNX 需要在輸入的正確位置插入一個屬性（帶有發現的關鍵名稱）。為了確定插入位置（應該修改輸入的哪個字段），LYNX 維護了標簽插入位置和屬性載體 O 之間的映射。

為了說明這一點，重用之前討論的示例：原始輸入是 {“email”:”aa@ gmail.com”, “passwd”:”11”}。如前所述，LYNX 需要確定插入位置：根據映射，任何添加到輸入基部的內容都會出現在前圖中第 11 行對象的基部。然后，LYNX 根據檢測到的關鍵名稱。最后生成的模板是{“email”:”aa@ gmail.com”, “passwd”:”11”, “constructor”: SYMBOL}。

（2）利用攻擊后果

在為每個隱藏屬性候選生成漏洞利用模板后，LYNX 開始分析其潛在的安全后果。為此，LYNX 首先象征性地執行隱藏屬性以探索所有可能的路徑。然后，LYNX 沿著發現的路徑精確定位敏感接收器，以確定隱藏的屬性是否有害。

根據有害隱藏屬性的定義，從機密性、完整性和可用性三個角度總結出六個敏感sink。如上表所示，不同的 sink 用于檢測不同類型的攻擊后果。總之，接收器有兩種實現方式。第一種類型是基于關鍵字的接收器。根據觀察，敏感 API 的某些參數可能是隱藏屬性的常見接收器。因此，通過分析已知漏洞數據庫（例如 snyk 漏洞數據庫和 npmjs 安全公告）上報告的現有漏洞，收集了一個關鍵字列表，盡最大努力收集盡可能多的敏感 API。目前，該列表包含 24 個 Sink：11 個文件系統操作 API、9 個數據庫查詢方法和 4 個代碼執行方法（API 列表將與 LYNX 的源代碼一起發布）。雖然列表可能不完整，但隨著時間的推移，它可以很容易地擴展。另一種類型的接收器是基于行為的接收器。許多漏洞高度依賴于代碼上下文。為了識別此類漏洞，關注可能濫用應用程序邏輯的行為。

目前，LYNX 已經覆蓋了以下三種惡意行為：(1) 返回值操作，對于旨在操縱臨界狀態的漏洞，LYNX 會檢查被測試模塊的返回值。如果攻擊者可以控制其返回值，LYNX 會將其標記為易受攻擊。(2)全局變量篡改，如果 LYNX 檢測到某個隱藏屬性可以篡改某個全局變量，則會將其報告為潛在漏洞。(3) 循環變量操作，對于旨在通過造成無限循環來破壞服務的漏洞，LYNX 會檢查循環條件以確定它們是否可以通過隱藏屬性進行操作。

識別出敏感接收器后，LYNX 準備概念驗證漏洞利用，旨在驗證接收器是否可達到攻擊控制值。為了收集漏洞利用，使用上一步生成的輸入重新執行程序。如果可以到達接收器，則將輸入與攻擊指示符一起報告。攻擊指標旨在幫助安全分析師了解漏洞利用如何影響接收器。對于不同的接收器，LYNX 采用不同的規則來生成指標。對于基于關鍵字的接收器，LYNX 會記錄可以到達敏感函數/屬性的內容類型。對于基于行為的接收器，LYNX 會比較攻擊輸入和良性輸入的執行軌跡，以查明漏洞利用的影響。例如，LYNX 監控全局對象的變化以觀察 A1 的可利用性。

整個攻擊探索方法總結在算法1中。搜索方法的輸入是測試程序m和上一步生成的漏洞利用模板集T。該方法的輸出是由（E，I）表示的攻擊概念證明，其中E是最終漏洞利用的集合，I是相應的攻擊效果指標。在算法的第一階段，它收集符號執行期間發現的新路徑，并將具體輸入和路徑提取到 U 中。在第二階段，算法檢查每條路徑 Pi。檢測到敏感sink后，會生成對應的exploit到達sink。如果 LYNX 檢測到接收器可達，則 LYNX 將同時報告漏洞利用 exp 和攻擊后果指標 ind。

為了演示整個過程，將算法應用于運行示例。如前圖所示，LYNX 在第 14 行符號化隱藏屬性構造函數。在執行期間，由于藍色虛線指示的符號值傳播，另外兩個變量也被符號化。通過解析三個符號值的約束，LYNX 找到了兩個可能的路徑（即第 19 行和第 21 行）。由于新路徑導致最終模塊返回值（即對象或空值）的更改，因此漏洞利用命中 I2 。因此，LYNX 構建了一個漏洞利用 {“email”:SQLI, “passwd”:”11”, “constructor”:false}（SQLI 代表 SQL 注入負載）。將漏洞利用程序輸入程序后，LYNX 會收集相應的指標：它檢測到可以通過將構造函數設置為 false 來更改返回值。

F.實施

將 LYNX 構建為一個 Node.js 應用程序，并通過使用幾個現有工具來實現它。在 LYNX 的第一個分析階段（即識別隱藏屬性），使用 Jalangi來檢測目標 Node.js 代碼以實現標簽系統。帶有標簽的檢測 Node.js 代碼會動態執行以發現隱藏的屬性載體。應用 Esprima生成 AST（抽象語法樹），用于對已識別的屬性載體進行靜態分析并提取隱藏屬性。在 LYNX的第二個分析階段，使用 ExpoSE執行符號執行，以確定發現的隱藏屬性的危害性并生成漏洞利用。為了分析基于 Web 的應用程序，實現了一個基于分析的 pipeline，用于捕獲 HTTP 請求并生成相應的測試用例。

0x04 Evaluation

為了評估 HPA 的安全影響，將 LYNX 應用于一組在實踐中廣泛使用的真實 Node.js 應用程序和模塊。在以下部分中，將通過三個研究問題討論評估結果：

? RQ1：隱藏屬性是否普遍存在于廣泛使用的 Node.js 程序中？

? RQ2：LYNX 能否有效檢測有害的隱藏屬性并生成相應的漏洞利用？

? RQ3：發現的漏洞和利用如何擴大Node.js 生態系統的攻擊面？

A.數據集

Node.js 取得了很大的進步，并且已經有很多 Node.js 程序可用。但是，發現其中大部分很少使用或與威脅模型不匹配。因此，為了減少分析的工作量，規范了數據集收集過程。特別是，根據以下兩個標準收集 Node.js 程序：（1）被測試的程序應該用于與外部輸入交互，并且它們的 API 應該接受對象（通過 JSON 或查詢字符串序列化）。(2) 被測試的程序應該被廣泛使用或持續維護。

為了滿足第一個標準，從最有可能暴露于輸入的類別中收集程序。這些類別包括數據庫、輸入驗證、用戶功能和基于 Web 的應用程序/中間件。為了滿足第二個標準，從知名供應商（例如 MongoDB）收集程序，以及在 Github 上至少有 1000+ star 或在 npm 上每月下載 500 次的項目。

總共收集了 102 個 Node.js 程序作為分析數據集。有 91 個 Node.js 模塊和 11 個基于 Web 的程序。在 11 個基于 Web 的程序中，4 個是最小的 Web 框架/中間件，7 個是完整的 Web 應用程序。

B.分析結果

（1）概述

在配備 Intel Core i5-9600K (3.70GHz) 和 32 GB 內存的 Ubuntu 18.04 機器上運行 LYNX。總共檢測到 451 個隱藏屬性候選，并確認了 15 個以前未知的 HPA 漏洞。截至撰寫本文時，已為發現分配了 10 個 CVE。其中半數以上被NVD（美國國家通用漏洞數據庫）評為“嚴重”和“高危”。

在這些漏洞中，有兩個是從完整的 Web 應用程序中識別出來的。其他 13 個漏洞是從模塊中識別出來的，總共影響了 20,402 個相關應用程序/模塊。Node.js 社區非常關注本研究的發現。權威的公共漏洞數據庫創建了一個新的概念來跟蹤相關漏洞。

（2）階段 1：識別隱藏屬性

為了回答 RQ1（流行的 Node.js 程序中是否普遍存在隱藏屬性？），分析了從廣泛使用的 Node.js 程序中檢測到了多少（以及什么樣的）隱藏屬性。

下表總結了檢測結果（上表列出了完整的檢測結果）。在下表中，從第二個列 “Tested Programs”，可以觀察到隱藏屬性廣泛存在于所有可能暴露于外部輸入的類別中。總體而言，69% (70/102) 的測試程序被發現包含隱藏屬性。

“Detection Results”下的前兩列表示屬性載體隱藏屬性候選者的數量。LYNX 通過分析 3175 個屬性載體，總共確定了 451 個隱藏屬性候選。可以觀察到隱藏屬性候選廣泛存在于數據集的所有類別中。“Detection Results”下的最后一列顯示有多少候選者被 LYNX 識別為記錄在案的論據。為了弄清楚記錄的參數推斷規則的正確性，將來自官方文檔的記錄參數與本文結果進行比較。發現基于上下文的規則可以正確識別來自已識別隱藏屬性的所有文檔參數。

請注意，根據正在測試的 Node.js 程序的類型來驅動本文的分析。對于91個npm模塊，直接重用它們 npm 主頁上提供的用例作為測試輸入。對于剩下的 11 個基于 Web 的程序，手動與應用程序交互并使用基于分析的pipline生成測試用例。LYNX 分析 Web 基礎程序的 JSON 和查詢字符串序列化通道。這 11 個基于 Web 的程序中有 7 個同時支持查詢字符串和 JSON 序列化（在不同的 API 中）。

（3）階段2：探索攻擊后果

從以下兩個方面評估 LYNX 的有效性（RQ2）：

（1）LYNX 是否有效地從不同類別的程序中找出潛在的漏洞？

（2) LYNX 是否成功生成可以直接或輕松移植以引入現實世界攻擊效果的漏洞？

下表顯示了第二階段的總結利用結果。在此表中，“Reported”列記錄了 LYNX 報告有多少敏感接收器易受攻擊。“Exploitable”列表示 LYNX 自動利用并手動確認為真正漏洞的報告接收器的數量。從這兩列中，可以觀察到 LYNX 能夠從不同類型的程序中查明潛在的易受攻擊的接收器。此外，報告問題的“quality”很好。總體而言，發現報告的 15 個漏洞中有 11 個被確認為易受攻擊，其他 4 個被認為是無害的。在這4種情況中，雖然一些隱藏屬性確實導致了某些敏感的sink，但它們仍然受到程序語義的約束，因此不能引入顯著的攻擊效果。例如，當 LYNX 利用驗證庫中的隱藏屬性時，它會導致執行異常，從而觸發接收器sink I2（最終結果操作）。但是，由于該異常稍后由程序處理，因此它不會啟用任何攻擊效果，例如驗證繞過。

上表的最后一列（“Missed”）記錄了 LYNX 成功檢測到（階段1）但未能生成可用漏洞（階段2）的隱藏屬性。為了找出此類隱藏屬性，手動檢查了 LYNX 報告的所有隱藏屬性候選。有三種類型的故障。首先，一些隱藏的屬性有一個特定的約束，在代碼語義中沒有出現。例如，taffyDB（一種流行的 JavaScript 數據庫）有一個隱藏屬性，可以通過偽造作為內部索引來泄漏任意數據。然而，與索引相關的約束是在內存中而不是在代碼中。因此，即使索引采用易于猜測的格式（例如，T000002R000001），LYNX 也無法構建有效索引。這種失敗源于符號執行的限制。為了覆蓋此類故障，模糊測試技術可能是一個很好的補充，可以覆蓋符號執行無法分析的部分。

另一種類型的失敗是由多約束問題引起的：為了利用某些隱藏屬性，必須將輸入的某些參數設置為某些值。可以通過擴展 LYNX 來同時探索多個變量（不僅是隱藏的屬性，還有記錄的參數）來解決此類故障。最后一種失敗來自語法不兼容問題。不兼容是因為底層檢測框架 (Jalangi) 與 ECMAScript 6 之后的某些語法不兼容。通過使用 Babel向下編譯不兼容的程序或避免檢測不兼容的代碼來緩解這個問題。為了簡化解決不兼容問題的過程，構建了一個自動向下編譯工具，該工具將與 LYNX 一起發布。

C.已識別 HPA 漏洞的影響分析

在本節中，試圖通過了解 HPA 漏洞如何將嚴重的攻擊影響引入 Node.js 生態系統來回答 RQ3。如下表所示檢測到 15 個 HPA 漏洞。為了修復這些漏洞，進行了負責任的披露并通知了供應商。他們立即反應過來。目前已有10家廠商確認該漏洞，其中7家已發布相應補丁。接下來，將從以下三個角度解釋HPA的安全影響。

機密性：發現 4 個已識別的漏洞（即 HP-1、HP-2、HP-3 和 HP-14）影響程序的機密性（例如，從數據庫中泄露敏感信息）。HP-1 和 HP-2 漏洞來自兩個廣泛使用的 mongoDB 驅動程序。通過利用HP-1和HP-2，攻擊者可以強制數據庫無論查詢條件是否正確，始終返回data/true。這可能會被濫用來泄露敏感信息或繞過訪問控制。例如，攻擊者可能會通過強制身份驗證結果為真來登錄其他用戶的帳戶。漏洞HP-3 來自taffyDB。這是一個嚴重的通用 SQL 注入，可以被濫用來訪問數據庫中的任意數據項：發現隱藏屬性可以偽造為 taffyDB 的內部索引 ID。如果查詢中找到索引ID，taffyDB會忽略其他查詢條件，直接返回索引的數據項。此外，索引 ID 采用易于猜測的格式（例如，T000002R000001），因此攻擊者可以利用此漏洞訪問數據庫中的任何數據項。漏洞 HP-12 來自電子商務 Web 應用程序 cezerin。發現隱藏屬性可以修改存儲在數據庫中的關鍵數據（即支付狀態為支付）。

完整性：發現了 10 個已識別的漏洞（即 HP-4、HP-5、HP-6、HP-7、HP-8、HP-9、HP-10、HP-11、HP-12 和 HP- 13) 損害 Node.js 應用程序的完整性。4 個廣泛使用的輸入驗證模塊受到 HPA 的影響。正在運行的示例類驗證器 (HP-4) 允許攻擊者覆蓋格式架構對象，從而繞過任意輸入驗證。Jpv（HP-5 和 HP-6）檢查其原型上不安全對象的類型。但是，由于 HPA 可以修改原型中的屬性，因此可以操縱 jpv 的驗證結果。其他三個驗證繞過漏洞來自 valib 的一個 API（HP-6）和模式檢查器的兩個 API（HP-7 和 HP-8）：通過修改不安全對象原型下的hasOwnProperty 函數，可以跳過安全檢查。請注意，這三種情況的利用場景有限：攻擊者需要傳遞有效的函數定義，這不是一個廣泛支持的特性。

影響程序完整性的其他 4 個漏洞（HP-10、HP-11、HP-12 和 HP-13）來自用戶功能模塊。這4個漏洞的利用方式類似：通過操縱輸入對象下的一些關鍵屬性，攻擊者可以操縱模塊調用的最終結果。這種操縱可能會給應用程序帶來嚴重的風險。例如，根據 Github 的 1,822,028 個項目中使用的對象克隆模塊 clone-deep 使用易受攻擊的種類 (HP-13) 在克隆之前執行類型檢查。如果要克隆的變量var被檢測為數組，clone-deep遞歸調用自身var.length次來克隆var下的所有元素。使用 HP-13，惡意對象可以偽造為一個非常長的數組。在克隆這樣一個對象時，clone-deep 會進入一個超級大的循環，從而凍結整個應用程序（耗時任務由于其單線程模型可能會阻塞 Node.js 應用程序）。

可用性：發現 1 個網絡框架工作（即 HP-15）的可用性會受到 HPA 的影響。此漏洞是從基于 Web 的應用程序 mongo-express 中檢測到的。發現隱藏屬性可以給應用程序引入無限循環，從而阻塞整個應用程序。

社區影響：本文發現已得到 Node.js 社區的證實。為了幫助開發人員意識到這種新風險，提出了一個新的概念來描述和跟蹤相關問題。由 snyk 維護的權威公共漏洞數據庫已接受該提議并開始在相關安全問題中使用該概念。

評論：基于影響分析，假設 HPA 攻擊確實擴大了 Node.js 生態系統的攻擊面。該主張得到以下兩個觀點的支持。：(1) HPA 攻擊通過建立對應用程序內部對象的意外數據依賴性，有效地破壞了以前無法訪問的程序狀態，并引入了不同類型的攻擊效果。(2) 經典防御技術（例如，輸入驗證）不能減輕 HPA。如前表所示，一些廣泛使用的驗證模塊容易受到 HPA 攻擊。

D.分析覆蓋率和性能

根據 ExpoSE的覆蓋率監控測量每個 Node.js 程序的 LYNX 代碼覆蓋率，它計算‘LoC being executed’/‘total LoC in executed fifiles’（不計算依賴項）。在下面討論覆蓋率測量結果，基于不同類型的經過測試的 Node.js 程序：模塊和基于 Web 的程序。

對于 Node.js 模塊，代碼覆蓋率各不相同（即 10% – 80%）。雖然大部分模塊實現了不錯的覆蓋率（超過 40%），但認為代碼覆蓋率并不一定表明 LYNX 的有效性：為了找到實際漏洞，有選擇地測試與威脅模型匹配的 API（可能會暴露于外部用戶和接受對象）。因此，即使測試用例適用于大多數 API，也不會盲目地測試所有 API。例如，如果某個 API 根本不接受參數，將不會將其包含在測試中，并且此類 API 測試貢獻的代碼覆蓋率無助于從測試程序中審查 HPA。

對于基于 Web 的程序，LYNX 平均實現了 21% 的代碼覆蓋率。發現這是因為 Web 應用程序通常具有大量的函數/API，而基于分析的測試可能無法涵蓋所有這些。為了幫助 LYNX 發現更多的 Web API，整合主動 Web 掃描器 可能是一項很有前途的未來工作。

除了代碼覆蓋率，還測量了每個階段的運行時間。作為離線工具，LYNX 實現了合理的分析速度：對于隱藏屬性的檢測，分析一個 API 的時間通常不超過 10 秒（90% 的情況）。對于非常大的程序，例如 Web 應用程序，每個 API 的分析時間可能超過 200 秒（不超過 10 個案例）。為了利用隱藏屬性，需要更長的時間，因為 LYNX 需要為每個候選者探索多條路徑。通常，每個隱藏屬性需要大約 50 秒。

E.案例研究

訪問機密用戶數據：LYNX 報告來自 mongoDB Node.JS 驅動程序的有害隱藏屬性 (_bsontype)。此屬性用于決定查詢類型，不應由輸入提供。但是發現mongoDB允許input通過HPA修改這個屬性。由于 mongoDB 根據預定義的類型處理查詢對象。

攻擊者可以指定一個未知的 _bsontype（例如 aaa）來強制 mongoDB 不序列化某些對象。例如，這可以被濫用以強制查詢結果始終為真（即，不序列化查詢文件管理器）。通過利用該漏洞，攻擊者可以對 mongoDB 中的機密數據進行未經授權的訪問。

為了演示其中一種攻擊媒介，使用 Phaser Quest，這是一款使用易受攻擊的 mongoDB 驅動程序模塊的在線游戲。如List 2 所示，程序通過用戶提供的秘密標識符 (id) 加載/刪除用戶配置文件。通過濫用所討論的漏洞，攻擊者可以強制數據庫返回有效用戶，而不管標識符是否正確。通過這樣做，攻擊者可以登錄/刪除任意玩家的帳戶。

已經向 MongoDB 團隊進行了負責任的披露。他們已經修補了漏洞并在他們的安全建議中承認了本研究。

阻止事件處理程序：由于 Node.js 基于單線程模型，因此其事件處理程序的可用性非常關鍵，并且已經討論了很多。在第二種情況下想演示 HPA 如何攻擊事件處理程序，從而凍結整個程序。

LYNX 報告了來自基于 Web 的 mongoDB 管理界面 mongo-express 的有害隱藏屬性 (toBSON)。通過濫用此屬性，經過身份驗證的用戶會發出一個耗時的任務來阻止 Node.js 的事件處理程序。如List 3 上半部分所示，在第 3 行識別出一個隱藏屬性 toBSON。通過跟蹤該屬性的數據流，發現它到達了第 12 行的敏感接收器，該接收器用于執行中的代碼一個沙箱。因此，攻擊者可以通過一個耗時的函數（例如，無限循環）來阻止事件處理程序。

在收到漏洞報告后，項目團隊立即確認并將此問題添加到他們的安全公告中。在撰寫論文時正在與他們合作修復錯誤。

0x05 Discussion

緩解對策：總結了針對 HPA 的三個主要對策。例如，其中之一是驗證輸入對象。由于 HPA 的第一步是注入其他屬性，因此刪除不需要的（惡意）屬性可能是一種可行的緩解措施。

局限性：首先，LYNX 需要外部輸入（即模塊測試用例或網絡上的用戶交互）來觸發分析。由于不同模塊/應用程序的 API 具有不同的上下文依賴關系和參數格式，因此很難自動推斷和解決這些先決條件。例如，在評估過程中，發現需要登錄被測試的 Web 程序才能訪問某些 API。為了解決這個問題，實現了一個pipline，可以自動重放和改變 API 調用。為了測試基于 Web 的程序，安全分析師只需像普通用戶一樣進行交互即可。未來正在考慮向 LYNX 引入自動輸入格式推理組件，以簡化輸入生成過程。其次，與許多其他動態分析工具一樣，LYNX 可能存在漏報。例如，使用的測試輸入可能沒有探索某些測試程序的所有分支。為了提高覆蓋率，可以將 LYNX 與模糊測試技術結合起來。第三，Lynx 沒有覆蓋 Node.js 生態系統中存在的所有輸入通道：在生態系統中，不同的程序可能使用不同的方法/代碼實現來共享對象，因此很難系統地覆蓋所有通道，也不是本文的重點。雖然知道 Lynx 并未涵蓋所有輸入行，但它確實涵蓋了兩種最流行的方法，并且可以支持大量程序。

0x06 Conclusion

在本文中對 Node.js 程序的對象共享進行了首次系統研究，并設計了一種名為隱藏屬性濫用的新攻擊。通過將以前無法訪問的程序狀態暴露給攻擊者，新的攻擊擴大了 Node.js 的攻擊面。新的攻擊面導致發現 15 個0 day漏洞，所有這些漏洞都可以被利用來引入嚴重的攻擊效果。為了檢測 HPA構建了 LYNX，這是一種新穎的漏洞發現和驗證工具，它結合了靜態和動態分析技術來查明和利用 Node.js 程序中存在漏洞的內部對象。對 102 個廣泛使用的 Node.js 程序使用 LYNX，表明 LYNX 可以有效地檢測 HPA 漏洞。