不过我认为PDP的风格比较土，比较猥琐，应该不会玩这种高级货，所以我认为他应该只是简单的把文件贴到一起了。后来翻到PDP去年在blackhat上的关于客户端安全的paper里，他果然是用 copy /B 来整的。
不过我和0day之王当时都很疑惑这玩意要怎么跑起来，难道是
就能当成jar运行吗？ 测试过后，发现显然是不行的。
其实我们还是浮躁了啊，没好好看news和paper，今天抽了点时间复习了下这几天的讨论，发现这个啥GIFAR原来是这么玩的，果然符合PDP一贯的猥琐风格。
1. 用 copy /B 或者类似手段把一个jar贴到一个gif后面，文件后缀还是叫 fvck.gif
2. 把这个新的gif文件上传到你要攻击的站点，比如baidu
3. 在第三方站点，注意，这里才是关键，第三方站点，你自己的，或你黑下来的。上面整一个applet标签，然后引用你刚才的图片。
现在应该看明白了，原来这是一个类似跨域的问题，那么为什么会有这个问题呢？原因在于applet这个标签，因为applet标签是不怎么计较文件格式的，所以任意文件格式他都当作jar来执行，也不判断文件头，只要内容里有jar就行。
在codebase里引用了url后:
The Java browser plugin sees a codebase URL of the target site and consequently adds a allowing the applet to connect back to it and make full requests.
几乎就能干任意事情了，而最要命的是，applet在连接target的时候会自动调用浏览器保存的cookie，所以这个时候baidu的cookie就危险啦~~
It turns out that when an applet makes an HTTP request to a website the Java browser plugin will slap on the relevant cookies from the browser cookie store (even if the applet is unsigned).
这个漏洞现在很清楚了，就应该是这么利用的，不是像XSS一样直接攻击，而是类似跨域攻击。
至于修补方案可以从三方面考虑
首先SUN可以升级JRE，限制这种跨域连接
其次浏览器可以限制applet标签
最后，对于website来说，麻烦一点，需要扫描上传的文件内容。
实际上回到我昨天写的关于设计安全的文件上传的文章上来，其中
第三点：使用独立的域名作为上传文件的域名
就起到的很重要的作用，就算由于上传文件的问题导致被跨域，也只能拿到该文件服务器的域下的cookie，从而降低了风险。
不过也可以看出，这个漏洞猥琐归猥琐，还确实是非常严重的！