10 安全注意事項(xiàng)

安全注意事項(xiàng)

本章描述了一些適用于WebSocket協(xié)議的安全注意事項(xiàng)。具體的安全注意事項(xiàng)在本章的字章節(jié)描述。

10.1.非瀏覽器客戶端

WebSocket協(xié)議防止惡意的JavaScript運(yùn)行在一個(gè)受信任的應(yīng)用內(nèi)部，比如web瀏覽器，例如，通過(guò)檢查頭字段|Origin|（見(jiàn)下文）。更多細(xì)節(jié)請(qǐng)參考1.6節(jié)。在一個(gè)更強(qiáng)大的客戶端的情況下，這樣的假設(shè)不成立。

雖然該協(xié)議的目的是被web頁(yè)面中的腳本使用，它也可以被主機(jī)直接使用。這樣的主機(jī)按照它們自己的行為行事，因此可以發(fā)送偽造的|Origin|頭字段，騙過(guò)服務(wù)器。因此服務(wù)器應(yīng)該小心，假設(shè)它們是直接與來(lái)自已知源的腳本通信，且必須考慮到它們可能以非預(yù)期方式訪問(wèn)。尤其，服務(wù)器不應(yīng)該相信任何輸入是有效的。

例如：如果服務(wù)器使用輸入作為SQL查詢的一部分，所有輸入文本在傳輸?shù)絊QL服務(wù)器之前應(yīng)該被轉(zhuǎn)義，以免服務(wù)器受到SQL注入攻擊。

10.2. Origin注意事項(xiàng)

服務(wù)器不打算處理來(lái)自任意web頁(yè)面的輸入，但僅限于網(wǎng)站應(yīng)該驗(yàn)證|Origin|頭是一個(gè)它們盼望的源。如果源指示是服務(wù)器不可接受的，那么它應(yīng)該以一個(gè)包含HTTP 403 Forbidden的狀態(tài)碼的回復(fù)響應(yīng)WebSocket握手。

當(dāng)不受信任方通常是一個(gè)執(zhí)行在受信任的客戶端上下文中的JavaScript應(yīng)用的作者時(shí)，|Origin|頭字段可以保護(hù)攻擊的情況?？蛻舳吮旧砜梢耘c服務(wù)器聯(lián)系，并通過(guò)| Origin|頭字段機(jī)制，決定是否提供JavaScript應(yīng)用的這些通信權(quán)限。目的不是為了阻止非瀏覽器建立連接，而是確保受信的瀏覽器在潛在的惡意JavaScript控制下不能偽造WebSocket握手。

10.3.攻擊基礎(chǔ)設(shè)施（掩碼）

除了端點(diǎn)是WebSocket攻擊的目標(biāo)之外，web基礎(chǔ)設(shè)施的其他部分，如代理，也可能是攻擊的對(duì)象。在本協(xié)議正在開(kāi)發(fā)時(shí)，進(jìn)行了一個(gè)實(shí)驗(yàn)旨在演示一類代理上的攻擊，其導(dǎo)致部署在野的緩存代理中毒[討論]。一般的攻擊形式是在“攻擊者”的控制下建立一個(gè)到服務(wù)器的連接，執(zhí)行類似于WebSocket協(xié)議建立連接的HTTP連接上的UPGRADE，且隨后在已經(jīng)UPGRADE的連接上發(fā)送數(shù)據(jù)，看起來(lái)像一個(gè)GET請(qǐng)求一個(gè)特定的已知資源（在一次攻擊中，很可能會(huì)像廣泛部署的用于跟蹤點(diǎn)擊或一個(gè)廣告服務(wù)網(wǎng)絡(luò)資源的腳本）。遠(yuǎn)程服務(wù)器響應(yīng)的東西看起來(lái)像是到偽造的GET請(qǐng)求的一個(gè)響應(yīng)，且這個(gè)響應(yīng)將被一個(gè)非零百分比的部署的中間件緩存，因此使緩存中毒了。這種攻擊的靜效應(yīng)將是如果能說(shuō)服用戶去訪問(wèn)攻擊者控制的網(wǎng)站，攻擊者可能使用戶和其他晚于相同緩存的用戶的緩存中毒且在其他源運(yùn)行惡意腳本，影響網(wǎng)絡(luò)安全模型。

為避免這種部署的中間件上的攻擊，前置不兼容HTTP的和幀一起的應(yīng)用提供的數(shù)據(jù)是不夠的，因?yàn)闊o(wú)法詳盡地發(fā)現(xiàn)和測(cè)試每一個(gè)不符合中間件的不跳過(guò)這樣的非HTTP幀和錯(cuò)誤地假裝幀負(fù)載。

因此，采用的防御是掩碼所有從客戶端到服務(wù)器端發(fā)送的數(shù)據(jù)，使遠(yuǎn)程腳本（攻擊者）無(wú)法控制數(shù)據(jù)如何在電線上發(fā)送，從而無(wú)法構(gòu)造一個(gè)可能被中間件誤解釋的作為一個(gè)HTTP請(qǐng)求的消息。

客戶端必須為每一幀選擇一個(gè)新的掩碼密鑰，使用一個(gè)不能被提供數(shù)據(jù)的終端應(yīng)用預(yù)測(cè)。例如，每次掩碼可以從一個(gè)強(qiáng)加密的隨機(jī)數(shù)生成器獲取。如果使用相同的密鑰或存在一個(gè)可預(yù)測(cè)的模式用于選擇下一個(gè)密鑰，當(dāng)掩碼后，攻擊者可以發(fā)送一個(gè)消息，可能作為一個(gè)HTTP請(qǐng)求出現(xiàn)（通過(guò)交換消息，攻擊者希望觀察線上并用下一個(gè)將被使用的掩碼密鑰掩碼它，當(dāng)客戶端應(yīng)用它時(shí)掩碼密鑰將有效的解碼數(shù)據(jù)）。 一旦從客戶端傳輸一個(gè)幀已經(jīng)開(kāi)始，幀的負(fù)載（應(yīng)用提供的數(shù)據(jù)）必須不能被應(yīng)用修改也是必要的。

否則，攻擊者可能發(fā)送一個(gè)已知初始數(shù)據(jù)（如都是0）的長(zhǎng)幀，一收到數(shù)據(jù)的第一部分后就開(kāi)始計(jì)算使用的掩碼密鑰，當(dāng)掩碼后，接著修改尚未發(fā)送的作為一個(gè)請(qǐng)求出現(xiàn)的幀中的數(shù)據(jù)（這本質(zhì)上是和前面段落描述的使用一個(gè)已知的或可預(yù)測(cè)的掩碼密鑰是相同的問(wèn)題）。 如果需要發(fā)送額外的數(shù)據(jù)或要發(fā)送的數(shù)據(jù)以某種方式修改了，新的或修改了的數(shù)據(jù)必須在一個(gè)新的幀中發(fā)送，那么需要一個(gè)新的掩碼密鑰。總之，一旦開(kāi)始傳輸一個(gè)幀，對(duì)于遠(yuǎn)程腳本（應(yīng)用）來(lái)說(shuō)，內(nèi)容必須不能是可修改的。

威脅模型用來(lái)保護(hù)客戶端發(fā)送的在一個(gè)請(qǐng)求出現(xiàn)的數(shù)據(jù)。因此，需要掩碼的信道是從客戶端到服務(wù)器的數(shù)據(jù)。服務(wù)器到客戶端的數(shù)據(jù)可以作出看起來(lái)像一個(gè)響應(yīng)，但為了完成這個(gè)請(qǐng)求，客戶端也必須有能力去偽造一個(gè)請(qǐng)求。因此，沒(méi)必要在兩個(gè)方向上掩碼數(shù)據(jù)（從客戶端到服務(wù)器的數(shù)據(jù)沒(méi)有掩碼）。

盡管掩碼提供了保護(hù)，對(duì)于客戶端和服務(wù)器沒(méi)有掩碼的這種類型的中毒攻擊，非兼容HTTP代理將依然是脆弱的。

10.4.實(shí)現(xiàn)特定限制

實(shí)現(xiàn)已經(jīng)實(shí)現(xiàn)— 和/或特定平臺(tái)的有關(guān)幀大小或總消息大小的限制，從多個(gè)幀重新組裝后，必須保證它們自己不超過(guò)這些限制。（例如，一個(gè)惡意終端無(wú)論是通過(guò)單一的大幀（例如，2**60大?。┻€是通過(guò)發(fā)送一個(gè)長(zhǎng)流的分片消息的一部分的小幀，可以設(shè)法耗盡它的對(duì)等體端點(diǎn)（Peer，即要攻擊的那一方）的內(nèi)存或安裝一個(gè)拒絕服務(wù)攻擊）。這樣的實(shí)現(xiàn)應(yīng)該對(duì)幀大小和和從多個(gè)幀重組后的總消息大小加以限制。

10.5.WebSocket客戶端驗(yàn)證

本規(guī)范沒(méi)有規(guī)定任何特定的方式在WebSocket握手期間服務(wù)器可以驗(yàn)證客戶端。WebSocket服務(wù)器可以使用任何客戶端對(duì)普通HTTP服務(wù)器可用的驗(yàn)證機(jī)制，如Cookie，HTTP驗(yàn)證，或者TLS驗(yàn)證。

10.6.連接的保密性和完整性

連接的保密性和完整性是通過(guò)運(yùn)行在TLS（wss URI）上WebSocket協(xié)議提供的。WebSocket實(shí)現(xiàn)必須支持TLS并應(yīng)該在與它們的對(duì)等端點(diǎn)通信時(shí)使用它。

對(duì)于使用TLS的連接，TLS提供的受益量在很大程度上取決于在TLS握手期間協(xié)商的算法強(qiáng)度。例如，一些TLS加密機(jī)制不提供連接的保密性。為了實(shí)現(xiàn)合理級(jí)別的保護(hù)，客戶端應(yīng)該僅適用強(qiáng)TLS算法?！癢eb安全上下文：用戶接口指南”[W3C.REC-wsc-ui-20100812]討論了什么構(gòu)成強(qiáng)TLS算法。[RFC5246]的附錄A.5和附錄D.3中提供了額外的指導(dǎo)。

10.7.處理無(wú)效數(shù)據(jù)

傳入的數(shù)據(jù)必須始終由客戶端和服務(wù)器驗(yàn)證。如果，在任何時(shí)候，一個(gè)端點(diǎn)不理解它的數(shù)據(jù)或違反了一些端點(diǎn)確定的安全輸入標(biāo)準(zhǔn)，或當(dāng)端點(diǎn)看到一個(gè)打開(kāi)階段握手沒(méi)有符合它盼望的值（例如，在客戶端請(qǐng)求中不正確的路徑或源），端點(diǎn)可以終止TCP連接。如果在WebSocket握手成功后接收到了無(wú)效數(shù)據(jù)，端點(diǎn)應(yīng)該在進(jìn)行關(guān)閉WebSocket連接之前發(fā)送一個(gè)帶有適當(dāng)狀態(tài)碼（7.4節(jié)）的關(guān)閉幀。使用一個(gè)帶有適當(dāng)狀態(tài)碼的關(guān)閉幀能幫助診斷問(wèn)題。如果在WebSocket握手期間發(fā)送了無(wú)效的數(shù)據(jù)，服務(wù)器應(yīng)該返回一個(gè)適當(dāng)?shù)腍TTP[RFC2616]狀態(tài)碼。使用錯(cuò)誤的編碼發(fā)送文本數(shù)據(jù)是通常出現(xiàn)的一類安全問(wèn)題。本協(xié)議規(guī)定一個(gè)Text數(shù)據(jù)類型（而不是Binary或其他類型）的消息包含UTF-8編碼的數(shù)據(jù)。雖然仍指定了長(zhǎng)度，且實(shí)現(xiàn)本協(xié)議的應(yīng)用應(yīng)該使用長(zhǎng)度來(lái)決定幀從哪真正結(jié)束，但以一個(gè)不當(dāng)?shù)木幋a發(fā)送數(shù)據(jù)仍可能打破建立在本協(xié)議之上的應(yīng)用的假設(shè)，導(dǎo)致從誤解釋數(shù)據(jù)到丟失數(shù)據(jù)或潛在的安全漏洞。

10.8.使用SHA-1的WebSocket握手

本文檔中描述的WebSocket握手不依賴于任何SHA-1安全特性，例如抗碰撞性或抗第二前像攻擊（如同[RFC4270]中的描述）。