網(wǎng)絡(luò)協(xié)議信息隱藏

1、第五章 網(wǎng)絡(luò)協(xié)議信息隱藏 5.1 基于網(wǎng)絡(luò)層協(xié)議的信息隱藏 【實驗?zāi)康摹俊緦嶒災(zāi)康摹?【實驗環(huán)境】【實驗環(huán)境】 【原理簡介】【原理簡介】 【實驗步驟】【實驗步驟】 【實驗結(jié)果】【實驗結(jié)果】 【思考題】【思考題】 【實驗?zāi)康摹俊緦嶒災(zāi)康摹?掌握網(wǎng)絡(luò)層信息隱藏的原理， 理解在網(wǎng)絡(luò)層兩種主要協(xié)議上 進行信息隱藏的基本方法，使 用VC設(shè)計并實現(xiàn)一種網(wǎng)絡(luò)層信 息隱藏算法。 【實驗環(huán)境】 (1) 網(wǎng)絡(luò)環(huán)境：100Mbps交換 式以太網(wǎng)，2臺主機，其中包 括發(fā)送端(/24)與 接收端(/24)； (2) 操作系統(tǒng)：Windows2000 或2.4.20以上版本的L

2、inux （如Redhat9和Fedora系列）； (3) 編程工具：Microsoft Visual C+ 6.0。 【原理簡介】【原理簡介】 IPV4網(wǎng)絡(luò)協(xié)議設(shè)計時存在漏洞，首部存在 冗余或可選字段，網(wǎng)絡(luò)設(shè)備對某些字段限 制過于寬松，通過精心設(shè)計和構(gòu)造，可以 利用這些字段進行信息隱藏以實現(xiàn)隱蔽通 信。這種通信不增加額外帶寬，很難被網(wǎng) 絡(luò)防火墻和入侵檢測系統(tǒng)檢測到，容易逃 避網(wǎng)絡(luò)監(jiān)控，實現(xiàn)信息隱藏的目的。 傳統(tǒng)信息隱藏的載體是靜態(tài)的多媒體數(shù)據(jù)， 而網(wǎng)絡(luò)隱蔽通道的載體是動態(tài)的網(wǎng)絡(luò)協(xié)議 的首部，這種載體上的區(qū)別是兩者最根本 的區(qū)別；前者依賴于人的視覺或聽覺不敏 感性，而后者是基于網(wǎng)絡(luò)協(xié)議在語法或

3、語 義上的冗余；前者的隱匿性主要對于人感 官上的不可感知，而后者的隱匿性是對于 網(wǎng)絡(luò)監(jiān)控設(shè)備而言的。 多媒體數(shù)據(jù)中存在大量的信息冗余，網(wǎng)絡(luò) 協(xié)議數(shù)據(jù)包中的冗余顯然要少許多；多媒 體有著復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，任取其中的一個 數(shù)據(jù)(像素、視頻幀等)進行數(shù)值改寫，幾 乎不會對它的感官效果產(chǎn)生影響，而網(wǎng)絡(luò) 協(xié)議的數(shù)據(jù)包中的各個首部字段都是最簡 單的“01”比特串，對首部字段取值的改 寫不但徹底改變了數(shù)據(jù)包的類型，而且有 可能使得這個數(shù)據(jù)包由于畸形而被丟棄。 網(wǎng)絡(luò)協(xié)議信息隱藏(協(xié)議隱寫)是一種利用 數(shù)據(jù)包作為掩護載體，將秘密信息隱匿在 網(wǎng)絡(luò)協(xié)議的數(shù)據(jù)包之中的信息隱藏技術(shù)， 它可以通過網(wǎng)絡(luò)協(xié)議數(shù)據(jù)包中的保留、可

4、 選、未定義等字段和數(shù)據(jù)包的順序、數(shù)量、 到達(dá)時間、特定時間流量以及其它可被利 用的特征，在網(wǎng)絡(luò)中不同的主機之間建立 隱蔽通信。 利用協(xié)議隱寫進行隱蔽通信時，發(fā)送端在協(xié)議數(shù)據(jù) 包中使用嵌入算法嵌入秘密信息，得到攜密數(shù)據(jù)包， 可將隱蔽通信劃分為6種模式： 上圖中的嵌入進程即為隱蔽通信的發(fā)送方，提取進程 為接收方。根據(jù)網(wǎng)絡(luò)通信的實際情況，6種模式中其 實只有模式A和模式C是可行的。由于模式C需要重寫 操作系統(tǒng)的網(wǎng)絡(luò)協(xié)議驅(qū)動，故此處采用模式A，即發(fā) 送方自己產(chǎn)生載體（即正常協(xié)議數(shù)據(jù)包），發(fā)送方和 接收方分別是數(shù)據(jù)流的始點和終點，如下圖： 在上圖中，發(fā)送端的嵌入進程將秘密信息嵌入數(shù)據(jù)包的首部， 通過網(wǎng)

5、絡(luò)傳輸后，接收方利用檢測進程檢測出攜帶秘密信息 的數(shù)據(jù)包后提取出信息，根據(jù)用戶的需要可以保存成文件， 也可立即顯示。 最早被用來進行協(xié)議隱寫的協(xié)議是IP協(xié)議，其首部如下圖所 示，圖中灰色陰影部分可直接用于隱藏信息。 網(wǎng)絡(luò)層的另一種協(xié)議是ICMP（互聯(lián)網(wǎng)控制報文協(xié)議）， 它通常被IP層或更高層協(xié)議用來傳遞差錯報文，下面 介紹利用ICMP的8位代碼字段進行協(xié)議隱寫的原理。 ICMP的報文格式根據(jù)前16個字節(jié)的變化而各有不同， 下圖是回顯應(yīng)答和回顯請求報文的格式。 針對ICMP協(xié)議，實現(xiàn)信息發(fā)送程序，在接 收端利用原始套接字進行嗅探接收。先對 一個首部字段填寫自定義數(shù)值、其它字段 填充正常值，然后發(fā)

6、送該數(shù)據(jù)包，記錄嗅 探器的嗅探結(jié)果。以ICMP為例，測試隱寫 載體的發(fā)送程序如下頁圖所示。 對ICMP的所有首部字段進行實驗，發(fā)現(xiàn)所 有的首部字段都可隨意設(shè)置，雖然RFC規(guī) 定了ICMP回顯請求和回顯應(yīng)答的報文格式， 但8位代碼字段的取值對報文的功能沒有 任何影響，模擬Ping程序在8位代碼字段 設(shè)置為任意值的情況下仍能從遠(yuǎn)端主機返 回回顯應(yīng)答，表明此字段是協(xié)議隱寫的良 好載體。 【實驗步驟】【實驗步驟】 1.算法描述 2.數(shù)據(jù)結(jié)構(gòu) 3.算法實現(xiàn) 1.算法描述 實驗的主要思路是在網(wǎng)絡(luò)層實現(xiàn)信息發(fā)送 及接收程序，由于在底層實現(xiàn)該程序，需 要手工構(gòu)造IP報文的首部字段來自定義發(fā) 送數(shù)據(jù)包，因此必須

7、使用Raw Socket編程。 Raw Socket允許程序繞過系統(tǒng)內(nèi)核而直接 訪問底層協(xié)議，因此IP層的封裝工作就要 用手工填充數(shù)據(jù)的方法實現(xiàn)，而不是由操 作系統(tǒng)自動完成。由于Raw Socket經(jīng)常被 用來編寫網(wǎng)絡(luò)掃描程序等惡意軟件，微軟 在Windows XP的協(xié)議驅(qū)動tcpip.sys中， 基于安全考慮已經(jīng)對利用Raw Socket發(fā)送 數(shù)據(jù)包進行了限制，故底層數(shù)據(jù)包發(fā)送程 序在Windows 2000下通過VC6.0實現(xiàn)。 由于使用原始套接字發(fā)送數(shù)據(jù)包，數(shù)據(jù)包的某些 字段還被用來隱藏信息，接收端不能用普通的 Recv( )或Recvfrom( )來接收數(shù)據(jù)包，只能采用 嗅探的方式接收

8、發(fā)送方的數(shù)據(jù)。但網(wǎng)絡(luò)中的數(shù)據(jù) 包很多，這又會產(chǎn)生識別特定數(shù)據(jù)包的問題，在 程序?qū)崿F(xiàn)時，除在接收端根據(jù)源IP地址、目的IP 地址、協(xié)議等字段設(shè)置規(guī)則進行過濾外，還在發(fā) 送端對IP標(biāo)志的最高位進行了置位，只有符合這 些規(guī)則的數(shù)據(jù)包才會被接收。 流式套接字編程對上層應(yīng)用提供了可靠的服務(wù)， 而使用Raw Socket發(fā)送數(shù)據(jù)包則沒有這樣的保證 ，容易造成丟包等情況，程序僅為驗證隱蔽通信 的可行性，沒有考慮對亂序、丟包、數(shù)據(jù)錯誤的 處理。另外，僅給出關(guān)鍵代碼，有關(guān)界面編程的 內(nèi)容不再贅述，可參考附件中的源程序。 2.數(shù)據(jù)結(jié)構(gòu) 協(xié)議 20字節(jié)的IP頭 typedef struct _IPHeader 定義

9、ICMP報頭(回顯請求與回 顯應(yīng)答) typedef struct _ICMPHeader 3.算法實現(xiàn) 算法分為兩個部分實現(xiàn)： 嵌入算法 提取算法 【實驗結(jié)果】【實驗結(jié)果】 下面對上文的內(nèi)容進行實驗驗證，嵌入程序發(fā)送一個名為 “test.txt”的文件， 內(nèi)容為“Network covert communication has been a key technology in the research of network security technologies.”，提取程 序在接收端主機上運行，顯示被隱寫的數(shù)據(jù)包的相關(guān)信息， 實驗結(jié)果如圖所示。 上圖中的Code就是文件test.txt

10、所對應(yīng)字 符的ASCII碼。需要說明的是，上文給出 的提取程序在解析嗅探到的數(shù)據(jù)包時可支 持ICMP、TCP和UDP三種協(xié)議，嵌入程序在 發(fā)送時將識別號和序列號設(shè)置為“1234” 與“5678”，實際上還可以用函數(shù) GetCurrentProcessId()提取當(dāng)前進程ID 賦給識別號，將每個ICMP數(shù)據(jù)包的序列號 依次設(shè)置為一個遞增的整數(shù)。另外，在模 擬Ping的過程中，發(fā)現(xiàn)Windows系統(tǒng)自帶 的Ping程序默認(rèn)發(fā)送的選項數(shù)據(jù)是32字節(jié) 的一段小寫字母，其內(nèi)容為“abcdefgh- ijklmnopqrstuvwabcdefghi”，為了不使 隱寫分析者發(fā)現(xiàn)選項數(shù)據(jù)的異常，可將選 項數(shù)據(jù)

11、填充成和系統(tǒng)一致。 【思考題】【思考題】 1.根據(jù)圖5.1.3,設(shè)計并實現(xiàn)一種基 于IP標(biāo)識字段的協(xié)議隱寫方法。 2.分析IP數(shù)據(jù)包的選項字段（共5種 類型），思考利用IP數(shù)據(jù)包的選項 字段實現(xiàn)協(xié)議隱寫的可行性。 3.查閱IPv6的文檔（RFC2460）或相 關(guān)資料，分析在IPv6上進行協(xié)議隱 寫的可能性。 5.2 基于傳輸層協(xié)議的信息隱藏 【實驗?zāi)康摹俊緦嶒災(zāi)康摹?【實驗環(huán)境】【實驗環(huán)境】 【原理簡介】【原理簡介】 【實驗步驟】【實驗步驟】 【實驗結(jié)果】【實驗結(jié)果】 【思考題】【思考題】 【實驗?zāi)康摹?掌握傳輸層信息隱藏的原理， 理解在傳輸層兩種主要協(xié)議上 進行信息隱藏的基本方法，使 用VC

12、設(shè)計并編程實現(xiàn)一種傳輸 層信息隱藏算法。 【實驗環(huán)境】 (1) 網(wǎng)絡(luò)環(huán)境：100Mbps交換式以太 網(wǎng)，2臺主機，其中包括發(fā)送端 (/24)與接收端 (/24)； (2) 操作系統(tǒng)：Windows2000或 2.4.20以上版本的Linux（如Redhat9 和Fedora系列）； (3) 編程工具：Microsoft Visual C+ 6.0，WinPcap開發(fā)包（版本3.0 以上）。 【原理簡介】 在傳輸層中，TCP和UDP都使用相同的網(wǎng)絡(luò)層，TCP向應(yīng) 用層提供一種面向連接的、可靠的字節(jié)流服務(wù)，而UDP 提供的是無連接的、不可靠的字節(jié)流服務(wù)。

13、在TCP與 UDP上都可以進行信息隱藏，本節(jié)以TCP為例進行說明 ，其首部格式如下圖所示。 TCP序列號是一個32位的字段，用以標(biāo)識從TCP發(fā)送端 向TCP接收端發(fā)送的數(shù)據(jù)字節(jié)流，它保證了傳輸?shù)目?靠性。正常的TCP連接建立分三步，具體原理如下圖 所示。 請求端發(fā)送一個SYN段指明請求端打算連接的服務(wù)器的端口以及ISN； 服務(wù)器發(fā)回包含服務(wù)器ISN的SYN報文段作為應(yīng)答，同時將確認(rèn)號設(shè)置 為請求端的ISN加1以對請求端的SYN報文段進行確認(rèn)； 請求端必須將確認(rèn)號設(shè)置為服務(wù)器的ISN加1對服務(wù)器的SYN報文段進行 確認(rèn)。 利用TCP數(shù)據(jù)包的32位序列號隱藏信息的方法原理如下 圖所示。 該方法只完

14、成了正常三次握手中的第一 步就實現(xiàn)了秘密信息的傳輸。由于事先 已對此種報文做過定義，接收端將不會 發(fā)送ACK信息，因此避免了接收端認(rèn)為 受到了SYN Flood攻擊。發(fā)送端間隔1秒 發(fā)送數(shù)據(jù)包是為了防止在接收端一方發(fā) 生數(shù)據(jù)包亂序的現(xiàn)象。SEQ域的信息可 以經(jīng)過編碼或加密，在實際實現(xiàn)中一般 是將隱匿信息的ASCII碼乘以256。該方 法的可靠性較差，在理想情況下，嵌入 效率為每個數(shù)據(jù)包16比特。 【實驗步驟】【實驗步驟】 1.1.算法描述算法描述 實驗的主要思路與5.1節(jié)相似，為掌握更 多協(xié)議隱寫的實現(xiàn)手段，這里介紹使用 WinPcap進行數(shù)據(jù)嗅探的方法。 2.2.數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)結(jié)構(gòu) 20字節(jié)的

15、TCP頭、定義TCP偽報頭 3.3.算法實現(xiàn)算法實現(xiàn) 算法分為兩個部分實現(xiàn)： 嵌入算法 提取算法 【實驗結(jié)果】 TCP隱寫的嵌入程序 TCP隱寫的提取 程序 提 取的 秘密 信息 由于WinPcap嗅探的數(shù)據(jù)包中包含14字節(jié)的 以太網(wǎng)首部，加上IP、TCP首部的40字節(jié)和 TCP測試數(shù)據(jù)（This is a test rn）的17 字節(jié)，圖中的長度為71。需要說明的是，提 取程序設(shè)置了每20個數(shù)據(jù)包顯示一次消息， 故長度為104字節(jié)的消息只能在對話框中顯 示出80字節(jié)，圖中的最后一個序列號 1953984370就是對話框最后四個字符 “twor”的ASCII碼。除此之外，提取程序 定義了過濾規(guī)

16、則，只有滿足IP分片R標(biāo)記和 TCP的SYN標(biāo)記被置位、IP源地址為 的數(shù)據(jù)包才會被處理。提取程 序還可將對方發(fā)送的信息存儲為 ISN_Data.dat文件，并將每個ISN的數(shù)字按 序號保存在TCP_SYN.txt中，以便進行進一 步分析。 【思考題】【思考題】 1.根據(jù)本節(jié)介紹的TCP隱寫原理，分 析UDP協(xié)議的相關(guān)字段，實現(xiàn)基于UDP 的協(xié)議隱寫。 2.采集windows系統(tǒng)原始的TCP數(shù)據(jù)包 ，對其序列號字段進行統(tǒng)計分析，思 考如何檢測出這種協(xié)議隱寫。 5.3 基于應(yīng)用層協(xié)議的信息隱藏 【實驗?zāi)康摹俊緦嶒災(zāi)康摹?【實驗環(huán)境】【實驗環(huán)境】 【原理簡介】【原理簡介】 【

17、實驗步驟】【實驗步驟】 【實驗結(jié)果】【實驗結(jié)果】 【思考題】【思考題】 【實驗?zāi)康膶嶒災(zāi)康摹?掌握應(yīng)用層信息隱藏的原理， 理解在應(yīng)用層主要協(xié)議上進行 信息隱藏的基本方法，利用VC 設(shè)計并編程實現(xiàn)一種應(yīng)用層信 息隱藏算法。 【實驗環(huán)境實驗環(huán)境】 (1) 網(wǎng)絡(luò)環(huán)境：100Mbps交換式以太 網(wǎng)，2臺主機，其中包括發(fā)送端 (/24)與接收端 (/24)； (2) 操作系統(tǒng)：Windows2000或 2.4.20以上版本的Linux（如 Redhat9和Fedora系列）； (3) 瀏覽器：IE5.0 (4) 編程工具：Microsoft Visual C+

18、 6.0，WinPcap開發(fā)包（版本3.0 以上）。 【原理簡介】【原理簡介】 低層協(xié)議中的協(xié)議隱寫健壯性不強、隱寫效率不 高，實現(xiàn)過程復(fù)雜、容易被檢測器檢測，難以穿 越NAT和代理型防火墻，并且由于使用預(yù)留、填 充、可選字段，容易受主動攻擊破壞。近年來， 協(xié)議隱寫有向上層協(xié)議發(fā)展的趨勢。由于防火墻 和路由器一般不檢查應(yīng)用層協(xié)議，這使得應(yīng)用層 協(xié)議隱寫更容易實施。TCP/IP協(xié)議族中的應(yīng)用層 協(xié)議十分豐富，包括SMTP、FTP、SSH、LDAP（分 布式路徑協(xié)議）等，每個應(yīng)用層協(xié)議都具有復(fù)雜 的通信和控制機制，十分適合隱藏信息。 HTTP協(xié)議產(chǎn)生的流量僅次于P2P位列第二，是互 聯(lián)網(wǎng)中應(yīng)用最廣

19、泛的應(yīng)用層協(xié)議之一。同時，該 協(xié)議具有復(fù)雜的報頭，是穿透防火墻等網(wǎng)絡(luò)訪問 控制系統(tǒng)的理想?yún)f(xié)議，本節(jié)主要介紹如何使用 HTTP協(xié)議來隱藏信息。 HTTPHTTP概述概述 HTTP（超文本傳輸協(xié)議）建立在請求/響應(yīng)（ Request/Response）模型上，首先由客戶建立 一條與服務(wù)器的TCP鏈接，并發(fā)送一個請求到服 務(wù)器，請求中包含請求方法、URL、協(xié)議版本以 及相關(guān)的MIME（Multipurpose Internet Mail Extensions）樣式消息。服務(wù)器返回響應(yīng)報文 ，包含消息的協(xié)議版本、一個成功或失敗碼以 及相關(guān)的MIME式樣消息（包含服務(wù)器的信息、 資源實體的信息和可能的資

20、源內(nèi)容）。 HTTP是一個無狀態(tài)的協(xié)議，使用TCP作為底層運 輸協(xié)議。HTTP客戶機發(fā)起一個與服務(wù)器的TCP連 接，一旦連接建立，瀏覽器和服務(wù)器進程就可 以通過套接字進行面向連接的交互通信。HTTP 的報文有兩種，請求報文和響應(yīng)報文。 HTTP請求報文的一般格式如下圖所示： 圖中SP表示空格（Space），CRLF表示回車換行 （Carriage Return and Line Feed）。HTTP請求報文 每行用一個回車換行符結(jié)束，最后一行后跟有附加的回 車換行符。第一行叫做請求行，后繼的行叫做首部行。 請求行有三個字段：方法字段、URL字段和HTTP 協(xié)議版本字段。方法字段可以取值GET、

21、POST、 HEAD、OPTION、PUT、DELETE、TRACE、CONNECT ，最常用的是前面三種，其含義如下： GET請求，返回Request-URI所指定的任意信息。 HEAD請求，類似于GET請求，但服務(wù)器程序只返回指 定文檔的首部信息，而不包含實際的文檔內(nèi)容。該請 求通常被用來測試超文本鏈接的正確性、可訪問性和 最近的修改。 POST請求用來發(fā)送電子郵件、新聞或發(fā)送能由交互用 戶填寫的表格。這是唯一需要在請求中發(fā)送實體主體 （Body）的請求。使用POST請求時需要在報文首部 Content-Length字段中指出Body的長度。 HTTP協(xié)議仍在不斷發(fā)展，現(xiàn)在的較新版本是 1

22、999年在RFC2616中公布的HTTP/1.1，它已經(jīng)成 為互聯(lián)網(wǎng)草案標(biāo)準(zhǔn)。有關(guān)HTTP的其它技術(shù)細(xì)節(jié) 可參閱有關(guān)文獻(xiàn)，在此不再贅述。 協(xié)議機制分析協(xié)議機制分析 HTTP是一種應(yīng)用層協(xié)議，由于面向用戶，協(xié)議的制定者基于友 好性的考慮，為HTTP設(shè)計了自容錯、強糾錯的特性。協(xié)議由兩 部分程序?qū)崿F(xiàn)：一個客戶機程序和一個服務(wù)器程序，它們運行 在不同的端系統(tǒng)中，通過交換HTTP報文進行會話。同時，HTTP 是建立在TCP基礎(chǔ)上的請求響應(yīng)模式的協(xié)議，該模式的基本工作 原理如圖示。 上圖中的第一步和最后一步是TCP連接的建立和釋放，與 一般的TCP應(yīng)用沒有區(qū)別，在關(guān)鍵的中間兩步，客戶機與 服務(wù)器實現(xiàn)了H

23、TTP報文的交互。這個交互過程不是嚴(yán)格 正確的理想過程，經(jīng)常出現(xiàn)由于種種原因產(chǎn)生畸形報文的 情況。 HTTPHTTP報文構(gòu)造試驗報文構(gòu)造試驗 HTTP請求包括三種方法，下面以GET方法為例， 通過報文構(gòu)造試驗研究HTTP中的協(xié)議隱寫。實 驗的主要思路是利用自編的CovertHTTP_Sender 來構(gòu)造自定義HTTP請求報文，反復(fù)模擬IE向Web 服務(wù)器發(fā)送GET請求，同時捕獲服務(wù)器對每一個 請求的HTTP響應(yīng)報文，并判斷其是否正常，以 此來發(fā)現(xiàn)HTTP中的語義冗余。 獲得獲得IEIE的標(biāo)準(zhǔn)的標(biāo)準(zhǔn)GETGET請求請求 首先需要得到普通瀏覽器軟件產(chǎn)生的標(biāo)準(zhǔn)HTTP 請求報文，下面考察Micros

24、oft Windows 2000 SP4下Internet Explorer 5.0的GET請求頭數(shù)據(jù) ，下文所有的協(xié)議隱寫將全部以此為例。 通過IE訪問IP地址為7的Web服務(wù)器 ，該服務(wù)器安裝的信息服務(wù)軟件為Microsoft- IIS/5.1，同時運行自編嗅探器IPMonitor，得 到的結(jié)果如下頁圖所示。 第一行是HTTP請求報文的請求行，指明了該請求采用的是GET方法，后續(xù)的行是 首部行，分別指明了客戶端瀏覽器接受的媒體類型、語言、編碼方式和瀏覽器版 本、遠(yuǎn)端主機、連接選項。上述每個字段都有明確的用途，似乎不存在冗余。 下面是截獲到TCP三次握手成功后HTTP請

25、求報文中數(shù)據(jù)段的內(nèi)容： IE5.0的GET請求 報文 向服務(wù)器發(fā)送自定義向服務(wù)器發(fā)送自定義HTTPHTTP請求請求 在得到標(biāo)準(zhǔn)GET請求的數(shù)據(jù)內(nèi)容后，開始以此內(nèi)容為基礎(chǔ)模 擬IE向Web服務(wù)器發(fā)送請求報文，報文構(gòu)造試驗的原理如圖 所示。 在報文發(fā)送過程中，由于請求報文可能非法， Web服務(wù)器會產(chǎn)生各種響應(yīng)報文，當(dāng)返回的報文 頭為“HTTP/1.1 200 OK”時，說明此報文可從 服務(wù)器正常返回網(wǎng)頁，故該次試驗所產(chǎn)生的報 文在功能上可以等同于IE的標(biāo)準(zhǔn)請求報文。 利用自編CovertHTTP_Sender產(chǎn)生與IE的標(biāo)準(zhǔn)請求一樣的HTTP 報文，然后將報文中數(shù)據(jù)段的首部行不斷減少，發(fā)現(xiàn)服務(wù)器的

26、 響應(yīng)報文全部正常。經(jīng)過數(shù)次試驗，發(fā)現(xiàn)上述數(shù)據(jù)報文可簡化 到請求行，在只?！癎ET / HTTP/1.1”的情況下仍可從服務(wù)器 正常返回網(wǎng)頁，實驗效果如圖所示。 在得出首部行全部為冗余行的同時，經(jīng)過進一步實 驗，發(fā)現(xiàn)包括上述首部行在內(nèi)的所有首部行（不同 操作系統(tǒng)下Opera、Firefox、Netscape等瀏覽器的 多個版本會產(chǎn)生不同的首部行）中，存在如標(biāo)識符 號不敏感、大小寫無關(guān)等諸多冗余，這為協(xié)議隱寫 創(chuàng)造了條件。 【實驗步驟實驗步驟】 1.1.算法描述算法描述 2.2.算法實現(xiàn)算法實現(xiàn) 1.算法描述 在HTTP協(xié)議中，可通過空白隱寫術(shù)、大小寫混排 編碼、非默認(rèn)首部字段值、微調(diào)URI特殊

27、符號、 自定義消息報頭域、二進制對象排序隱藏等幾種 方法實現(xiàn)協(xié)議隱寫，算法實現(xiàn)時僅介紹利用自定 義消息報頭域進行信息隱藏的方法。 空白隱寫術(shù)空白隱寫術(shù) 所謂空白隱寫術(shù)就是在文本文件一行的末尾附上 Space和Tab等不可顯示字符，由于Space和Tab出 現(xiàn)在行尾時是不可見的，這就使得信息可以隱藏 在文本文件中，并且不會影響整個文本的顯示。 HTTP報頭中，首部字段名后都可以隨意嵌入 Space和Tab，無論是首部字段值之中還是行尾， 都不會影響報文的功能。 下面以示例請求報文為例說明隱寫過程，為方便顯 示，以SP表示Space，HT表示Tab（Horizontal Tab），CRLF表示回車

28、換行。 上例中的請求行“GET / HTTP/1.1”未隱 藏信息，將SP編為“0”、HT編為 “1”，則該請求報文隱匿傳送了 “HELLO!”。 大小寫混排編碼大小寫混排編碼 HTTP報文由普通ASCII文本書寫，因此它只能表示英文字母、數(shù) 字和簡單標(biāo)點符號，請求報文的請求行嚴(yán)格區(qū)分英文字母的大 小寫，但首部行對大小寫的變化卻不敏感。這種大小寫無關(guān)意 味著HTTP報文提供了近12.5%的空間隱藏秘密信息。例如： 將小寫字母編為“0”、大寫字母編為“1”，則該請求報文隱匿傳送了 “EVE BETRAY US”。但是，若此報文被網(wǎng)絡(luò)上的隱寫分析者捕獲到， 很容易引起懷疑，因為沒有哪個程序員會有這

29、樣怪異的書寫習(xí)慣。改進 方法是將原始報文全部置為小寫，然后改動報文英文單詞的首字母大小 寫方式，首字母小寫編為“0”、首字母大寫編為“1”。例如： 上述HTTP報文隱藏了16比特的信息“0 xDC53”，而這樣的編碼方式不至 于引人注目，但代價是大大減小了隱寫效率。 非默認(rèn)首部字段值非默認(rèn)首部字段值 上文提到的HTTP請求報文僅用一句“GET / HTTP/1.1”就可替代 ，原因在于特定瀏覽器發(fā)送請求報文的報頭域參數(shù)都有默認(rèn)值， 如果報文中沒有此報頭域，服務(wù)器端就會認(rèn)為瀏覽器使用相應(yīng)的 默認(rèn)選項。比如Windows 2000下IE 5.0的GET請求頭數(shù)據(jù)中， Accept的默認(rèn)值是“*/*

30、”，而實際上該值還可以為“image/ gif, text/html, application/vnd.ms-excel”等。例如： 因此，如將使用默認(rèn)值編為“0”、使用其它值編 為“1”，則該請求報文隱匿傳送了比特串“110001”， 該方法具有強健壯性，不容易遭受蓄意攻擊，但隱 寫效率較差。 微調(diào)微調(diào)URIURI特殊符號特殊符號 URI即統(tǒng)一資源標(biāo)識符（Uniform Resource Identifiers），它用于唯一地標(biāo)識元素或 屬性的數(shù)字或名稱，常用的URL就是一種特 殊的URI。HTTP程序在實現(xiàn)時屏蔽了用戶之 間可能存在的差異，包括用戶的錯誤輸入、 簡化輸入等。最明顯的例子在“

31、/”、默認(rèn) 端口和單雙引號上，比如“http:/ :/”、“ http:/ :80”在HTTP中代表同樣的含義 。而在查詢資源Cookie時報頭域要用到的 If-None-Match默認(rèn)使用雙引號來標(biāo)識資源 哈希值，如： If-None-Match: 0c41a86ad11c11:1aec HTTP報頭中還有幾種標(biāo)點符號括號、冒號、逗號、分號和 等于號，它們本身不具有冗余性，但它們對周圍的空格變化不 敏感。前四種在每一個首部行都中有使用，等于號在短時間內(nèi) 再次發(fā)送同樣資源請求的HTTP報頭中存在。舉例如下： 標(biāo)點符號左右以不出現(xiàn)空格編為“0”，出現(xiàn)空 格編為“1”，每個符號可攜帶2比特信息，上

32、 例隱匿傳送了比特串“100101100111100101” ，該方法具有很強隱蔽性，報文即使被攻擊者 截獲也很難發(fā)現(xiàn)存在隱蔽通信。 自定義消息報頭域自定義消息報頭域 HTTP報文首部行常用字段接近20種，請求報文常用字段共9種。HTTP 程序的多樣化，使新版本客戶端發(fā)送的HTTP報頭經(jīng)常出現(xiàn)服務(wù)器端無 法識別的情況（如HTTP/1.1的請求報文發(fā)送到了只支持HTTP/1.0的服 務(wù)器上），此時服務(wù)器會忽略這樣的字段，只提供可識別字段所對應(yīng) 的服務(wù)，HTTP代理也會原樣轉(zhuǎn)發(fā)這樣的字段。因此，可以通過自定義 消息報頭域來隱藏秘密信息，例如： 該方法與上文的區(qū)別是采用了直接嵌入的形式，使得隱藏信息的 容量可以隨意擴充，隱寫效率也很高，但由于秘密信息以明文存 在，透明性不強，可以采用加密算法（如DES、AES）對秘密信息 加密傳輸。需要注意的是，經(jīng)過加密后，輸入信息的比特流成隨 機分布，很可能出現(xiàn)一個字節(jié)的第一比特為1的情況，而標(biāo)準(zhǔn) ASCII的最高位恒為0。這樣，HTTP在傳輸過程中可能會將每字節(jié) 的最高位置零，在到達(dá)接收端后，解密得不到原始秘密信息。解 決該問題可采用BASE64編碼，將3個8比特的信息編碼成4個6比特 的信息，便不會在傳輸時受到干擾。 二進制對象