程 飛,沈 波
(北京交通大學 通信與信息系統(tǒng)北京市重點實驗室,北京 100044)
隨著網(wǎng)絡(luò)架構(gòu)研究的不斷深入,表述性狀態(tài)轉(zhuǎn)移(REST,Representational State Transfer)技術(shù)日益成熟,REST架構(gòu)不但能提高Web應用的運行效率,還可以簡化開發(fā)過程,已經(jīng)在電子政務(wù)、電子商務(wù)等領(lǐng)域得到廣泛的應用。但這些新技術(shù)在給社會發(fā)展帶來便利的同時,也帶來了巨大的安全風險。
針對REST應用的攻擊手段與破壞程度,其被關(guān)注程度越來越高,已經(jīng)超過了對傳統(tǒng)安全問題的關(guān)注度[1]。文獻[2]中闡述了構(gòu)造REST的Web服務(wù)接口,同時針對REST安全性將其與WS-*技術(shù)進行比較。文獻[3]中闡述了REST APIs可能存在的安全隱患并給出防范建議。
本文通過對REST安全性的分析與總結(jié),找出常見的安全問題及安全策略。根據(jù)REST安全問題在應用中的作用原理,給出應對策略。最后建立REST的安全模型及安全檢測系統(tǒng),通過攻擊演示證明系統(tǒng)的可用性。
REST并不是一種協(xié)議或標準,而HTTP是一種應用協(xié)議,REST經(jīng)常作為傳輸協(xié)議詮釋HTTP協(xié)議的設(shè)計初衷?;ヂ?lián)網(wǎng)上的各種資源就是通過HTTP協(xié)議的4種基本操作實現(xiàn)類似數(shù)據(jù)庫中增刪查改功能,REST規(guī)定了定位資源的規(guī)則,并對資源通過 HTTP協(xié)議實現(xiàn)操作[4]。
(1)REST風格API的快速發(fā)展?,F(xiàn)在很多基于REST風格的API已經(jīng)由只讀模式轉(zhuǎn)變成讀寫模式,這極大的促進了人機和機器之間的交互性,但權(quán)限的增加意味著安全性的降低。(2)認證和授權(quán)方式不夠完善。例如密鑰沒有加密或是靜態(tài)加密;一些基于HTTP的認證授權(quán)沒有使用安全套接層(SSL,Secure Sockets Layer);自定義的權(quán)限文件AuthZ存在缺陷等。(3)API設(shè)計者對Web基本應用安全的忽視及對API的不合理調(diào)用。開發(fā)人員對安全風險考慮不足,尤其是對新安全問題缺乏足夠認識,或?qū)赡艽嬖诎踩[患的危險函數(shù)或程序使用不當。(4)Mashup的廣泛應用使REST安全性降低。不同API聚集使安全風險升高,向Mashup添加新工件或數(shù)據(jù)源會增加安全漏洞,不同API之間的匿名請求可能存在安全隱患;同源策略無法給予網(wǎng)絡(luò)保護。
通過對REST架構(gòu)和常見安全隱患的分析發(fā)現(xiàn),與REST密切相關(guān)的安全問題包括注入攻擊、跨站腳本攻擊、跨站請求偽造和會話固定攻擊等。其中跨站腳本攻擊、注入式攻擊在發(fā)生時有一個共同點,即攻擊者都是通過偽造URL參數(shù)或輸入數(shù)據(jù)來實現(xiàn)對基于REST的應用程序的攻擊;另外,中斷認證和會話固定以及跨站腳本偽造等攻擊手段都是通過與服務(wù)器傳遞給用戶的會話ID實現(xiàn)的,而很多基于REST應用的會話ID都會保存在cookie中,所以,會話類攻擊可以通過對cookie進行處理加以防范。
本文采取的防范策略結(jié)構(gòu)如圖1所示。
圖1 策略方案基本框架結(jié)構(gòu)
(1)參數(shù)化查詢。設(shè)計與數(shù)據(jù)庫鏈接或訪問數(shù)據(jù)時,使用參數(shù)給的值填入需要添加的地方,這樣就將執(zhí)行代碼與數(shù)據(jù)分離。(2)輸入信息檢測。輸入信息檢測會在服務(wù)器與用戶端進行,用戶端會檢測用戶輸入信息,服務(wù)器端則檢測HTTP請求頭中的Content-Type、Host、Content-Length等信息,以及報文體的用戶輸入信息,檢測輸入的格式、地址、長度等。為確保檢測效果,本文采用客戶端和服務(wù)器端雙重檢測的策略。(3)屏蔽返回的出錯信息。輸入錯誤時,響應報文要使瀏覽器只顯示一種錯誤信息。(4)過濾危險字符。服務(wù)器端要過濾掉敏感字符,同時可使用白名單機制,只允許名單內(nèi)的用戶通過。
(1)對輸入進行驗證。可在服務(wù)器與用戶端進行,檢測的內(nèi)容與注入式攻擊的檢測相似,除了檢測HTTP請求頭中的Content-Type、Host、Content-Length等信息外,服務(wù)器端還要檢測報文體中用戶輸入的語法。(2)對輸出進行檢查并指定編碼方式。字符串過濾過程中API需要把過濾規(guī)則和數(shù)據(jù)庫及前臺共享。對輸出進行編碼必不可少,HTTP響應報文頭的charset對此做了規(guī)定。(3)對字符串過濾。本文采用白名單機制,也就是只允許指定語法的輸入信息通過,這樣對安全性更有保障。
(1)會話超時機制。瀏覽器與服務(wù)器建立通信時不使用長連接,使HTTP請求與響應報文的Connection項是close狀態(tài)。(2)同步令牌機制。典型的是使用一次性令牌策略,要求服務(wù)器對每個響應報文都重新發(fā)送會話令牌Set-Cookie。(3)雙向認證機制。檢測報文體的用戶輸入,發(fā)現(xiàn)相關(guān)事務(wù)會要求用戶端的再次確認。(4)挑戰(zhàn)應答機制。需要服務(wù)器端增加挑戰(zhàn)應答引擎,在響應報文中增加一項給用戶傳送“挑戰(zhàn)”字符串,用戶的請求報文也要增加一項“應答”字符串。(5)驗證請求來源。就是驗證HTTP請求報文頭的Referer字段。
(1)拒絕用戶指定會話標識。即Cookie項由服務(wù)器端賦值,通過響應報文的Set-Cookie進行賦值。(2)使用更安全的會話標識。要求服務(wù)器產(chǎn)生Set-Cookie項的引擎更加強大,使用更復雜的算法產(chǎn)生更難破解的隨機數(shù)。(3)會話標識綁定網(wǎng)絡(luò)地址。要求Set-Cookie項與用戶的IP地址相關(guān),服務(wù)器端要增加一個檢測會話標識與IP地址相關(guān)度的引擎。
本文使用SQL injection中的1‘or’1‘=’1方式來演示注入式攻擊,這里注入下列攻擊代碼:Fei' OR '1'='1。
系統(tǒng)檢測到敏感字段,發(fā)出注入式攻擊的警報并生成日志對這次攻擊進行了記錄,如圖2所示。采用本文的REST安全模型,系統(tǒng)對用戶進行輸入檢測及過濾并使用參數(shù)化查詢等策略有效防范了這次攻擊。
圖2 SQL注入攻擊警報檢測記錄
本文使用存儲型XSS攻擊,在頁面代碼中添加一個惡意的JavaScript腳本,被攻擊者在點擊被注入的腳本時瀏覽器執(zhí)行腳本中的惡意代碼,完成XSS攻擊。示例演示通過惡意腳本獲取被攻擊用戶的cookie,添加的腳本代碼為:
系統(tǒng)在檢測到敏感字段后產(chǎn)生的XSS攻擊記錄如圖3所示。
圖3 XSS攻擊檢測記錄
對CSRF攻擊檢測示例中攻擊者編寫一個帶惡意請求的HTML文件,例如惡意請求為轉(zhuǎn)移5000資金,在REST中具體實現(xiàn)的過程是先創(chuàng)建一個轉(zhuǎn)賬交易資源transferFunds,然后加入?yún)?shù)。本文采用如下代碼:
被攻擊者通過驗證產(chǎn)生cookie,攻擊者利用上面的惡意請求使用此cookie訪問信任網(wǎng)站,實現(xiàn)轉(zhuǎn)移資金的操作,完成CSRF攻擊。系統(tǒng)檢測到輸入會造成CSRF攻擊產(chǎn)生的記錄,同時系統(tǒng)發(fā)出警報,如圖4所示。系統(tǒng)采用會話超時機制、令牌同步機制、雙向認證機制策略有效防范了這種攻擊。
圖4 CSRF攻擊檢測記錄
對會話固定攻擊的檢測里攻擊者在郵件中加入如下代碼:
其中SID表示要被用來固定的會話令牌,服務(wù)器端通過rewrite規(guī)則實現(xiàn)REST風格。收信者按照郵件的鏈接登錄基于REST應用后,攻擊者得到收信者的權(quán)限,實施會話固定攻擊。系統(tǒng)采用會話超時機制、令牌同步機制、雙向認證機制策略避免這種攻擊。
檢測結(jié)果表明本系統(tǒng)能有效識別并防范注入式攻擊、XSS攻擊、CSRF攻擊及會話固定攻擊等REST常見安全問題,同時能給出詳細攻擊信息。
本文通過對REST安全性的分析與總結(jié),找出REST常見的安全問題及可以使用的安全策略。建立了REST安全檢測系統(tǒng),并通過攻擊演示證明系統(tǒng)的可用性。測試結(jié)果表明,采用本文的安全檢測系統(tǒng)能有效檢測并防御REST常見安全問題。下一步的工作是增強系統(tǒng)檢測庫的自我學習能力,使其能自主分析問題,更新檢測規(guī)則,提高檢測效率。同時提出更高效的實現(xiàn)機制,并且通過仿真過程驗證系統(tǒng)的科學性、算法的復雜度、實現(xiàn)機制的可行性。
[1]馮新?lián)P,沈建京.REST和RPC:兩種Web服務(wù)架構(gòu)風格比較分析[J].小型微型計算機系統(tǒng),2010,12(7):1393-1395.
[2]Joe Gregorio. REST and WS[OL]. http://bitworking.org/news/125/REST-and-WS,2007.
[3]Pete Soderling, Chris Comerford. Why REST Security Doesn’t Exist(and What to Do About It)[C]. RSA CONFERENCE ,2010.
[4]陳 磊. REST的真諦[J].軟件世界,2007(17).