《NoSQL注入的分析和緩解》要點：
本文介紹了NoSQL注入的分析和緩解，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者 | Aviv Ron Alexandra-Shulman-Peleg Anton Puzanov

譯者 | 冬雨 ?

本文要點：

• 了解針對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)用推動起來的,比如Facebook、Amazon和Twitter,它們需要把數(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ù),以及它們的緩解機制.

NoSQL 漏洞

幾乎就像每種新技術(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)注.

NoSQL攻擊途徑

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查詢以及數(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)該是這樣的：

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

PHP重言式注入

讓我們審視一下圖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)類型,在本例中,可使用字符串,如下所示：

NoSQL聯(lián)合查詢注入

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 JavaScript注入

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í)行.

看一下如下輸入：

a);}},function(kv) { return 1; }, { ? ?out: ‘x’ });db.injection. insert({success:1});return 1;db.stores.mapReduce(function() { { ? ?emit(1,1

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

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

鍵值對數(shù)據(jù)存儲

像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ù)式查詢攻擊.
  

  背負(fù)式查詢

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

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

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

研究人員表示,該驅(qū)動程序未能針對帶有回車\r(0x0D)和換行的\n(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就很容易受到這種注入攻擊.

跨域違規(guī)

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.

開發(fā)和測試

為充分解決由應(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)隔離.在過去,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,其中許多都缺乏我們在此提到的安全措施.

監(jiān)控和攻擊檢測

人類容易犯錯,即使遵循所有安全開發(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.
  

  關(guān)于作者

• Aviv Ron 是IBM網(wǎng)絡(luò)安全卓越中心的安全研究員.他的研究興趣包括應(yīng)用安全,特別是云環(huán)境的安全.Ron擁有Ben Gurion大學(xué)的計算機科學(xué)學(xué)士學(xué)位.Alexandra Shulman-Peleg 是花旗銀行云安全領(lǐng)域的一名負(fù)責(zé)人.在準(zhǔn)備這篇文章的期間,她是IBM網(wǎng)絡(luò)安全卓越中心的高級研究員.她的研究興趣包括云安全.Shulman-Peleg擁有Tel Aviv大學(xué)的計算機科學(xué)博士學(xué)位.她曾在頂級期刊、大會和書籍中發(fā)表了30多篇科學(xué)出版物.Anton Puzanov 是IBM網(wǎng)絡(luò)安全卓越中心的安全研究員.他的研究興趣包括應(yīng)用安全測試產(chǎn)品.Puzanov擁有Ben Gurion大學(xué)的通信系統(tǒng)工程學(xué)士學(xué)位.本篇文章已經(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).

文章來微信公眾號：高效開發(fā)運維

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4242.html