如何全面掌控Session?且看WebSocket跨站劫持
WebSockets是一個能夠給單TCP連線提供全雙工通道的HTML5特性。它的持續性連線功能,使得構建B/S模式的實時應用成為可能。Websockets常常用在那些帶有聊天功能的WEB應用上。
下面的圖片就非常貼切地闡釋了一個APT攻擊用到的websockets:
科普:
同源策略(Same origin policy):同源是指,域名,協議,埠相同,即瀏覽器會檢查同一瀏覽器的不同選項卡中,來源相同的指令碼才能跨選項卡執行。
Origin欄位:瀏覽器在傳送POST請求的時候可能會加上一個Origin欄位,這個Origin欄位主要是用來標識出最初請求是從哪裡發起的。如果瀏覽器不能確定源在哪裡,那麼在傳送的請求裡面Origin欄位的值就為空。
IronWASP:某開源WEB測試平臺,使用者可以自定義安全掃描,並且可以自己用python/ruby來定義外掛系統。相關介紹見:http://www.freebuf.com/tools/32948.html
ZAP(Zed Attack Proxy):是一款整合各種工具的滲透測試框架,可以發現在WEB應用程式中的漏洞,相關介紹見:http://www.freebuf.com/tools/5427.html
WebSocket的安全評估
最近,我們對一個擁有複雜選單選項和功能的WEB應用做了安全評估。該應用中大部分操作都用到了web-sockets,這意味著其大多數行為都不會記錄到http代理日誌上。
首先,我們開啟主頁後,網站會載入一個帶有JS指令碼和CSS檔案的靜態網頁。此後,整個通訊互動會轉為Websockets模式,瀏覽器和服務端之間會建立websocket連線,從而載入網站裡所有可見的HTML資源。點選連結或者提交Form表單時,瀏覽器會向服務端傳送一些WebSocket訊息。伺服器處理了這些訊息後,會通過WebSocket進行反饋,而後客戶端瀏覽器會展示新的HTML內容。
這時當websocket訊息在進行互動時,通訊數量是非常巨大的。每隔一秒它們之間會有心跳探測包的互動。然而現有的工具達不到我的要求,我不得不給IronWASP新增了一個Websocket訊息分析裝置和一個WebSocket客戶端,這樣它才能識別Websocket從而嘗試fuzz其漏洞。你可以在在這裡瞭解下相關知識。
在測試這個應用時,我發現它存在WebSocket跨站劫持(Cross-Site WebSocket Hijacking)漏洞(由christian schneider首創)。當然,我會在給大家介紹測試方法之前,解釋下這個漏洞的影響。在測試相關Websockets應用之前,我們需要先做下準備。
WebSocket跨站劫持漏洞實驗準備
大家應該明白,同源策略(SOP)不會通過瀏覽器在websockets上強制執行(同一瀏覽器下,受SSL保護的頁面,不會讓非SSL的WebSocket通過),我們測試的應用採用了http cookie作為session認證,WebSocket通過瀏覽器傳送的訊息不會有Session ID或是隨機引數。
這樣一來,如果某使用者登入了帶有漏洞的WEB應用,然後在同一瀏覽器還開啟了http://attacker.com(攻擊者的網站),http://attacker.com可以嘗試通過該漏洞應用與應用的服務端建立一個WebSocket連線,然後通過瀏覽器傳送一個帶有效的認證Session ID的請求包。於是,這個由攻擊者網站建立的WebSocket連線會和應用本身有相同的許可權。
由於整個應用都是以websockets為基礎執行的,劫持了WebSocket就相當於劫持了使用者的session。所以這個漏洞在本質上和儲存型跨站指令碼漏洞是一樣的。
如果你認為這就很糟了,那當你聽到某些情況下WebSocket跨站指令碼,甚至可以在使用者系統上實現遠端程式碼執行的時候,會不會更驚訝呢?事見IPython Notebook的案例。
測試之前,你首先要做的就是確認該應用是否存在WebSockets。幸運的是,做這個非常簡單,你只需要知道以下三點:
1.WebSocket的URL連線一般是以ws://或者wss://開頭的。
2.需要檢測建立連線的Origin頭,該網頁可能是通過Origin欄位建立的WebSocket連結。
3.瀏覽器和服務端之間傳送的訊息中,我們可以從中檢查出普通WebSocket連線的特徵。
下面這張圖會給你展示:如何通過IronWASP日誌得到Origin欄位的值和WebSocket的URL值。
一旦你得到這些資訊,你可以使用一些特殊方法,對跨站WebSocket劫持漏洞進行檢測。我在這裡例舉三個簡單的例子:
使用代理軟體(如Burpsuite):
這裡必須提到的是,burpsuite可以捕獲和記錄WebSockets的訊息。而ZAP和IronWASP是我所知道的,可以重放websocket請求的軟體。
在burpsuite裡,我們不能重放websockets訊息,但我們還是可以在有限條件下,檢測WebSocket握手包是否成功。為了進行測試,我們需要分析websocket的升級請求包:它們會通過http或者https傳送,因此可以被重放。
以下截圖為burpsuite重放器(Repeat選項卡)的記錄,其顯示了websocket連線的有效請求和應答情況:
為了測試這個漏洞,我們需要傳送另一個帶有重製後的Origin頭的請求包。如果我們回應包裡有“101 Web Socket Protocol Handshake”的標誌,這就表示WebSocket已經建立成功了。
如果連線沒有建立成功,那就意味著該應用不存在這個漏洞,因為它會拒絕外部的WebSocket連線。建立成功後,我們就可以開始下一步測試,看看該應用是否有WebSocket跨站劫持漏洞。這裡需要說明一下:即使已經建立連線,也需要其如Origin的正常連線一般,確認得到服務端對WebSocket訊息的應答之後,才能證明該應用存在漏洞。這是因為開發者可能會同時啟用Origin檢測與連線許可權認證。因此我們的實驗中也許會出下面這種情況:建立的連線可以一直保持,但擁有外部來源的Origins不會通過認證。
ZAP可以重放WebSocket訊息,但據我瞭解,它並不能更改Origin頭。下面介紹的方法可以給你科普下,如何通過CSWSH(WebSocket跨站劫持)來獲得更多的東西。
使用WebSocket跨站劫持的線上測試工具
開啟需要測試的WEB應用登入其中,然後在同一瀏覽器中開一個新選項卡,訪問http://ironwasp.org/cswsh.html(模擬的黑客網站),輸入該WebSocket的URL地址,然後點選網頁上的Connect按鈕。一旦建立連線,你就可以通過這個頁面向WebSocket的伺服器傳送訊息。我們需要通過重放有效session傳送過的訊息,然後檢視伺服器的回應包。
如果服務端的回應與前面有效session傳送的正常包相同,那就說明該應用可能存在WebSocket跨站劫持漏洞。
使用IronWASP
IronWASP可以做到更多,即使是最基礎的檢測也能提供自動化指令碼檢查。
使用IronWASP的WebSocket客戶端
以上測試Origin的方法的使用的服務端是http://ironwasp.org,如果你想要更加靈活地設定Origin值,你可以使用IronWASP的客戶端功能。它允許你自定義Origin值來測試WebSocket連線。
在以下環境下可能會用到客戶端功能:
1.應用允許來自開放的Origin的WebSocket連線
2.應用允許來自localhost和內網IP的Origin欄位值
這種做法是為了方便開發者和應用的內部測試。通過使用IronWASP的客戶端,你可以嘗試內網IP或者localhost作為Origin是否能夠生效。如果可以的話,那沒準兒你可以耍一點小手段,在真實環境下利用這個漏洞。比如,如果某個應用允許http:/127.0.0.1:8080作為Origin欄位,那我們就可以這樣做:若受害者正好有個在本地8080埠執行的WEB應用,而且其存在跨站指令碼漏洞。如果滿足這些條件,黑客可以先在該WEB應用上進行跨站攻擊,然後再向目標應用服務端建立WebSocket連線:
使用IronWASP的WebSocket API進行自動化檢測
如果你需要利用localhost或者內網IP進行測試Origin頭,使用客戶端指令碼進行自動化檢測會讓你的行動更加輕鬆。IronWASP允許你使用Python或者Ruby進行實現自定義指令碼編寫。
下面這個指令碼可以單獨檢測Origin頭裡填充的內網IP地址,測試服務端對此是否認可:
import clr clr.AddReference("WebsocketClient.exe") from WebsocketClient import * def check_conn(origin): print "Testing origin - " + origin ws = SyncWebsockClient() ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212") ws.Send("first message to send") msg = ws.Read() ws.Close() if msg == "message that is part of valid session": print "Connection successful!!" return True else: return False def check_nw(): for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]: for ip in Tools.NwToIp(nws): if check_conn("http://" + ip): break check_nw()
相關文章
- 如何處理網站劫持網站
- 什麼是DNS劫持?如何讓你的網站免遭DNS劫持?DNS網站
- 能否劫持網站流量、網站流量劫持的方法網站
- 全面解析 掌控SOA價值關鍵
- 網站被劫持到其它網站如何解決網站
- 網站安全漏洞之SESSION防跨站攻擊獲取網站Session
- 網站被劫持的方式有幾種?遭遇劫持如何處理?網站
- 如何解決瀏覽器被網站劫持瀏覽器網站
- 網站監控網站劫持,網站監控網站劫持有哪些需要注意的網站
- 後門病毒通過下載站傳播 全面劫持各大主流瀏覽器瀏覽器
- 如何防止域名被劫持?網站域名被劫持怎麼辦?怎麼處理?網站
- php跨域共享sessionPHP跨域Session
- 做遊戲的,且看公司背景如何(上)?遊戲
- WebSocket跨域問題解決Web跨域
- 如何防止獨立IP虛擬主機網站遭PR劫持、被pr劫持的後果網站
- 如何防止網站快照被劫持收錄灰色內容網站
- 網站劫持跳轉,分享網站被劫持跳轉的解決辦法網站
- 網站 DNS劫持 檢測,網站被DNS劫持該怎麼檢測出來網站DNS
- app安全:如何應對介面劫持、介面劫持如何檢測APP
- 怎麼檢視域名是否被劫持沒有、如何判斷網站域名是否被劫持?網站
- 網站快照被劫持,網站被劫持跳轉另一個網站解決辦法網站
- php實現SESSION跨域PHPSession跨域
- BadTunnel:跨網段劫持廣播協議協議
- Cookie Session跨站無法共享問題(單點登入解決方案)CookieSession
- 網站被劫持攻擊以及流量攻擊如何解決網站
- 什麼是DNS劫持?如何應對DNS劫持?DNS
- 網站被劫持 網站被劫持跳轉到非法頁面的解決辦法網站
- 網站安全:dns汙染與dns劫持網站DNS
- 公司官網百度快照劫持、那麼如何處理解決網站被劫持的問題呢?網站
- 網站百度快照被劫持如何快速恢復、百度快照劫持怎麼解決了網站
- 非正式全面解析 NebulaGraph 中 Session 管理Session
- 大資料時代,且看Flink如何叱吒風雲大資料
- iframe跨域session丟失問題跨域Session
- 百度域名劫持案,網站域名被劫持後的處理方法網站
- React如何解決fetch跨域請求時session失效問題React跨域Session
- cookie和session的區別(全面總結)CookieSession
- SignalR跨域解決方案全面SignalR跨域
- dns汙染與dns劫持,瞭解dns汙染與dns劫持,網站安全不可疏忽DNS網站