【51CTO活动】8.26 带你深度了解清华大学、搜狗基于算法的IT运维实际与探求

WebSocket是HTML5末尾提供的一种阅读器与效劳器间停止全双工通讯的网络技术。WebSocket通讯协议于2011年被IETF定为标准RFC 6455，WebSocket API也被W3C定为标准，主流的阅读器都曾经支持WebSocket通讯。

WebSocket协议是基于TCP协议上的独立的通讯协议，在树立WebSocket通讯衔接前，需求运用HTTP协议停止握手，从HTTP衔接晋级为WebSocket衔接。阅读器和效劳器只需求完成一次握手，两者之间就直接可以创立耐久性的衔接，并停止双向数据传输。

WebSocket定义了两种URI格式, “ws://“和“wss://”，相似于HTTP和HTTPS, “ws://“运用明文传输，默许端口为80，”wss://“运用TLS加密传输，默许端口为443。

ws-URI: "ws://host[:port]path[?query]"  

wss-URI: "wss://host[:port]path[?query]" 

WebSocket 握手阶段，需求用到一些HTTP头，晋级HTTP衔接为WebSocket衔接如下表所示。

一次残缺的握手衔接如下图:

一旦效劳器端前往 101 照应，即可完成 WebSocket 协议切换。效劳器端可以基于相反端口，将通讯协议从 或 https:// 切换到 ws://或 wss://。协议切换完成后，阅读器和效劳器端可以运用 WebSocket API 相互发送和收取文本和二进制音讯。

WebSocket运用安全成绩

WebSocket作为一种通讯协议引入到Web运用中，并不会处置Web运用中存在的安全成绩，因此WebSocket运用的安全完成是由开发者或效劳端担任。这就要求开发者了解WebSocket运用潜在的安全风险，以及如何做到安全开发规避这些安全成绩。

认证

WebSocket 协议没有规则效劳器在握手阶段应该如何认证客户端身份。效劳器可以采用任何 HTTP 效劳器的客户端身份认证机制，如 cookie认证，HTTP 基础认证，TLS 身份认证等。在WebSocket运用认证明现下面临的安全成绩和传统的Web运用认证是相反的，如： CVE-2015-0201 , Spring框架的Java SockJS客户端生成可预测的会话ID，攻击者可应用该破绽向其他会话发送音讯; CVE-2015-1482 , Ansible Tower未对用户身份停止认证，远程攻击者经过websocket衔接获取敏感信息。

授权

同认证一样，WebSocket协议没有指定任何授权方式，运用顺序中用户资源拜访等的授权策略由效劳端或开发者完成。WebSocket运用也会存在和传统Web运用相反的安全风险，如：垂直权限提升和水平权限提升。

跨域央求

WebSocket运用基于源的安全模型，在发起WebSocket握手央求时，阅读器会在央求中添加一个名为Origin的HTTP头，Oringin字段表示发起央求的源，以此来避免未经授权的跨站点拜访央求。WebSocket 的客户端不只仅局限于阅读器，因此 WebSocket 标准没有强迫规则握手阶段的 Origin 头是必需的，并且WebSocket不受阅读器同源策略的限制。假设效劳端没有针对Origin头部停止验证能够会招致跨站点WebSocket劫持攻击。该破绽最早在 2013 年被Christian Schneider 发现并地下，Christian 将之命名为跨站点 WebSocket 劫持 (Cross Site WebSocket Hijacking)(CSWSH)。跨站点 WebSocket 劫持危害大，但容易被开发人员无视。相关案例可以参考: IPython Notebook( CVE-2014-3429 ), OpenStack Compute( CVE-2015-0259 ), Zeppelin WebSocket效劳器 等跨站WebSocket劫持。

上图展现了跨站WebSocket劫持的进程，某个用户曾经登录了WebSocket运用顺序，假设他被诱骗拜访了某个恶意网页，而恶意网页中植入了一段js代码，自动发起 WebSocket 握手央求跟目的运用树立 WebSocket 衔接。留意到，Origin 和 Sec-WebSocket-Key 都是由阅读器自动生成的，阅读器再次发起央求拜访目的效劳器会自动带上Cookie 等身份认证参数。假设效劳器端没有反省 Origin头，则该央求会成功握手切换到 WebSocket 协议，恶意网页就可以成功绕过身份认证衔接到 WebSocket 效劳器，进而窃取到效劳器端发来的信息，或许发送伪造信息到效劳器端窜改效劳器端数据。与传统跨站央求伪造(CSRF)攻击相比，CSRF 主要是经过恶意网页悄然发起数据修正央求，而跨站 WebSocket 伪造攻击不只可以修正效劳器数据，还可以控制整个双向通讯通道。也正是由于这个缘由，Christian 将这个破绽命名为劫持(Hijacking)，而不是央求伪造(Request Forgery)。

了解了跨站WebSocket劫持攻击的原理和进程，那么如何防范这种攻击呢?处置也比较复杂，在效劳器端的代码中添加 对Origin头的反省，假设客户端发来的 Origin 信息来自不同域，效劳器端可以拒绝该央求。但是仅仅反省 Origin 依然是不够安全的，恶意网页可以伪造Origin头信息，绕过效劳端对Origin头的反省，更完善的处置方案可以自创CSRF的处置方案-令牌机制。

拒绝效劳

WebSocket设计为面向衔接的协议，可被应用惹起客户端和效劳器端拒绝效劳攻击，相关案例可参考: F5 BIG-IP远程拒绝效劳破绽( CVE-2016-9253 )。

1. 客户端拒绝效劳

WebSocket衔接限制不同于HTTP衔接限制，和HTTP相比，WebSocket有一个更高的衔接限制，不同的阅读器有本人特定的最大衔接数,如：火狐阅读器默许最大衔接数为200。经过发送恶意内容，用尽允许的一切Websocket衔接耗尽阅读器资源，惹起拒绝效劳。

2. 效劳器端拒绝效劳

(责任编辑：admin)