小心 ！跨站點websocket劫持！
開始之前，先熱熱身，講個小故事：
年終獎下來了，張大胖琢磨著去買點兒股票作為投資，他用瀏覽器訪問了www.stock.com ， 輸入了用戶名和密碼，登錄成功。
stock.com返回了cookie用來標識張大胖這個用戶。
瀏覽器認真負責， 它把這個Cookie記錄了下來，以后張大胖每一次再向stock.com發起Http請求，瀏覽器都會兢兢業業地把Cookie加入到Http請求的Header中，一并發到stock.com ， 這樣stock.com就知道張大胖已經登陸過了，就可以按照張大胖的請求來做事情，比如查看股票，買賣股票。
張大胖看到股票漲幅不錯，心中暗喜。 他又打開了www.beauty.com， 去看一些自己的小秘密。
瀏覽器把beauty.com的HTML，JavaScript都下載到本地，開始執行。
這個JavaScript中創建了一個XMLHttpRequest對象，然后居然向stock.com發起了HTTP請求 !
瀏覽器嚴格按照規定，把之前存儲的cookie也添加到Http請求中 !
無辜的stock.com根本不知道這個Http請求是beauty.com的JavaScript發出的，還是張大胖發出的。
stock.com 檢查了cookie，就知道這是一個登錄過的用戶，于是就冷冰冰地去執行，張大胖的個人信息就泄露了。
(當然，實施這樣一次攻擊不會這么簡單，這里只是說明基本原理)
可憐的張大胖就是因為瀏覽了一個網站，就遭受了錢財損失。 這也太可怕了!
我們來復盤一下為什么會發生這種情況， 主要有兩個原因：
首先，每當訪問stock.com的時候(不管是人點擊按鈕/鏈接，或者是通過程序的方式)，存儲在瀏覽器的stock.com的cookie都會發過去。
其次，從beauty.com下載的JS利用XMLHttp訪問了stock.com。
第一點我們是無法阻止的， 如果阻止了，cookie就沒用了。
對于第二點，瀏覽器必須做出限制， 不能讓來自beauty.com的JavaScript去訪問stock.com! 這個限制就是大家所熟知的同源策略。
同源策略非常嚴格，要求兩個URL必須滿足下面三個條件才算同源。
(1) 協議(http/https) 相同
(2) 域名相同
(3) 端口相同
這個要求可以說是殺敵一千，自損八百。
因為對大的系統來說，有很多域名是很正常的事情，現在JavaScript只能向自己的“源”發起請求，不能訪問別的系統，這實在是太讓人難受了。
于是人們想了很多辦法，比如JSONP , CORS等來突破這個限制。
等到websocket這個新的技術出現以后，干脆放棄了這個限制，websocket可以跨域訪問。
但是這就帶來的安全隱患： 跨站點websocket 劫持 ， 我們接著張大胖的故事往下講。
跨站點websocket 劫持
張大胖又一次登錄了www.stock.com， 瀏覽器又收到了cookie并且保存了下來， 這一次張大胖發現stock.com提供了一個新功能： 實時的股票價格推送。
張大胖開啟了這個新功能，這是用websocket實現的。 大家都知道，websocket的通信是由HTTP協議發起的。
瀏覽器向stock.com發起了一個HTTP請求， 這個請求希望把HTTP 協議升級為web socket協議，下面是HTTP請求的Header：
- GET /stock/ws HTTP/1.1
- Host: www.stock.com
- User-Agent: xxxxxx
- ......
- Origin: https://www.stock.com
- Sec-WebSocket-Key: xxxxx
- Cookie: JSESSIONID=2B323FCF3968ETDSA9459
- Connection: keep-alive, Upgrade
- Upgrade: websocket
注意，Cookie數據也發送給了stock.com。
stock.com檢查Cookie，確認是個登陸過的客戶，于是建立websocket連接，并且推送張大胖訂閱的最新的股票信息。
張大胖看到最新的股票信息，很高興，他又打開了www.beauty.com， 去看一些自己的小秘密。
這個beauty.com中的JavaScript又一次運行，也向stock.com發起HTTP請求，也要建立websocket連接。
- GET /stock/ws HTTP/1.1
- Host: www.stock.com
- User-Agent: xxxxxx
- ......
- Origin: https://www.beauty.com
- Sec-WebSocket-Key: xxxxx
- Cookie: JSESSIONID=2B323FCF3968ETDSA9459
- Connection: keep-alive, Upgrade
- Upgrade: websocket
stock.com收到請求，檢查Cookie，確認是個登陸過的客戶，也成功地建立了websocket連接， 把數據也推送給你beauty.com ， 于是張大胖的信息就暴漏了。
如果這個websocket還支持別的操作，那危害就更大了。(這也是被稱為“劫持”，而不僅僅是“偽造”的原因)
可以看出，websocket不遵守同源策略，是導致跨站點腳本劫持的最大原因。
Websocket協議怎么解決這個問題呢?
敏銳的同學已經注意了，在前面的HTTP請求中，有個叫做Origin的東西：
合法請求：
Origin: https://www.stock.com
攻擊請求：
Origin: https://www.beauty.com
這個Origin是websocket協議所要求的。
所以在www.stock.com的服務器端，在建立websocket連接的時候，一定要去檢查這個Origin,確保這個Origin在自己的白名單中。
幾個小問題
1. 不就是一個Origin嗎? 黑客可以輕松地偽造啊?
注意：這一切都發生在張大胖的瀏覽器中，是張大胖在操作， 黑客想偽造的話，只能通過JavaScript來修改它。
但是協議規定： 這個Origin是在HTTP Header中， 是由瀏覽器自動加上的，不能通過編程的方式(如JavaScript)來改變它。
2. 那黑客可以修改HTTP請求，把這個Origin改了啊?
如果你控制了張大胖的瀏覽器，甚至張大胖的電腦，那肯定可以修改HTTP請求， 但是都控制電腦了，一切盡在掌握，還費這勁干嘛，直接監控用戶名和密碼不就得了。
如果你充當中間人，通過抓包的方式，來修改Origin，那確實可以，這時候張大胖需要用Https，和wss來防范了。
3. 還有沒有別的辦法來防范?
有的，還有個更加安全的辦法，和防范CSRF的思想是一致的： 使用token 。
(1) 服務器端給每個websocket客戶端分配一個隨機的，唯一的token
(2) 瀏覽器在建立websocket連接的時候，把token也發過來。
(3) 服務器端驗證token， 如果有效，才建立連接，并且廢棄掉這個token。
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
