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