0 引言

傳統(tǒng)的瀏覽器只允許HTTP接收或者發(fā)送消息，大量消耗了服務(wù)器帶寬和資源，且無法滿足實(shí)時(shí)性強(qiáng)的Web應(yīng)用?；诖耍琀TML5中WebSocket協(xié)議通過建立一個(gè)持續(xù)的、全雙工的信道，來傳輸不帶元數(shù)據(jù)的信息，可以滿足某些Web應(yīng)用的實(shí)時(shí)要求。但WebSocket技術(shù)的發(fā)展的前提是必須有力的保障其安全性。

1 WebSocket協(xié)議

服務(wù)器推送的實(shí)現(xiàn)方式主要基于Ajax輪詢方式、基于Ajax的長(zhǎng)輪詢方式、基于iframe的流方式。然而這些方式都存在浪費(fèi)資源、占用帶寬等問題。Websocket協(xié)議是HTML5實(shí)現(xiàn)的瀏覽器與服務(wù)器雙向通信的新協(xié)議之一，能更好地節(jié)省服務(wù)器資源和帶寬，并達(dá)到實(shí)時(shí)通信。瀏覽器和服務(wù)器只需一個(gè)“握手”動(dòng)作就能建立一條快速通道，進(jìn)行數(shù)據(jù)的相互傳送。

握手動(dòng)作的請(qǐng)求端主要代碼：

握手動(dòng)作接收端主要代碼：

當(dāng)WebSocket連接建立之后，客戶端和服務(wù)器端通過“幀”來相互發(fā)送消息。下圖表示數(shù)據(jù)傳輸?shù)腤ebSocket幀格式：

其中參數(shù)具體意義如下表：

位名稱 所占位數(shù) 具體意義FIN 1 表示此幀是不是消息的最后幀RSV1，RSV2，RSV3 1 自定義協(xié)議位，必須是0 Opcode 4 定義載荷數(shù)據(jù)類型MASK 1 是否有掩碼位，值為1 Payload length如果值為0-125，則是有效載荷長(zhǎng)度；如果值為126，接下來2字節(jié)的16位無符號(hào)整數(shù)為有效載荷長(zhǎng)度；如果值為127，接下來8字節(jié)的64位無符號(hào)整數(shù)為有效載荷長(zhǎng)度Masking-key 0或4 掩碼位7或者7+16或者7+64

2 WebSocket安全特性研究

WebSocket可能會(huì)遇到很多攻擊，比如說不法分子試圖復(fù)制、刪除和修改用戶數(shù)據(jù)，在Web通信過程中，惡意竊取或攔截信息等。而WebSocket的安全特性可以緩解某些特性的攻擊。

2.1 Origin特性

在客戶端發(fā)起的WebSocket握手中，一般會(huì)有Origin字段，它主要用來標(biāo)識(shí)這個(gè)請(qǐng)求最初發(fā)起在哪里。如果瀏覽器不能確定源的位置，那么初始握手中Origin字段的值為空。Origin字段允許接收方拒絕不想處理或惡意的連接，并發(fā)送一個(gè)適當(dāng)?shù)腍TTP錯(cuò)誤碼。用于保護(hù)WebSocket服務(wù)器不被未授權(quán)的腳本跨源使用WebSocket API，比如說源可以有效的緩解拒絕服務(wù)（DoS）攻擊。

2.2 WebSocket握手安全

在服務(wù)器發(fā)起的握手連接初始化期間，WebSocket服務(wù)器用Sec-WebSocket-Key，Sec-WebSocket-Accept兩個(gè)頭字段生成應(yīng)答信息，消除跨協(xié)議攻擊的可能性。WebSocket協(xié)議中包含了一個(gè)用于識(shí)別協(xié)議的全局唯一標(biāo)識(shí)符（Globally Unique Identifier，GUID），是258EAFA5-E914-47DA-95CA-C5AB0DC85B11。服務(wù)器首先讀取Sec-WebSocket-Key首標(biāo)值，基于以下的算法生成正確的應(yīng)答信息：

（1）服務(wù)器添加GUID值拼接字符串；

（2）服務(wù)器用SHA1散列轉(zhuǎn)換結(jié)果；

（3）服務(wù)器用Base64編碼轉(zhuǎn)換結(jié)果；

（4）服務(wù)器將結(jié)果做為Sec-WebSocket-Accept首標(biāo)的值返回。

基于以上算法，服務(wù)器端將生成的安全密鑰作為應(yīng)答信息發(fā)回給客戶端，由此建立雙方的WebSocket連接通道，進(jìn)行數(shù)據(jù)傳輸。

2.3 代理服務(wù)器和mask

除了客戶端和服務(wù)器端是WebSocket的攻擊對(duì)象之外，Web基礎(chǔ)設(shè)施的其他部分也可能是攻擊的對(duì)象，比如說代理服務(wù)器。代理服務(wù)器是介于客戶端和Web服務(wù)器之間的服務(wù)器?！肮粽摺比绻⒁粋€(gè)到WebSocket服務(wù)器的連接，模擬客戶端發(fā)送HTTP的UPGRADE請(qǐng)求，然后再發(fā)送數(shù)據(jù)，服務(wù)器端返回一個(gè)響應(yīng)信息，若有代理服務(wù)器，響應(yīng)信息會(huì)首先存放在緩存中，以致緩存中毒?；诖祟惞簦琖ebSocket協(xié)議添加屏蔽及掩碼位，客戶端發(fā)送的每一幀都有新的掩碼，以保護(hù)數(shù)據(jù)在傳輸中的安全性。

WebSocket幀的第二個(gè)字節(jié)的第一位表示該幀是否進(jìn)行了屏蔽，WebSocket協(xié)議默認(rèn)所有幀都要進(jìn)行屏蔽再發(fā)送。如上節(jié)所示，掩碼位在擴(kuò)展載荷數(shù)據(jù)的后四位字節(jié)。WebSocket服務(wù)器在處理接收到的載荷數(shù)據(jù)之前都要先用掩碼對(duì)屏蔽進(jìn)行解除?？捎靡韵潞瘮?shù)解除屏蔽：

var unmask function（mask_bytes.buffer）{var payload = new Buffer（buffer.length）；for（var i=0；i

解除屏蔽之后，服務(wù)器可以得到原始的幀數(shù)據(jù)：二進(jìn)制消息可以直接交付；文本消息將進(jìn)行UTF-8解碼，并通過服務(wù)器API輸出字符串。

2.4 連接的保密性和完整性

通信安全的中心內(nèi)容就是保證信息在信道內(nèi)的保密性、消息完整性和可認(rèn)證性。SSL/TLS用于在客戶端和服務(wù)器端之間建立安全通道，以保護(hù)在不安全的公眾網(wǎng)絡(luò)上交換的數(shù)據(jù)。與WebSo-cket從一個(gè)HTTP握手開始升級(jí)到WebSocket協(xié)議一樣，WebSo-cket安全握手從HTTPS握手開始。HTTPS和WSS協(xié)議非常類似，都是通過TCP連接的TLS基礎(chǔ)上運(yùn)行的。與HTTP相同，WebSock et也通過使用證書來配置TLS加密。對(duì)于HTTPS，客戶端和服務(wù)器端在使用HTTP協(xié)議之前要先建立一個(gè)安全連接。類似的，對(duì)于WSS，客戶端和服務(wù)器端首先建立一個(gè)安全連接，然后進(jìn)行HT TP握手，最后升級(jí)WebSocket協(xié)議。

3 結(jié)語

實(shí)時(shí)通信技術(shù)是Web通信的重要應(yīng)用領(lǐng)域，正是WebSocket等相關(guān)技術(shù)的發(fā)展與應(yīng)用，使得Web瀏覽器的實(shí)時(shí)通信水平有了長(zhǎng)足的發(fā)展進(jìn)步。同時(shí)，安全性對(duì)于WebSocket能夠廣泛推廣有舉足輕重的地位。本文介紹了WebSocket協(xié)議的新規(guī)范，并詳細(xì)闡述了通信中可能遇到的安全威脅及其相關(guān)的安全特征。