李彥廣

（商洛學(xué)院 計(jì)算機(jī)科學(xué)系,陜西商洛 726000）

HTTP平臺(tái)是網(wǎng)絡(luò)安全性的熱點(diǎn)同時(shí)也是難點(diǎn)問(wèn)題，現(xiàn)在好多研究只是關(guān)注對(duì)常規(guī)攻擊的防范，比如文獻(xiàn)[1]提出XSS注入式攻擊的防范加轉(zhuǎn)義輸入尖括號(hào)；文獻(xiàn)[2]提出CRSF注入式攻擊的防范設(shè)置 Cookie，為 HttpOnly以及增加Session相關(guān)的Hash Token碼；文獻(xiàn)[3]提出SQL注入攻擊的防范將分號(hào)轉(zhuǎn)義等。雖然這些做起來(lái)簡(jiǎn)單，但不足以解決現(xiàn)階段的網(wǎng)絡(luò)攻擊模式，需要了解基于HTTP平臺(tái)傳遞信息的原理，更深層次的解讀現(xiàn)有的防范措施的原理，找出其漏洞，以便對(duì)現(xiàn)有的防范措施升級(jí)。HTTP平臺(tái)的防御策略探析從平臺(tái)的安全性著手，探討HTTP平臺(tái)搭建所涉及的技術(shù)細(xì)節(jié)。根據(jù)需要傳遞信息，找出最佳的選擇。

1 HTTP協(xié)議的安全性分析

HTTP是一種無(wú)狀態(tài)的應(yīng)用層協(xié)議，所涵蓋的信息都是未經(jīng)加密的明文，包括請(qǐng)求參數(shù)、返回值、Cookie、Head 等[2]。因此，外界通過(guò)對(duì)通信的監(jiān)聽(tīng)，可以輕而易舉地模擬出請(qǐng)求和響應(yīng)雙方的格式，從而偽造請(qǐng)求與響應(yīng)、修改和竊取各種信息。相對(duì)于TCP協(xié)議層的Socket傳輸方式，針對(duì)HTTP協(xié)議的攻擊門檻低。因此，基于HTTP協(xié)議的Web及SOA架構(gòu)，在應(yīng)用的安全性方面，需要更加重視。因此，在實(shí)際傳遞信息過(guò)程中，常采用摘要簽名法、公私鑰簽名法、HTTPS法、應(yīng)用授權(quán)法，為進(jìn)一步做好信息傳遞的安全性，有必要對(duì)這些方法作進(jìn)一步分析研究。

2 摘要簽名法分析

2.1 客戶端請(qǐng)求

對(duì)于重要的數(shù)據(jù)，關(guān)心它的真實(shí)性和準(zhǔn)確性，因此要保證在通信的過(guò)程中，數(shù)據(jù)不被第三方篡改。在圖1中，請(qǐng)求的參數(shù)經(jīng)過(guò)排序，將參數(shù)名稱和值經(jīng)過(guò)一定的策略組織起來(lái)，加上一個(gè)密鑰，然后通過(guò)摘要算法生成簽名[4]。通常的算法包括MD5、SHA等，根據(jù)算法的不可逆性和參數(shù)的多變性，在一定程度上保證了通信的安全性。

圖1 簽名構(gòu)造

2.2 服務(wù)端校驗(yàn)

在圖2中，服務(wù)器端接收到請(qǐng)求后，以相同的順序?qū)?shù)進(jìn)行排序并且鏈接起來(lái)，加上相同的密鑰，以相同的密鑰算法生成簽名，然后與請(qǐng)求的信息簽名進(jìn)行比較，若相同，信息合法，否則，非法。

服務(wù)器校驗(yàn)完成后，生成響應(yīng)，同樣的，響應(yīng)的內(nèi)容也進(jìn)行同樣的簽名，客戶端收到響應(yīng)后，根據(jù)接收的sign來(lái)驗(yàn)證簽名的合法性。

圖2 簽名的校驗(yàn)

2.3 實(shí)驗(yàn)證明

有一個(gè)請(qǐng)求：www.xxx.com/api.do?userid=123456789&page=1&pagesize=108&signtype=MD5&charset=gbk&method=com.chenkangxian.getname&sign=aef503e0ae7c27b04c2fe1cc95ce1d,在這個(gè)請(qǐng)求中，userid、page、pagesize是常規(guī)參數(shù)，signtype為加密類型，charset表示編碼，method表示接口類型，sign表示生成的字符串，為了方便傳輸，采用BASE64編碼，服務(wù)器端將接收來(lái)的參數(shù)拼接成userid=123456789&page=1&pagesize=108&signtype=MD5&charset=gbk&method=com.chenkangxian.getname，采用md5算法生成簽名串為aef503e0ae7c27b04c2fe1cc95ce1d，與傳遞過(guò)來(lái)的sign=aef503e0ae7c27b04c2fe1cc95ce1d相同，這個(gè)請(qǐng)求合法。

3 公私鑰簽名法分析

在摘要簽名中解決了合法性校驗(yàn)問(wèn)題，但密鑰相對(duì)固定，若多客戶端調(diào)用，容易造成密鑰泄露，為了解決這一缺陷，可以給每一客戶配一對(duì)公私鑰。

3.1 客戶端簽名

客戶端在請(qǐng)求時(shí)，客戶端將參數(shù)按一定的策略組合起來(lái)，形成一定的順序，拼成一個(gè)字符串，MD5后，通過(guò)私鑰加密生成簽名，整個(gè)過(guò)程如圖3。

3.2 服務(wù)器端驗(yàn)證

在服務(wù)器端，采用圖3相同的操作，采取相同的參數(shù)順序，促成字符串MD5,通過(guò)客戶端的公鑰解密簽名，與其MD5生成的值進(jìn)行比較，以此來(lái)推斷數(shù)據(jù)的合法性。

圖3 客戶端私鑰簽名

3.3 客戶端驗(yàn)證

采用相同的方法，使用服務(wù)器端的公鑰，對(duì)服務(wù)器端校驗(yàn)（如圖4）。

圖4 服務(wù)器端公鑰校驗(yàn)

4 HTTPS法分析

摘要簽名及公私鑰簽名很好的解決了數(shù)據(jù)的合法性問(wèn)題，但對(duì)一些重要的信息采取明文傳輸，風(fēng)險(xiǎn)很大，主要存在兩個(gè)方面，一是服務(wù)器端的公鑰與密鑰相對(duì)穩(wěn)定，容易泄露；二是服務(wù)器的身份難以保證，第三方可以通過(guò)域名欺騙來(lái)偽造身份，欺騙客戶端向偽服務(wù)器發(fā)送信息[5]，這樣一來(lái)，所有的信息就暴露無(wú)疑，造成損失將不可估量，因此，采用 SSL（Secure Socket Layer），這種協(xié)議的加密手段更加嚴(yán)格，從而保證信息的安全性。

4.1 SSL（Secure Socket Layer 安全套接層）安全優(yōu)勢(shì)

SSL（Secure Socket Layer安全套接層）是Netscape公司率先采用的網(wǎng)絡(luò)安全協(xié)議。它是在傳輸通信協(xié)議（TCP／IP）上實(shí)現(xiàn)的一種安全協(xié)議，采用公開(kāi)密鑰技術(shù)[6]。SSL廣泛支持各種類型的網(wǎng)絡(luò)，同時(shí)提供三種基本的安全服務(wù)，它們都使用公開(kāi)密鑰技術(shù)。通過(guò)SSL協(xié)議，能夠完成對(duì)服務(wù)器端的認(rèn)證、加密數(shù)據(jù)，防止在傳輸過(guò)程中信息的泄露和篡改，在很大程度上保證了通信的安全性。

4.2 SSL（Secure Socket Layer 安全套接層）安全的實(shí)現(xiàn)

依據(jù)SSL協(xié)議，HTTPS能夠確保整個(gè)通訊過(guò)程的加密，密鑰的產(chǎn)生是隨機(jī)的，整個(gè)通訊過(guò)程通過(guò)數(shù)字驗(yàn)明證書(shū)驗(yàn)證通訊雙方的身份，從而保障了通訊的安全性[7]。

圖5 HTTPS通信時(shí)序圖

圖5給出了SSL協(xié)議的握手過(guò)程，首先，客戶端向服務(wù)端發(fā)送SSL協(xié)議的版本號(hào)、支持的加密算法類型、產(chǎn)生的隨機(jī)數(shù)，以及其他客戶端與服務(wù)端通信所需的重要信息；隨后，服務(wù)端收到客戶端的信息，將它自己的SSL協(xié)議版本、支持的加密算法類型，以及產(chǎn)生的隨機(jī)數(shù)等內(nèi)容，加上它的數(shù)字證書(shū)，一起回復(fù)給客戶端。

4.3 校驗(yàn)過(guò)程

證書(shū)以證書(shū)鏈的形式組織，客戶端逐級(jí)校驗(yàn)證書(shū)的合法性，其中包括服務(wù)器域名是否與證書(shū)中的域名一致、證書(shū)是否在有效期內(nèi)、辦法證書(shū)的機(jī)構(gòu)是否合法，這整個(gè)過(guò)程對(duì)用戶來(lái)說(shuō)是透明的[8]。

4.4 握手完成

校驗(yàn)完證書(shū)后，客戶端將產(chǎn)生一個(gè)預(yù)主密碼，并用服務(wù)器所給的公鑰加密后傳送給服務(wù)器端，服務(wù)端會(huì)根據(jù)預(yù)主密碼來(lái)生成通信密碼，在此同時(shí)，客戶端也以相同的方式生成通信密碼，這樣，一次通信握手基本完成。

5 應(yīng)用授權(quán)法分析

摘要簽名法、公私鑰簽名法、HTTPS法都是在通信雙方信任的基礎(chǔ)上完成的，客戶端直接與服務(wù)端鏈接并完成數(shù)據(jù)傳輸?，F(xiàn)在還有一種用法是平臺(tái)商將數(shù)據(jù)有限的開(kāi)放給ISV(第三方軟件廠商)，ISV利用這些數(shù)據(jù)來(lái)給用戶提供服務(wù)，它的前提是ISV必須得到用戶的授權(quán)，因此，在應(yīng)用授權(quán)法中使用了OAuth協(xié)議，使用OAuth協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全、開(kāi)放的標(biāo)準(zhǔn)。

5.1 OAuth協(xié)議的安全優(yōu)勢(shì)

OAuth協(xié)議的出現(xiàn)，使得用戶在不泄露自己的用戶名和密碼的情況下，能夠完成對(duì)第三方應(yīng)用的授權(quán)[9]。從圖6可看見(jiàn)，第三方應(yīng)用得到用戶授權(quán)后，便可以在一定時(shí)間內(nèi)訪問(wèn)到用戶授權(quán)的數(shù)據(jù)。

圖6 服務(wù)端用公鑰簽名

5.2 OAuth協(xié)議授權(quán)的實(shí)現(xiàn)

在圖6的數(shù)據(jù)訪問(wèn)流程中，用戶先對(duì)ISV(第三方軟件廠商)發(fā)起請(qǐng)求，ISV向平臺(tái)商請(qǐng)求Request Token，帶上其申請(qǐng)的App ID，平臺(tái)返回Request頁(yè)面，帶上自己的App ID、Request Token以及回調(diào)地址，用戶在平臺(tái)的頁(yè)面上完成授權(quán)。然后平臺(tái)通過(guò)ISV提供的回調(diào)鏈接，返回給ISV應(yīng)用Access Token，ISV應(yīng)用Access Token取到用戶授權(quán)的數(shù)據(jù)，進(jìn)行加工后返回給用戶，授權(quán)完成。

5.3 OAuth協(xié)議授權(quán)的安全實(shí)現(xiàn)

為了確保通信的安全，一般會(huì)讓ISV使用期私鑰對(duì)參數(shù)進(jìn)行簽名，平臺(tái)使用ISV的公鑰進(jìn)行簽名驗(yàn)證，以此來(lái)驗(yàn)證ISV的資質(zhì)，具體實(shí)現(xiàn)過(guò)程在前幾種方法中已論述。

OAuth協(xié)議授權(quán)是一個(gè)相對(duì)復(fù)雜的過(guò)程，包含了系統(tǒng)的方方面面，比如，通信的加密解密，以及權(quán)限劃分、Token生成和校驗(yàn)、公私鑰管理以及分布式Session機(jī)制等，相對(duì)過(guò)去來(lái)說(shuō)，由于開(kāi)源社區(qū)的發(fā)展，為其實(shí)現(xiàn)降低了不少門檻，目前已出現(xiàn)了很多開(kāi)源的解決方案[10]。

6 結(jié)語(yǔ)

網(wǎng)絡(luò)安全一直是全世界關(guān)注的焦點(diǎn)，如何有效實(shí)現(xiàn)網(wǎng)絡(luò)安全，查找漏洞、消除隱患，也是人們最頭痛的問(wèn)題。本文結(jié)合HTTP平臺(tái)安全隱患常用的防御方法，在分析HTTP平臺(tái)傳遞信息的原理的基礎(chǔ)上，給出了HTTP平臺(tái)搭建過(guò)程中所面臨的問(wèn)題以及解決的方法，分析了每種方法的工作原理及存在的缺陷。通過(guò)對(duì)比分析，應(yīng)用授權(quán)法的安全級(jí)別相對(duì)較高，OAuth授權(quán)是一個(gè)相對(duì)復(fù)雜的體系，涵蓋了系統(tǒng)的方方面面，包括通信的加密解密，權(quán)限的劃分、Token生成和校驗(yàn)、公私鑰的管理，相對(duì)前幾年來(lái)說(shuō)，由于開(kāi)源社區(qū)的發(fā)展，為其實(shí)現(xiàn)降低了不少門檻，目前已有很多開(kāi)源解決方案，平時(shí)應(yīng)用時(shí)，可以根據(jù)用戶的需要，選擇最佳的防御策略。

[1]李馥娟.基于Cookies的Web應(yīng)用分析及其安全研究[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用,2009(6):88-93.

[2]馮 挺,王 慧.WEB服務(wù)認(rèn)證[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2009(8):209-216.

[3]趙 娜.淺談WEB應(yīng)用漏洞的防御解決方案[J].計(jì)算機(jī)與網(wǎng)絡(luò),2011(8)236-237.

[4]張衛(wèi)全,胡志遠(yuǎn).淺析作用于WEB2.0安全防范的OpenId和Oauth機(jī)制[J].通訊管理與技術(shù),2011(2):15-20.

[5]王宇飛,范明鈺,王光衛(wèi).一種基于HTTP摘要認(rèn)證的SIP安全機(jī)制[J].重慶郵電學(xué)院學(xué)報(bào):自然科學(xué)版,2005,17(6):769-774.

[6]古治鋼.基于驗(yàn)證碼破解的HTTP攻擊原理與防范[J].計(jì)算機(jī)工程,2006,32(7):170-174.

[7]袁 志.一種抵御HTTP洪水攻擊的方法[J].計(jì)算機(jī)工程,2012,39(7):271-276.

[8]孫長(zhǎng)華,劉 斌.分布式拒絕服務(wù)攻擊研究新進(jìn)展綜述[J].電子學(xué)報(bào),2009,37(7):1562-1569.

[9]Gsvrilis D,Chatis I,Dermatas E.Flash crowd detection using decoy Hyperlinks[C]//Sensing and control.IEEE International Conference on Networking,2007:466-470.

[10]茍 寧.網(wǎng)絡(luò)安全性能測(cè)試平臺(tái)-HTTP、FTP、POP3模塊設(shè)計(jì)與實(shí)現(xiàn)[D].四川大學(xué),2004.