如何全面掌控Session?且看WebSocket跨站劫持

澳门新葡亰赌995577 9

WebSockets是一个能够给单TCP连接提供全双工信道的HTML5特性。它的持续性连接功能,使得构建B/S模式的实时应用成为可能。Websockets常常用在那些带有聊天功能的WEB应用上。

有关IM(InstantMessaging)聊天应用、消息推送技术(如:现今移动端APP标配的消息推送模块)等即时通�讯应用场景下,大多数都是桌面应用程序或者native应用较为流行,而网上关于原生IM(相关文章请参见:《IM架构篇》、《IM综合资料》、《IM/推送的通信格式、协议篇》、《IM心跳保活篇》、《IM安全篇》、《实时音视频开发》)、消息推送应用(参见:《推送技术好文》)的通信原理介绍也较多,此处不再赘述。

下面的图片就非常贴切地阐释了一个APT攻击用到的websockets:

而web端的IM应用,由于浏览器的兼容性以及其固有的“客户端请求服务器处理并响应”的通信模型,造成了要在浏览器中实现一个兼容性较好的IM应用,其通信过程必然是诸多技术的组合,本文的目的就是要详细探讨这些技术并分析其原理和过程。

澳门新葡亰赌995577 1


更多即时通讯技术资料:

科普:

同源策略(Same origin
policy):同源是指,域名,协议,端口相同,即浏览器会检查同一浏览器的不同选项卡中,来源相同的脚本才能跨选项卡执行。

Origin字段:浏览器在发送POST请求的时候可能会加上一个Origin字段,这个Origin字段主要是用来标识出最初请求是从哪里发起的。如果浏览器不能确定源在哪里,那么在发送的请求里面Origin字段的值就为空。

IronWASP:某开源WEB测试平台,用户可以自定义安全扫描,并且可以自己用python/ruby来定义插件系统。相关介绍见:

ZAP(Zed Attack
Proxy):是一款集成各种工具的渗透测试框架,可以发现在WEB应用程序中的漏洞,相关介绍见:

– 即时通讯开发交流群:215891622

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应用之前,我们需要先做下准备。

【�Web端即时通讯技术盘点请参见】:

WebSocket跨站劫持漏洞实验准备

大家应该明白,同源策略(SOP)不会通过浏览器在websockets上强制执行(同一浏览器下,受SSL保护的页面,不会让非SSL的WebSocket通过),我们测试的应用采用了http
cookie作为session认证,WebSocket通过浏览器发送的消息不会有Session
ID或是随机参数。

这样一来,如果某用户登录了带有漏洞的WEB应用,然后在同一浏览器还打开了
ID的请求包。于是,这个由攻击者网站建立的WebSocket连接会和应用本身有相同的权限。

由于整个应用都是以websockets为基础运行的,劫持了WebSocket就相当于劫持了用户的session。所以这个漏洞在本质上和存储型跨站脚本漏洞是一样的。

如果你认为这就很糟了,那当你听到某些情况下WebSocket跨站脚本,甚至可以在用户系统上实现远程代码执行的时候,会不会更惊讶呢?事见IPython
Notebook的案例。

测试之前,你首先要做的就是确认该应用是否存在WebSockets。幸运的是,做这个非常简单,你只需要知道以下三点:

1.WebSocket的URL连接一般是以ws://或者wss://开头的。

2.需要检测建立连接的Origin头,该网页可能是通过Origin字段建立的WebSocket链接。

3.浏览器和服务端之间发送的消息中,我们可以从中检查出普通WebSocket连接的特征。

下面这张图会给你展示:如何通过IronWASP日志得到Origin字段的值和WebSocket的URL值。

澳门新葡亰赌995577 2

一旦你得到这些信息,你可以使用一些特殊方法,对跨站WebSocket劫持漏洞进行检测。我在这里例举三个简单的例子:

《Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE》

使用代理软件(如Burpsuite):

这里必须提到的是,burpsuite可以捕获和记录WebSockets的消息。而ZAP和IronWASP是我所知道的,可以重放websocket请求的软件。

在burpsuite里,我们不能重放websockets消息,但我们还是可以在有限条件下,检测WebSocket握手包是否成功。为了进行测试,我们需要分析websocket的升级请求包:它们会通过http或者https发送,因此可以被重放。

以下截图为burpsuite重放器(Repeat选项卡)的记录,其显示了websocket连接的有效请求和应答情况:

澳门新葡亰赌995577 3

为了测试这个漏洞,我们需要发送另一个带有重制后的Origin头的请求包。如果我们回应包里有“101
Web Socket Protocol Handshake”的标志,这就表示WebSocket已经建立成功了。

如果连接没有建立成功,那就意味着该应用不存在这个漏洞,因为它会拒绝外部的WebSocket连接。建立成功后,我们就可以开始下一步测试,看看该应用是否有WebSocket跨站劫持漏洞。这里需要说明一下:即使已经建立连接,也需要其如Origin的正常连接一般,确认得到服务端对WebSocket消息的应答之后,才能证明该应用存在漏洞。这是因为开发者可能会同时启用Origin检测与连接权限认证。因此我们的实验中也许会出下面这种情况:建立的连接可以一直保持,但拥有外部来源的Origins不会通过认证。

ZAP可以重放WebSocket消息,但据我了解,它并不能更改Origin头。下面介绍的方法可以给你科普下,如何通过CSWSH(WebSocket跨站劫持)来获得更多的东西。

【关于Ajax短轮询】:

使用WebSocket跨站劫持的在线测试工具

打开需要测试的WEB应用登入其中,然后在同一浏览器中开一个新选项卡,访问

如果服务端的回应与前面有效session发送的正常包相同,那就说明该应用可能存在WebSocket跨站劫持漏洞。

澳门新葡亰赌995577 4

澳门新葡亰赌995577 5

找这方面的资料没什么意义,除非忽悠客户,否则请考虑其它3种方案即可。

使用IronWASP

IronWASP可以做到更多,即使是最基础的检测也能提供自动化脚本检查。

【有关Comet技术�的详细介绍请参见】:

使用IronWASP的WebSocket客户端

以上测试Origin的方法的使用的服务端是

澳门新葡亰赌995577 6

在以下环境下可能会用到客户端功能:

1.应用允许来自开放的Origin的WebSocket连接

澳门新葡亰赌995577,2.应用允许来自localhost和内网IP的Origin字段值

这种做法是为了方便开发者和应用的内部测试。通过使用IronWASP的客户端,你可以尝试内网IP或者localhost作为Origin是否能够生效。如果可以的话,那没准儿你可以耍一点小手段,在真实环境下利用这个漏洞。比如,如果某个应用允许http:/127.0.0.1:8080作为Origin字段,那我们就可以这样做:若受害者正好有个在本地8080端口运行的WEB应用,而且其存在跨站脚本漏洞。如果满足这些条件,黑客可以先在该WEB应用上进行跨站攻击,然后再向目标应用服务端建立WebSocket连接:

澳门新葡亰赌995577 7

《Comet技术详解:基于HTTP长连接的Web端实时通信技术》

使用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()

《WEB端即时通讯:HTTP长连接、长轮询(long polling)详解》

《WEB端即时通讯:不用WebSocket也一样能搞定消息的即时性》

《开源Comet服务器iComet:支持百万并发的Web端即时通讯�方案》

【有关WebSocket的详细介绍请参见】:

《WebSocket详解:初步认识WebSocket技术》

《WebSocket详解:技术原理、代码演示和应用案例》

《WebSocket详解:深入WebSocket通信协议细节》

《Socket.IO介绍:支持WebSocket、用于WEB端的即时通讯的框架》

《socket.io和websocket 之间是什么关系?有什么区别?》

【有关SSE的详细介绍文章请参见】:

《SSE技术详解:一种全新的HTML5服务器推送事件技术》

【更多WEB端即时通讯文章请见】:

浏览器本身作为一个瘦客户端,不具备直接通过系统调用来达到和处于异地的另外一个客户端浏览器通信的功能。这和我们桌面应用的工作方式是不同的,通常桌面应用通过socket可以和远程主机上另外一端的一个进程建立TCP连接,从而达到全双工的即时通信。

浏览器从诞生开始一直走的是客户端请求服务器,服务器返回结果的模式,即使发展至今仍然没有任何改变。所以可以肯定的是,要想实现两个客户端的通信,必然要通过服务器进行信息的转发。例如A要和B通信,则应该是A先把信息发送给IM应用服务器,服务器根据A信息中携带的接收者将它再转发给B,同样B到A也是这种模式,如下所示:

澳门新葡亰赌995577 8

我们认识到基于web实现IM软件依然要走浏览器请求服务器的模式,这这种方式下,针对IM软件的开发需要解决如下三个问题:

双全工通信:

即达到浏览器拉取服务器数据,服务器推送数据到浏览器;

低延迟:

即浏览器A发送给B的信息经过服务器要快速转发给B,同理B的信息也要快速交给A,实际上就是要求任何浏览器能够快速请求服务器的数据,服务器能够快速推送数据到浏览器;

支持跨域:

通常客户端浏览器和服务器都是处于网络的不同位置,浏览器本身不允许通过脚本直接访问不同域名下的服务器,即使IP地址相同域名不同也不行,域名相同端口不同也不行,这方面主要是为了安全考虑。

即时通讯网注:关于浏览器跨域访问导致的安全问题,有一个被称为CSRF网络攻击方式,请看下面的摘录

CSRF(Cross-site request
forgery),中文名称:跨站请求伪造,也被称为:one click attack/session
riding,缩写为:CSRF/XSRF。

你这可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账……造成的问题包括:个人隐私泄露以及财产安全。

CSRF这种攻击方式在2000年已经被国外的安全人员提出,但在国内,直到06年才开始被关注,08年,国内外的多个大型社区和交互网站分别爆出CSRF漏洞,如:NYTimes.com、Metafilter(一个大型的BLOG网站),YouTube和百度HI……而现在,互联网上的许多站点仍对此毫无防备,以至于安全业界称CSRF为“沉睡的巨人”。

基于以上分析,下面针对这三个问题给出解决方案。

这是最简单的一种解决方案,其原理是在客户端通过Ajax的方式的方式每隔一小段时间就发送一个请求到服务器,服务器返回最新数据,然后客户端根据获得的数据来更新界面,这样就间接实现了即时通信。优点是简单,缺点是对服务器压力较大,浪费带宽流量(通常情况下数据都是没有发生改变的)。

客户端代码如下:

(简书无法支持程序代码样式,详细代码请见同步发布文章:

创建一个XHR对象,每2秒就请求服务器一次获取服务器时间并打印出来。

服务端代码:

(简书无法支持程序代码样式,详细代码请见同步发布文章:

结果如下:

澳门新葡亰赌995577 9

在上面的轮询解决方案中,由于每次都要发送一个请求,服务端不管数据是否发生变化都发送数据,请求完成后连接关闭。这中间经过的很多通信是不必要的,于是又出现了长轮询(long-polling)方式。这种方式是客户端发送一个请求到服务器,服务器查看客户端请求的数据是否发生了变化,如果发生变化则立即响应返回,否则保持这个连接并定期检查最新数据,直到发生了数据更新或连接超时。同时客户端连接一旦断开,则再次发出请求,这样在相同时间内大大减少了客户端请求服务器的次数。代码如下。(详细技术文章请参见《WEB端即时通讯:HTTP长连接、长轮询(long
polling)详解》)

客户端:

(简书无法支持程序代码样式,详细代码请见同步发布文章:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图