了解websocket
websocket是HTML5的新特性，在客户端和服务端提供了一个基于TCP连接的双向通道。
websocket是通过ws:// 和wss:// 通信协议，其中ws可以认为是http的切换，wss是https的切换，是加密的传输协议
websocket与http的是没有任何关系的，websocket是持久化的协议，而http是非持久的
WebSocket 提供了全双工沟通，俗称 Web 的 TCP 连接，但 TCP 通常处理字节流（跟消息无关），而 WebSocket 基于 TCP 实现了消息流
WebSocket 也类似于 TCP 一样进行握手连接，跟 TCP 不同的是，WebSocket 是基于 HTTP 协议进行的握手
优点：
- 支持双向通信，实时性比较强
- 更好的二进制支持
- 较少的开销。创建连接后，数据交换时候不用携带所有的数据头部信息
- 支持拓展
缺点：
- 缺少认证机制
- 存在跨站点劫持漏洞
WebSocket 协议
首先看个http请求：
GET ws://echo.websocket.org/?encoding=text HTTP/1.1
Host: echo.websocket.org
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://www.websocket.org
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) Chrome/49.0.2623.110
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6
Cookie: _gat=1; _ga=GA1.2.2904372.1459647651; JSESSIONID=1A9431CF043F851E0356F5837845B2EC
Sec-WebSocket-Key: 7ARps0AjsHN8bx5dCI1KKQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits里面的核心：Connection: Upgrade以及Upgrade: websocket 这个就是告诉服务器，下一步我要对协议进行升级了，升级到websocket。
此时服务器的响应：
HTTP/1.1 101 Web Socket Protocol Handshake
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Headers: x-websocket-extensions
Access-Control-Allow-Headers: x-websocket-version
Access-Control-Allow-Headers: x-websocket-protocol
Access-Control-Allow-Origin: http://www.websocket.org
Connection: Upgrade
Date: Sun, 03 Apr 2016 03:09:21 GMT
Sec-WebSocket-Accept: wW9Bl95VtfJDbpHdfivy7csOaDo=
Server: Kaazing Gateway
Upgrade: websocket服务器返回响应代码101，进行websocket的协议切换。基于相同的端口，通信协议从http或者https切换到ws或者wss。切换完成之后，浏览器和服务器之间就可以通过webSocket的API进行通信
请求头部有一些重要的参数，Sec-WebSocket-Key 和Sec-WebSocket-Accept，客户端生成一个Base64编码的随机数字作为Sec-WebSocket-Key，服务器则会将一个GUID和这个客户端随机数生成一个散列key作为Sec-WebSocket-Accept:返回给客户端。这个工作机制可以用来避免缓存代理，可以用来避免请求重放
其中sec-开头的header值是无法通过浏览器的脚本读取到的，这样保证了无法使用ajax来模拟请求
Javascript创建websocket请求
<script>
function ws_attack(){
var ws = new WebSocket("ws://域名:端口/");//如果请求的Websocket服务仅支持HTTP就写成ws://，如果请求的Websocket服务支持HTTPs就写成wss://
ws.onopen = function(evt) {
ws.send(message);//发送的数据
};
ws.onmessage = function(evt) {
ws.close();
};
}
ws_attack();
</script>跨站点 WebSocket 劫持漏洞
漏洞主要基于以下两点构成：
- WebSocket 在进行协议切换的时候，会把所有域下面的cookie值都发送给服务器，但是websocket协议并没有规定服务器在握手阶段是如何认证客户端身份，服务器端可以采用http的客户端身份认证机制，这样就可以通过CSRF进行攻击，绕过身份认证。
- websocket的客户端不仅仅局限于浏览器，这样，就没有办法规范Origin。所有的浏览器都会发送 Origin 请求头，如果服务器端没有针对 Origin 头部进行验证可能会导致跨站点 WebSocket 劫持攻击
Origin 和 Sec-WebSocket-Key 都是由浏览器自动生成，Cookie 等身份认证参数也都是由浏览器自动上传到目标应用服务器端。如果服务器端疏于检查 Origin，该请求则会成功握手切换到 WebSocket 协议，恶意网页就可以成功绕过身份认证连接到 WebSocket 服务器，进而窃取到服务器端发来的信息，抑或发送伪造信息到服务器端篡改服务器端数据。有兴趣的读者可以将这个漏洞跟 CSRF 进行对比，CSRF 主要是通过恶意网页悄悄发起数据修改请求，不会导致信息泄漏问题，而跨站点 WebSocket 伪造攻击不仅可以修改服务器数据，还可以控制整个读取/修改双向沟通通道。正是因为这个原因，Christian 将这个漏洞命名为劫持（Hijacking），而不是请求伪造（Request Forgery）。
篡改后的请求：
GET ws://echo.websocket.org/?encoding=text HTTP/1.1
Host: echo.websocket.org
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://www.malicious.website.com
Sec-WebSocket-Version: 13
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6
Cookie: _gat=1; _ga=GA1.2.290430972.14547651; JSESSIONID=1A9431CF043F851E0356F5837845B2EC
Sec-WebSocket-Key: 7ARps0AjsHN8bx5dCI1KKQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits这里去malicious.website.com请求websocket.org，根据CORS，应该是无法读取到资源信息的，但是不幸的是，跨域资源共享不适应于 WebSocket，WebSocket 没有明确规定跨域处理的方法。
跨站点 WebSocket 劫持漏洞的检测
检测方法：
使用能拦截到 WebSocket 握手请求的工具，修改请求中的 Origin 头信息，然后重新发送这个请求，看看服务器是否能够成功返回 101 响应
防范跨站点 WebSocket 劫持攻击
- 服务器端检测Origin在服务器端的代码中增加 Origin 检查，如果客户端发来的 Origin 信息来自不同域，建议服务器端拒绝这个请求，发回 403 错误响应拒绝连接实例代码：
public class CustomConfigurator extends ServerEndpointConfig.Configurator {
private static final String ORIGIN = "http://jeremy.laptop:8080";
@Override
public boolean checkOrigin(String originHeaderValue) {
if(originHeaderValue==null || originHeaderValue.trim().length()==0)
return true;
return ORIGIN.equals(originHeaderValue);
}
}- WebSocket 令牌机制具体实现流程如下：
服务器端为每个人 WebSocket 客户端生成唯一的一次性 Token；
客户端将 Token 作为 WebSocket 连接 URL 的参数（比如 ws://echo.websocket.org/?token＝randomOneTimeToken），发送到服务器端进行 WebSocket 握手连接； 服
务器端验证 Token 是否正确，一旦正确则将这个 Token 标示为废弃不再重用，同时确认 WebSocket 握手连接成功；如果 Token 验证失败或者身份认证失败，则返回 403 错误。