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