NoSQL注入的分析和緩解

　　了解針對NoSQL的新的安全漏洞 五類NoSQL攻擊手段，比如重言式、聯(lián)合查詢、JavaScript 注入、背負(fù)式查詢（Piggybacked queries），以及跨域違規(guī) OWASP組織針對檢查NoSQL注入代碼的建議 了解如何緩解安全風(fēng)險 如何在整個軟件開發(fā)周期中整合NoSQL數(shù)據(jù)庫漏洞的管理

　　本篇文章已經(jīng)在 IEEE Software 雜志上首發(fā)。 IEEE Software 就今天的戰(zhàn)略性技術(shù)問題提供了可靠的、經(jīng)專家評審過的信息。IT管理者和技術(shù)領(lǐng)導(dǎo)應(yīng)依靠新先進解決方案的IT專業(yè)人員，以迎接運行可靠的、靈活的企業(yè)這一挑戰(zhàn)。

　　NoSQL（不僅僅是NoSQL）數(shù)據(jù)存儲系統(tǒng)已經(jīng)非常流行，因為它們易擴展且易于使用。盡管NoSQL數(shù)據(jù)存儲的新的數(shù)據(jù)模型和查詢格式令原來的攻擊不再有效了，但攻擊者卻可以尋找新的契機插入惡意代碼。

　　數(shù)據(jù)庫安全是信息安全的一個重要內(nèi)容。訪問企業(yè)數(shù)據(jù)庫授權(quán)攻擊者能夠充分控制關(guān)鍵性數(shù)據(jù)。例如，SQL注入攻擊把惡意代碼插入到應(yīng)用向數(shù)據(jù)庫層發(fā)送的語句中。這使攻擊者幾乎能對數(shù)據(jù)做任何操作，包括訪問未授權(quán)的數(shù)據(jù)，以及修改、刪除和插入數(shù)據(jù)。盡管由于框架更安全、人們意識更強，SQL注入這種手段的利用率近幾年來已經(jīng)穩(wěn)步下降，但它仍然是個高危的系統(tǒng)漏洞。例如，Web應(yīng)用每月受到四次或更多次Web攻擊活動，而SQL注入仍然是攻擊零售商最流行的方式1。此外，SQL注入漏洞對32%的Web應(yīng)用都有影響。

　　NoSQL（不僅僅是SQL）是數(shù)據(jù)存儲的一個流行趨勢；它泛指依賴于不同存儲機制的非關(guān)系型數(shù)據(jù)庫，這些存儲機制包括文檔存儲、鍵值對存儲和圖。這些數(shù)據(jù)庫的廣泛應(yīng)用是由現(xiàn)代大型應(yīng)用推動起來的，比如非死book、Amazon和推ter，它們需要把數(shù)據(jù)分布到許多的服務(wù)器上。傳統(tǒng)關(guān)系型數(shù)據(jù)庫不滿足這種擴展性需求，它們需要一個單獨的數(shù)據(jù)庫節(jié)點去執(zhí)行同一事務(wù)的所有操作。

　　于是，發(fā)展出一批分布式的、NoSQL鍵值對存儲來滿足這些大型應(yīng)用的擴展性需求。這些數(shù)據(jù)存儲包括像MongoDB和Cassandra之類的NoSQL數(shù)據(jù)庫，也有像Redis和Memcached這樣的內(nèi)存和緩存存儲。確實，NoSQL的受歡迎程度在過去幾年來一直在穩(wěn)定上升，其中MongoDB在10個最流行的數(shù)據(jù)庫中排到了第四位，如圖1所示。

　　圖1 db-engines.com 2015年8月流行度排名中前十個最受歡迎的數(shù)據(jù)庫。其中NoSQL數(shù)據(jù)庫有MongoDB、Cassandra和Redis。這三款的受歡迎程度仍在上升。

　　在本文中，我們將分析NoSQL的威脅和技術(shù)，以及它們的緩解機制。

　　幾乎就像每種新技術(shù)一樣，NoSQL數(shù)據(jù)庫在剛出現(xiàn)時還不夠安全3–5。它們當(dāng)初缺乏加密、適當(dāng)?shù)恼J(rèn)證、角色管理和細(xì)粒度的授權(quán)等6。此外，它們還會出現(xiàn)危險的風(fēng)險暴露和拒絕服務(wù)攻擊3。如今，情況已經(jīng)好轉(zhuǎn)了，流行的數(shù)據(jù)庫已經(jīng)引入了內(nèi)置的保護機制7。

　　NoSQL數(shù)據(jù)庫使用不同的查詢語言，這使傳統(tǒng)的SQL注入技術(shù)已經(jīng)無效了。但這是否意味著NoSQL系統(tǒng)對注入免疫呢？我們的研究表明，盡管這個查詢語言及其驅(qū)動的安全性已經(jīng)大型提升，但仍然存在著注入惡意查詢的手段。已經(jīng)有人整理出了NoSQL注入技術(shù)的列表1,3,4。有些初步應(yīng)用掃描項目已經(jīng)涌現(xiàn)出來了（例如 nosqlproject.com ），而且開放式Web應(yīng)用程序安全項目（OWASP，Open Web Application Security Project）已經(jīng)公布了檢查NoSQL注入代碼的建議。然而，這些還僅僅是初步成果，這些問題尚未得到充分的研究，并且未得到應(yīng)有的關(guān)注。

　　Web應(yīng)用和服務(wù)通常使用NoSQL數(shù)據(jù)庫去保存客戶數(shù)據(jù)。圖2展示了一個典型的架構(gòu)，在此NoSQL用于保存通過Web應(yīng)用來存取的數(shù)據(jù)。通過一個驅(qū)動程序來進行這個數(shù)據(jù)庫的訪問，即一個存取協(xié)議包裝器，它為多種編程語言編寫的數(shù)據(jù)庫客戶端提供類庫。盡管該驅(qū)動程序自身可能不易受到攻擊，但有時它們提供了不安全的API，當(dāng)應(yīng)用開發(fā)人員錯誤地使用它們時，就會給該應(yīng)用引入漏洞了，這些漏洞會被人利用對數(shù)據(jù)庫進行任意操作。如圖2所示，攻擊者可以偽造一個帶有注入代碼的Web訪問請求，當(dāng)數(shù)據(jù)庫客戶端或協(xié)議包裝器進行處理時，將會執(zhí)行預(yù)期的非法數(shù)據(jù)庫操作。

　　圖2 典型Web應(yīng)用架構(gòu)。NoSQL用于保存通過Web應(yīng)用來存取的數(shù)據(jù)。通過一個驅(qū)動程序來進行這個數(shù)據(jù)庫的訪問，即一個存取協(xié)議包裝器，它為多種編程語言編寫的數(shù)據(jù)庫客戶端提供類庫。盡管該驅(qū)動程序自身可能不易受到攻擊，但有時它們提供了不安全的API，當(dāng)應(yīng)用開發(fā)人員錯誤地使用它們時，就會給該應(yīng)用引入漏洞了。

　　NoSQL相關(guān)的SQL攻擊主要機制可以大致分為以下五類： 重言式 。又稱為永真式。此類攻擊是在條件語句中注入代碼，使生成的表達式判定結(jié)果永遠(yuǎn)為真，從而繞過認(rèn)證或訪問機制。例如，在本文中，我們將展示攻擊者如何用$ne操作（不相等）的語法讓他們無需相應(yīng)的憑證即可非法進入系統(tǒng)。 聯(lián)合查詢 。聯(lián)合查詢是一種眾所周知的SQL注入技術(shù)，攻擊者利用一個脆弱的參數(shù)去改變給定查詢返回的數(shù)據(jù)集。聯(lián)合查詢最常用的用法是繞過認(rèn)證頁面獲取數(shù)據(jù)。在本文中，我們將展示一個攻擊示例，它將通過增加永真的表達式利用布爾OR運算符進行攻擊，從而導(dǎo)致整個語句判定出錯，進行非法的數(shù)據(jù)獲取。 JavaScript注入 。這是一種新的漏洞，由允許執(zhí)行數(shù)據(jù)內(nèi)容中JavaScript的NoSQL數(shù)據(jù)庫引入的。JavaScript使在數(shù)據(jù)引擎進行復(fù)雜事務(wù)和查詢成為可能。傳遞不干凈的用戶輸入到這些查詢中可以注入任意JavaScript代碼，這會導(dǎo)致非法的數(shù)據(jù)獲取或篡改。 背負(fù)式查詢 。在背負(fù)式查詢中，攻擊者通過利用轉(zhuǎn)義特定字符（比如像回車和換行之類的結(jié)束符）插入由數(shù)據(jù)庫額外執(zhí)行的查詢，這樣就可以執(zhí)行任意代碼了。 跨域違規(guī) 。HTTP REST APIs是NoSQL數(shù)據(jù)庫中的一個流行模塊，然而，它們引入了一類新的漏洞，它甚至能讓攻擊者從其他域攻擊數(shù)據(jù)庫。在跨域攻擊中，攻擊者利用合法用戶和他們的網(wǎng)頁瀏覽器執(zhí)行有害的操作。在本文中，我們將展示此類跨站請求偽造（CSRF）攻擊形式的違規(guī)行為，在此網(wǎng)站信任的用戶瀏覽器將被利用在NoSQL數(shù)據(jù)庫上執(zhí)行非法操作。通過把HTML格式的代碼注入到有漏洞的網(wǎng)站或者欺騙用戶進入到攻擊者自己的網(wǎng)站上，攻擊者可以在目標(biāo)數(shù)據(jù)庫上執(zhí)行post動作，從而破壞數(shù)據(jù)庫。

　　盡管相對安全，但流行的JSON表述格式仍可受到新類型的注入攻擊。我們將舉例說明MongoDB中的此類攻擊，MongoDB是一個面向文檔的數(shù)據(jù)庫，已經(jīng)有多個大型供應(yīng)商予以采用，其中包括eBay、Foursquare和LinkedIn。

　　在MongoDB中，查詢和數(shù)據(jù)以JSON格式描述，這在安全方面要優(yōu)于SQL，因為它是更充分定義的，容易進行加密和解密，而且在每種編程語言中都有不錯的原生實現(xiàn)。像SQL注入那樣對查詢結(jié)構(gòu)的破壞，在JSON結(jié)構(gòu)的查詢中會更難實現(xiàn)。在MongoDB中常見的插入語句應(yīng)該是這樣的：

　　這會插入一個新的文檔到books的集合中，它具有title（標(biāo)題）和author（作者）字段。常見的查詢條件應(yīng)該是這樣的：

　　除限制要查詢的字段之外，查詢中還可以包括正則表達式和條件。

　　讓我們審視一下圖3中所畫的架構(gòu)，一個使用PHP實現(xiàn)后端的Web應(yīng)用，它將用于查詢數(shù)據(jù)存儲的請求編碼為JSON格式。讓我們使用一個MongoDB示例去演示數(shù)組注入漏洞吧，從技術(shù)和結(jié)果上來看這是一個與SQL注入有些類似的攻擊手段。

　　圖3 使用MongoDB的PHP應(yīng)用。一個使用PHP實現(xiàn)后端的Web應(yīng)用，它把用于查詢數(shù)據(jù)存儲的請求編碼為JSON格式。

　　PHP編碼數(shù)組為原生JSON。嗯，數(shù)組示例如下：

　　將由PHP編碼為以下JSON格式：

　　如果一個PHP具有登錄機制，由用戶瀏覽器通過HTTP POST（它像HTTP GET一樣容易受到攻擊）發(fā)送過來用戶和密碼，常見的POST URL編碼應(yīng)該是這樣的：

　　后端PHP代碼針對該用戶對它進行處理并查詢MongoDB，如下所示：

　　這本身合情合理沒什么問題，直覺上開發(fā)人員可能喜歡用以下查詢：

　　然而，PHP針對關(guān)聯(lián)數(shù)組有個內(nèi)置的機制，這讓攻擊者有機可乘，可發(fā)送以下惡意的數(shù)據(jù)：

　　PHP會把該輸入解析為：

　　它會編碼為如下MongoDB查詢：

　　因為$ne是MongoDB用來判定條件是否不相等的，所以它會查詢登錄集合中的所有用戶名稱不等于1且密碼也不等于1的記錄。因此，本次查詢將返回登錄集合中的所有用戶。換成SQL的表述法，就等同于以下查詢語句：

　　在這種情況下，漏洞就為攻擊者提供了一個不必有效憑證即可登錄應(yīng)用的方式。在其他變體中，該漏洞可能會導(dǎo)致非法數(shù)據(jù)訪問或由無特權(quán)的用戶執(zhí)行特權(quán)操作。為緩解這個問題，我們需要轉(zhuǎn)換從需求中接收的參數(shù)為適當(dāng)類型，在本例中，可使用字符串，如下所示：

　　SQL注入漏洞經(jīng)常是由于未對用戶輸入進行適當(dāng)編碼而直接拼接查詢造成的。在MongoDB之類的流行數(shù)據(jù)存儲中，JSON查詢結(jié)構(gòu)使攻擊變得更難了。然而，這并不代表不可能。

　　讓我們看一個通過HTTP POST發(fā)送用戶名和密碼參數(shù)到后端的登錄表單，它通過拼接字符串的方式得到查詢語句。例如，開發(fā)人員可能會這么做：

　　具有有效輸入時，得到的查詢語句是應(yīng)該這樣的：

　　但具有惡意輸入時，這個查詢語句會被轉(zhuǎn)換為忽略密碼的，在無需密碼的情況下登錄用戶賬號。惡意輸入示例如下：

　　該輸入會被構(gòu)建到該查詢中：

　　只要用戶名是正確的，這個查詢就可以成功。轉(zhuǎn)換成SQL的表述，這個查詢類似于以下語句：

　　密碼成為這個查詢多余的一部分，因為（）內(nèi)的條件總為真，所以不會影響到查詢的最終結(jié)果。

　　這是怎么發(fā)生的呢？以下為拼接出的查詢串，用戶輸入為加粗字體，剩余的文本串為無格式字體：

　　這個攻擊在任何只要用戶名正確的情況下都將成功，一般得到個用戶名并不是什么難事。

　　NoSQL數(shù)據(jù)庫中有個共同特性，那就是可以在數(shù)據(jù)庫引擎中運行JavaScript，從而可以執(zhí)行復(fù)雜的查詢或MapReduce之類的事務(wù)。包括MongoDB 和 CouchDB及其后續(xù)的 Cloudant 和 BigCouch等流行的數(shù)據(jù)庫都允許這么做。如果不干凈的用戶輸入發(fā)現(xiàn)這種查詢方式的話，這么執(zhí)行JavaScript就等于把薄弱面暴露給攻擊者了。例如，設(shè)想一個需要JavaScript代碼的復(fù)雜事務(wù)，包含有不干凈的用戶輸入作為查詢的參數(shù)。讓我們看一下它的存儲模型，它保存了一組條目，每個條目具有價格和數(shù)量屬性。為得到這些屬性的總數(shù)或平均值，開發(fā)人員編寫了一個MapReduce函數(shù)，它從用戶那里接收數(shù)量或價格作為參數(shù)，然后進行處理。在PHP中，看起來是如下代碼（$param是用戶輸入）：

　　這段代碼把每個條目按名稱給定的$param合計起來。當(dāng)時，$param預(yù)期是接收數(shù)量（amount）或價格（price）的，這段代碼將按預(yù)期進行運轉(zhuǎn)。但是，因為用戶輸入未被轉(zhuǎn)義，所以惡意輸入（它可能包含任意JavaScript）將被執(zhí)行。

　　看一下如下輸入：

　　第一部分的數(shù)據(jù)會閉合最初的MapReduce函數(shù)，然后攻擊者就可以在數(shù)據(jù)庫上執(zhí)行想要的JavaScript了（加粗部分）。最終，最后一部分調(diào)用一個新的MapReduce以保持被注入代碼的原始語句的平衡。在把會被執(zhí)行的用戶輸入合并到為字符串后，我們得到以下代碼（注入的用戶輸入加粗顯示）：

　　這個注入看起來與經(jīng)典的SQL注入非常相似。防御此類攻擊的一種方式是在數(shù)據(jù)庫配置中禁止執(zhí)行JavaScript。如果JavaScript是必需的，那么最好的策略是不使用任何用戶輸入。

　　像Memcached、Redis和Tachyon之類的鍵值對存儲是內(nèi)存數(shù)據(jù)存儲，旨在加快應(yīng)用、云架構(gòu)和平臺以及大數(shù)量框架的執(zhí)行速度。這些平臺考慮的是反復(fù)頻繁訪問的數(shù)據(jù)的存儲和檢索。它們通常處于數(shù)據(jù)存儲之前，如圖4所示。緩存架構(gòu)經(jīng)常存儲認(rèn)證令牌及容器訪問控制列表，對于每個后續(xù)的用戶請求必須重新使其生效。

　　圖4 分布式內(nèi)存數(shù)據(jù)存儲架構(gòu)。被攻擊的Web服務(wù)器使用一個鍵值數(shù)據(jù)存儲進行快速數(shù)據(jù)檢索。對數(shù)據(jù)存儲的查詢是在該Web服務(wù)器上通過用戶提供的數(shù)據(jù)構(gòu)建出來的。如果處理不適當(dāng)，用戶數(shù)據(jù)可以導(dǎo)致一個非法查詢注入，它將被該鍵值面目數(shù)據(jù)存儲處理，導(dǎo)致應(yīng)用邏輯中的錯誤，以此繞過認(rèn)證或進行有害的數(shù)據(jù)檢索。

　　盡管由于鍵值對查詢很簡單所以通常緩存API也非常簡單，但我們發(fā)現(xiàn)一個Memcached（第二受歡迎的鍵值對面目全非）潛在的注入攻擊手段，那就是基于特定PHP版本的Memcached驅(qū)動程序中的漏洞。達成以下條件即可進行攻擊： 用作傳遞給緩存set/get 的屬性（例如，value）是來自于用戶請求的信息（例如，HTTP標(biāo)頭） 接收到的字符串未經(jīng)過處理就發(fā)送了 緩存的屬性包括將導(dǎo)致查詢執(zhí)行不同于預(yù)期的行為的敏感信息。

　　如果滿足這些條件，攻擊者就可以注入查詢或操縱查詢邏輯，比如背負(fù)式查詢攻擊。

　　把一個鍵及相應(yīng)的值加到使用Memcached的數(shù)據(jù)庫中的一組操作。當(dāng)從命令行界面調(diào)用時，這組函數(shù)使用兩行輸入，第一行是：

　　然后第二行由要保存的數(shù)據(jù)構(gòu)成。

　　當(dāng)PHP配置的函數(shù)被調(diào)用時，它接收的兩個參數(shù)看起來是這樣的：

　　研究人員表示，該驅(qū)動程序未能針對帶有回車 (0x0D)和換行的

　　(0x0A)的ASCII碼采取措施，導(dǎo)致攻擊者有機會注入包含有鍵參數(shù)的新命令行和其他非計劃內(nèi)的命令到緩存中8。

　　看一下如下代碼，其中的$param是用戶輸入并作為鍵來作用：

　　攻擊者可以提供以下輸入進行注入攻擊：

　　在本例中，增加到數(shù)據(jù)庫中的第一個鍵是具有“some value”值的key1。攻擊者可以增加其他的、非計劃內(nèi)的鍵到數(shù)據(jù)庫中，即帶有“inject”值的key2。

　　這種注入也可以發(fā)生在get命令上。讓我們看一下Memcached主頁上的示例，它以這三行開頭：

　　這個示例展示了Memcached的典型用法，在處理輸入之前首先檢查在數(shù)據(jù)庫中是不是已經(jīng)存在了。假設(shè)用類似代碼檢查從用戶那里接收的認(rèn)證令牌，驗證他們是不是登錄過了，那么就可以通過傳遞以下作為令牌的字符串來利用它（注入部分已經(jīng)加粗強調(diào)）：

　　當(dāng)這個字符串作為令牌傳遞時，數(shù)據(jù)庫將檢查這個“random_token”是否存在，然后將添加一個具有“root”值的“my_crafted_token”。之后，攻擊者就可以發(fā)送具有root身份的my_crafted_token令牌了。

　　可以被這項技術(shù)攻擊的其他指令還有：

　　在此，incr用于增加一個鍵的值，decr用于縮減一個鍵的值，以及delete用于刪除一個鍵。攻擊者也可以用像set和get函數(shù)一樣的手段來使用帶來自己鍵參數(shù)的這三個函數(shù)。

　　攻擊者可以使用多條目函數(shù)進行同樣的注入：deleteMulti、getMulti和setMulti，其中每一個鍵字段都可以被注入。

　　回車換行注入可以被用于連接多個get請求。在一項我們進行的測試中，包括原始get在內(nèi)最多可以連接17條。這樣注入返回的結(jié)果是第一個鍵及其相應(yīng)的值。

　　該驅(qū)動程序的漏洞已經(jīng)在PHP 5.5 中修復(fù)，但不幸的是它已存在于之前所有的PHP版本中了。按照W3Techs.com對生產(chǎn)系統(tǒng)的PHP版本的統(tǒng)計來看，超過86%的PHP網(wǎng)站使用了比5.5要老的版本，這意味著如果他們使用了Memcached就很容易受到這種注入攻擊。

　　NoSQL數(shù)據(jù)庫的另一個常見特點是，他們能夠常常暴露能夠從客戶端應(yīng)用進行數(shù)據(jù)庫查詢的HTTP REST API。暴露REST API 的數(shù)據(jù)庫包括MongoDB、CouchDB和HBase。暴露REST API 就直接把數(shù)據(jù)庫暴露給應(yīng)用了，甚至是僅基于HTML5的應(yīng)用，因為它不再需要間接的驅(qū)動程序了，讓任何編程語言都可以在數(shù)據(jù)庫上執(zhí)行HTTP查詢。這么做的優(yōu)勢非常明顯，但這一特點是否伴隨著安全風(fēng)險？我們的回答是肯定的：這種REST API給跨站點請求偽造（CSRF）暴露了數(shù)據(jù)庫，讓攻擊者繞過了防火墻和其他外圍防御。

　　只要數(shù)據(jù)庫部署在諸如防火墻之類的安全設(shè)施之后的安全網(wǎng)絡(luò)中，攻擊者要危害這個數(shù)據(jù)庫就必須找到能讓他們進入這個安全網(wǎng)絡(luò)的漏洞，或者完成能讓他們執(zhí)行任意查詢的注入。當(dāng)數(shù)據(jù)庫在安全網(wǎng)絡(luò)內(nèi)暴露 REST API時，任何能夠訪問該安全網(wǎng)絡(luò)的人都可以僅通過HTTP就能在這個數(shù)據(jù)庫上執(zhí)行查詢，因此在瀏覽器上就可以發(fā)起此類查詢了。如果攻擊者可以在網(wǎng)站上輸入HTML表單，或者欺騙用戶到攻擊者自己的網(wǎng)站上，就能夠通過提交這個表單在數(shù)據(jù)庫上執(zhí)行任何post操作了。而post操作包括增加文件。

　　我們在調(diào)查研究審查了Sleepy Mongoose，這是一個針對MongoDB的全功能HTTP接口。 Sleepy Mongoose API是以http:// {host name}/{db name}/{collection name}/{action}這樣的URL格式定義的。查找文件的參數(shù)可以作為查詢參數(shù)包含在內(nèi)，而新文件也可以作為請求數(shù)據(jù)予以添加。例如，如果我們想要在safe.internal.db主機上的數(shù)據(jù)庫中名為hr的管理員集合中增加一個新文件{username:'attacker'} ，就可以發(fā)送一個post HTTP請求至 http://safe.internal.db/hr/admins/_insert ，加上URL編碼過的數(shù)據(jù)username=attacker。

　　現(xiàn)在讓我們看看CSRF攻擊是如何使用這個函數(shù)增加新文件到管理員集合中的，從而在hr數(shù)據(jù)庫（它被認(rèn)為處于安全的內(nèi)部網(wǎng)絡(luò)中）中增加了一個新的管理員用戶，如圖5所示。若想攻擊成功，必須要滿足幾個條件。首先，攻擊者必須能操作一個網(wǎng)站，要么是他們自己的網(wǎng)站，要么是利用不安全的網(wǎng)站。攻擊在該網(wǎng)站放置一個HTML表單以及一段將自動提交該表單的腳本，比如：

　　圖5 NoSQL HTTP REST API上的跨站請求背負(fù)式攻擊示意圖。藏在防火墻后的內(nèi)部網(wǎng)絡(luò)內(nèi)的用戶被欺騙訪問一個惡意外部網(wǎng)頁，這將導(dǎo)致在內(nèi)部網(wǎng)絡(luò)的NoSQL數(shù)據(jù)庫的 REST API 上執(zhí)行非預(yù)期的查詢。

　　第二，攻擊者必須通過網(wǎng)絡(luò)誘騙或感染用戶經(jīng)常訪問的網(wǎng)站欺騙用戶進入被感染的網(wǎng)站。最后，用戶必須許可訪問Mongoose HTTP接口。

　　用這種方式，攻擊者不必進入內(nèi)部網(wǎng)絡(luò)即可執(zhí)行操作，在本例中，是插入新數(shù)據(jù)到位于內(nèi)部網(wǎng)絡(luò)中的數(shù)據(jù)庫中。這種攻擊執(zhí)行很簡單，但要求攻擊者要提前偵察去識別主機、數(shù)據(jù)庫名稱，等等。

　　鑒于我們在本文中所提到的這些攻擊手段，NoSQL部署中的安全問題的緩解是非常重要的。但不幸的是，應(yīng)用層的代碼分析不足以確保所有風(fēng)險都能得以緩解。三個趨勢使該問題將比之前面臨更多的挑戰(zhàn)。首先，云和大數(shù)據(jù)系統(tǒng)的形成，它們通常會執(zhí)行多個復(fù)雜應(yīng)用，這些應(yīng)用使用異構(gòu)的開源工具和平臺。而這些應(yīng)用通常由開源社區(qū)開發(fā)，大多數(shù)情況下，未經(jīng)受過全面的安全性測試。另一個挑戰(zhàn)是伴隨DevOps方法論而形成的現(xiàn)代代碼開發(fā)的速度，因為DevOps追求的是縮短開發(fā)和生產(chǎn)之間的時間。最后，大多數(shù)應(yīng)用安全測試工具不能與新編程語言的應(yīng)用保持同步，例如，大多數(shù)安全產(chǎn)品不支持Golang、Scala和 Haskel。

　　為充分解決由應(yīng)用層引入的風(fēng)險，我們需要考慮整個軟件開發(fā)生命周期，如圖6所示。

　　圖6 應(yīng)用和部署安全的生命周期。為充分解決由應(yīng)用層引入的風(fēng)險，我們需要考慮整個軟件開發(fā)生命周期。

　　意識 。很明顯，構(gòu)建阻止注入和其他潛在漏洞的安全軟件是最好、最廉價的解決方案。建議在該軟件生命周期中涉及到的人針對他們的職責(zé)接受適應(yīng)的安全培訓(xùn)。例如，已經(jīng)理解漏洞的開發(fā)人員就不太可能把它們引入到軟件中。

　　設(shè)計 。應(yīng)用的安全方面必須在開發(fā)階段早期予以考慮和定義。定義什么需要在應(yīng)用內(nèi)保護，如何確保這個功能已經(jīng)轉(zhuǎn)化為開發(fā)階段中的任務(wù)并得到足夠的重視。

　　針對代碼的最佳實踐 。建議充分利用已經(jīng)經(jīng)受過安全驗證處理的共享類庫，從而減少犯安全性錯誤的機會。例如，使用針對認(rèn)證充分驗證過的類庫，減少開發(fā)人員自己實現(xiàn)認(rèn)證把漏洞引入到算法中的風(fēng)險。再舉一個使用“消毒后(sanitization)”類庫的例子。所有注入攻擊都是缺乏消毒造成的。使用一個充分測試消毒過的類庫能很大程度上減少以自主研發(fā)消毒方法引入漏洞的風(fēng)險。

　　特權(quán)隔離 。兆柏數(shù)據(jù)恢復(fù)公司在過去，NoSQL不支持適當(dāng)?shù)恼J(rèn)證和角色管理9。現(xiàn)在，在大多數(shù)流行的NoSQL數(shù)據(jù)庫上進行適當(dāng)?shù)恼J(rèn)證管理和基于角色的訪問控制認(rèn)證已經(jīng)成為可能。這些機制出于兩個原因非常重要。第一，它們允許實施最少特權(quán)的原則，從而避免通過合法用戶的特權(quán)升級攻擊。第二，類似于SQL注入攻擊10，當(dāng)數(shù)據(jù)存儲暴露在我們本文所說的注入攻擊之下時，適當(dāng)?shù)奶貦?quán)隔離能將危害最小化。

　　安全掃描 。建議在應(yīng)用或源碼上運行動態(tài)和靜態(tài)應(yīng)用安全測試（分別為DAST和SAST）以發(fā)現(xiàn)注入漏洞。問題是目前市場上的許多工具缺乏檢測NoSQL注入的規(guī)則。DAST方法被認(rèn)為比SAST更可靠11。特別是如果用戶使用后端檢查方法提升檢測可靠性的話，這是一種作為交互式應(yīng)用安全測試提出的方法9,12。它還建議，集成這些掃描工具到持續(xù)構(gòu)建和發(fā)布系統(tǒng)中，如此它們就會在每個周期或檢入時執(zhí)行，缺陷就會及時發(fā)現(xiàn)并修復(fù)，而不只是在安全測試階段。

　　由于兩個原因，這可能會減少修復(fù)安全性缺陷的工作量。第一個，在開發(fā)階段修復(fù)缺陷的成本要遠(yuǎn)低于生命周期更后的階段，特別是因為安全性測試往往都在功能性測試之后，而且修復(fù)安全性缺陷可能會需要重新做功能性測試。第二個，開發(fā)人員能在早期了解這些缺陷，在之后的代碼開發(fā)中不會犯類似的錯誤。

　　安全性測試 。應(yīng)該由專業(yè)的安全性測試人員測試應(yīng)用。這些測試應(yīng)該驗證所有在設(shè)計階段定義的安全需求都已經(jīng)得到滿足，并應(yīng)該包括應(yīng)用和主機基礎(chǔ)設(shè)施之上（建議盡可能與生產(chǎn)環(huán)境類似）的浸透測試。

　　保持應(yīng)用一個很重要的部分是確保安全的部署。如果部署不夠安全，所有在應(yīng)用代碼層的安全性努力可能也就付之東流了。而這一階段有時會被忽視。

　　網(wǎng)絡(luò)隔離 。Adobe、RSA Security和Sony等企業(yè)遭受了無數(shù)的攻擊，在這些攻擊中內(nèi)網(wǎng)安全的概念已不再成立。內(nèi)部網(wǎng)絡(luò)在某種情況下是滲透的邊界，我們應(yīng)盡可能讓攻擊者很難從這一點上得到什么。對于某些相對較新缺乏基于角色授權(quán)的NoSQL數(shù)據(jù)庫來講這一點尤其如此。為此，建議嚴(yán)格配置網(wǎng)絡(luò)，確保數(shù)據(jù)庫只能由相關(guān)主機訪問，比如應(yīng)用服務(wù)器。

　　API的防護 。為緩解REST API暴露和CSRF攻擊的風(fēng)險，需要對請求加以控制，限制它們的格式。例如，CouchDB已經(jīng)采用了一些重要的安全措施去緩解因為暴露的REST API導(dǎo)致的風(fēng)險。這些措施包括只接受JSON內(nèi)容格式。HTML表單限制為URL編碼的內(nèi)容格式，所以攻擊者不能使用HTML進行CSRF攻擊。另一項舉措是使用Ajax請求，得益于同源策略從瀏覽器發(fā)起的請求會被阻止。要確保在服務(wù)器的API中已經(jīng)取消了JSONP和跨域資源共享，不能從瀏覽器直接發(fā)起操作，這一點也很重要。某些數(shù)據(jù)庫，比如MongoDB，有很多第三方的REST API，其中許多都缺乏我們在此提到的安全措施。

　　人類容易犯錯，即使遵循所有安全開發(fā)最佳實踐，仍有可能在開發(fā)完后從軟件中找到漏洞。此外，在開發(fā)測試時未知的新的攻擊途徑可能會被發(fā)掘出來。因此，建議在運行期進行應(yīng)用的監(jiān)控和防御。盡管這些系統(tǒng)可能擅于發(fā)現(xiàn)和阻止某些攻擊，但是它們不了解應(yīng)用邏輯和那些假定運行的應(yīng)用下的規(guī)則，所以它們不能找出所有的漏洞。

　　Web應(yīng)用防火墻 。Web應(yīng)用防火墻（WAFs）是檢查HTTP數(shù)據(jù)流和檢測惡意HTTP事務(wù)的安全性工具。它們可以作為電器、網(wǎng)絡(luò)嗅探器、代理或網(wǎng)站服務(wù)器模塊來實現(xiàn)，具體目標(biāo)是為Web應(yīng)用提供一個獨立的安全層，檢測SQL注入之類的攻擊。盡管已知攻擊可以繞過防火墻13，但我們?nèi)匀惶岢珵檫@些系統(tǒng)增加檢測NoSQL注入的規(guī)則。

　　侵入檢測系統(tǒng) 。與可以在網(wǎng)絡(luò)層檢測攻擊的防火墻類似，基于主機的侵入檢測系統(tǒng)（HIDSs）監(jiān)控著應(yīng)用的執(zhí)行和服務(wù)器上的負(fù)載。HIDSs通常了解應(yīng)用的正常行為，對與預(yù)期行為不符的行為給出預(yù)警，它們可能是攻擊。此類工具可以檢測在操作系統(tǒng)上傳播的漏洞，但和SQL檢測或CSRF無關(guān)。

　　數(shù)據(jù)活動監(jiān)控 。數(shù)據(jù)活動監(jiān)控工具已成為組織數(shù)據(jù)防護的常規(guī)需求。它們控制數(shù)據(jù)的訪問，以自定義安全預(yù)警監(jiān)控活動，并創(chuàng)建數(shù)據(jù)訪問和安全事件審計報告。雖然大多數(shù)解決方案定位的都是關(guān)系型數(shù)據(jù)庫，但針對NoSQL數(shù)據(jù)存儲的監(jiān)控也已經(jīng)開始涌現(xiàn)出來了10。我們希望這些將不斷地改進成為NoSQL活動監(jiān)控的常規(guī)實踐。針對我們在本文演示過的注入攻擊，這些工具是非常有用的監(jiān)控和檢測系統(tǒng)。

　　安全信息與事件管理（SIEM）系統(tǒng)和威脅警報 。安全信息和事件管理系統(tǒng)整理日志并梳理日志的關(guān)聯(lián)關(guān)系去幫助攻擊的檢測。

　　此外，威脅警報工具可以幫助提供惡意IP地址和域上的數(shù)據(jù)，以及有危害的其他指標(biāo)，這能有助于檢測注入。

　　運行期應(yīng)用自我保護（ RASP ） 。運行期應(yīng)用自我保護引入了一種新的應(yīng)用安全方式，在此防御機制是在運行期嵌入到應(yīng)用中的，使其可以進行自我監(jiān)控。運行期應(yīng)用自我保護的優(yōu)點超過其他安全技術(shù)，因為它能夠檢查內(nèi)部的程序流轉(zhuǎn)和數(shù)據(jù)處理。在應(yīng)用中的關(guān)鍵位置設(shè)置檢查點能更精確地檢測更多的問題。而不利的一面是，運行期應(yīng)用自我保護付出了性能的代價，它高度依賴于編程語言，而且可能導(dǎo)致應(yīng)用在生產(chǎn)環(huán)境中中止運行。

　　NoSQL數(shù)據(jù)庫遭受像傳統(tǒng)數(shù)據(jù)庫一相的風(fēng)險問題。一些低層技術(shù)和協(xié)議已經(jīng)變了，但注入風(fēng)險、不正確的訪問控制管理以及不安全的網(wǎng)絡(luò)暴露仍然居高不下。我們建議使用具有內(nèi)置安全措施的成熟的數(shù)據(jù)庫。然而，即使使用最安全的數(shù)據(jù)存儲也無法阻止利用Web應(yīng)用中的漏洞去訪問數(shù)據(jù)存儲的注入攻擊。避免這些問題的其中一種方法是通過謹(jǐn)慎的代碼檢查和靜態(tài)分析。然而，這些很難實施并且可能有很高的誤報率。盡管動態(tài)分析工具已表明對檢測SQL注入攻擊很有作用，但它們需要做出調(diào)整去檢測我們在本文中所說的那些特定于NoSQL數(shù)據(jù)庫的漏洞。此外，與NoSQL風(fēng)險相關(guān)的監(jiān)控和防御系統(tǒng)也應(yīng)該利用起來。 Imperva Web Application Attack Report , 4th ed., Imperva, 2013; State of Software Security Report , Varacode, 2013; A. Lane, "No SQL and No Security" , blog, 9 Aug. 2011; L. Okman et al. "Security Issues in NoSQL Databases", Proc. IEEE 10th Int’l Conf. Trust, Security and Privacy in Computing and Communications (TrustCom), 2011, pp. 541–547. E. Sahafizadeh and M.A. Nematbakhsh. "A Survey on Security Issues in Big Data and NoSQL", Int’l J. Advances in Computer Science, vol. 4, no. 4, 2015, pp. 2322–5157. M. Factor et al. "Secure Logical Isolation for Multi- tenancy in Cloud Storage", Proc. IEEE 29th Symp. Mass Storage Systems and Technologies (MSST), 2013, pp. 1–5. "Security" , MongoDB 3.2 Manual, 2016; I. Novikov, "The New Page of Injections Book: Memcached Injections" , Proc. Black Hat USA, 2014; J. Williams, "7 Advantages of Interactive Application Security Testing (IAST) over Static (SAST) and Dynamic (DAST) Testing" , blog, 30 June 2015; K. Zeidenstein, "Organizations Ramp up on NoSQL Databases, but What about Security?" , blog, 1 June 2015; V. Haldar, D. Chandra, and M. Franz, "Dynamic Taint Propagation for Java", Proc. IEEE 21st Computer Security Applications Conf., 2005, pp. 303–311. S.M. Kerner, "Glass Box: The Next Phase of Web Application Security Testing?" , blog, 3 Feb. 2012; I. Ristic, "Protocol-Level Evasion of Web Application Firewalls" , Proc. Black Hat USA, 2012.

　　來自：http://www.infoq.com/cn/articles/nosql-injections-analysis