0×00. 前言
有时候我们遇到一个存储型xss 漏洞,但是sessionId设置了httpOnly,劫持不了会话,显得很鸡肋,让渗透测试人员很蛋疼,不过这种情况正在好转,随着HTML5的流行,通过HTML5 的CORS功能实现跨域通信,建立HTTP tunnel通信,实现会话劫持已经变成可能,本文就通过实测验证HTML5的CORS条件下的xss会话劫持的可行性。 关于HTML5 的CORS 特性,请参考:http://www.ruanyifeng.com/blog/2016/04/cors.html 0×01. 前提条件1)有一个存在XSS 漏洞的站点(最好是存储型的) 2)站点cookie使用了httpOnly 3)客户端浏览器支持HTML5 (因为用户端【被控端】和控制端需要通过HTML CORS 跨域通信,建立http通道) 0×02. 本次实验环境漏洞环境:1.修改后的dvwa (修改默认security level 修改为high,且high level下设置了httpOnly标志) [/url] [url=http://image.3001.net/images/20170314/14894904442568.jpg] 使用到的工具:
2.用户端浏览器使用chrome 3. Shell of the Future_v0.9
本文用到的最重要工具,用来实现XSS会话劫持,关于Shell of the Future,请参考:http://www.andlabs.org/tools/sotf/sotf.html Shell of the Future 监听8080 和1337端口,8080 为对外公开,提供恶意js下载、建立http 通道
1337 监听在本地,用来管理被劫持的会话 选择Server + Proxy 模式,点击start 即可 [/url] 4. burpsuite 1.7 运行在客户端(就是在虚拟机中,用户端访问含有XSS漏洞的站点时通过burpsuite代理访问,这样会捕获用户的访问,观察会话劫持的过程)
5.Vmware WorkStation 虚拟机,充当用户端 (192.168.3.206) 虚拟机充当用户访问设备 ,宿主机充当以下角色 1)dvwa 所在服务器(充当含有XSS漏洞的站点)192.168.2.85[url=http://www.xss.net/]www.xss.net 2)xss漏洞触发时下载js所在服务器(即Shell of the Future所在服务器)192.168.2.85www.attacker.net 3)Shell of Future 管理后台: http://localhost/sotf.console
登录Shell of Future 管理后台的浏览器做以下设置: [/url] 然后地址栏输入 [url=http://localhost/sotf.console]http://localhost/sotf.console,当看到如下界面时,说明shell of the future 和管理后台的浏览器设置OK [/url] 0×03. 测试过程1) 事先插入一段xss代码修改dvwa 数据库下的guestbook表的comment字段大小为800(不然长度不够嘿嘿) [url=http://image.3001.net/images/20170314/14894906383969.jpg] 然后插入一段xss 代码 [/url] 2) 配置好用户端的hosts192.168.2.85[url=http://www.xss.net/]www.xss.net 192.168.2.85www.attacker.net 3)开始测试用户端打开含有xss漏洞的站点: [/url] 恩,确认cookie设置了httpOnly标识 打开含有xss代码的页面,触发xss漏洞, OK, 通过截包,我们看看发生了什么 [url=http://image.3001.net/images/20170314/14894907109570.jpg] Ok,我们看到恶意js加载执行后就开始利用HTML CORS 特性跨域向控制端poll请求(poll 8080 端口,相当于在8080 建立了一条http 通道), [/url] 控制端接收到HTML CORS 请求后,从origin中获取被劫持会话的地址 (控制端就是HTML CORS的 server端) [url=http://image.3001.net/images/20170314/14894907413200.jpg] 然后。 控制端就给用户端分配一个 ID ,用于标识被劫持的sessionID, 从1开始, [/url] 用户端poll指令的时候携带上sessionID编号,控制端就知道要处理的是哪一个被劫持的session。 当hacker 在控制端点击被劫持的session的时候,控制端(1337端口)截获了此点击(确定是GET 请求还是POST请求,有木有携带参数),处理之后转发给8080端口的服务,然后通过8080的http 通道向用户(被控端)发送指令 当hacker 点击被劫持的session的host的时候(比如上图的[url=http://www.xss.net/]www.xss.net),就相当于向用户端发送了GET http://www.xss.net 指令 用户端poll到指令之后,就开始执行了 [/url] 上图指令是被hex加密之后的,16进制的分隔符是x,解码之后就是指令内容 其中m 表示请求方法,u表示请求的url,b表示请求参数,ct表示额外的请求头部,ssl表示是否加密,rid表示第几次请求 上图u 解密之后表示:[url=http://www.xss.net/]http://www.xss.net/, 上述指令表示获取http://www.xss.net/的内容并发送给控制端 [/url] 用户端执行完指令之后将指令执行结果内容push到控制端(利用HTML CORS特性跨域push) [url=http://image.3001.net/images/20170314/14894908878848.jpg] 注意到push的请求了吗, 1_1 表示第一个劫持会话的第一次请求, push的内容是www.xss.net首页内容,内容格式 请求编号&请求响应码&响应头部内容&响应body 请求编号表示第几次请求,响应头部和响应body 都经过16进制编码,16进制的分隔符是x 控制端接收到用户端的push之后,hex解码展现给用户 [/url] 此后hacker在控制台点击被劫持会话页面的每个动作都被1337端口截获,1337端口监听的服务处理后将向用户端发送指令(这就是为什么设置代理的原理,发送指令是通过已建立的8080 端口 http 通道) 然后等待指令执行结果,然后展现给控制台,这就实现了会话劫持! 0×04. shell of the future 劫持会话原理图[url=http://image.3001.net/images/20170314/1489491283483.jpg]
[/url] 0×05. 不足用户端如果离开含有xss代码的页面的时候,则建立的http 通道断开连接 (e1.js 不会再执行,客户端不会轮询控制端指令,控制端没法下发指令) from:[url]http://www.freebuf.com/articles/web/129384.html
|