作者：空虚浪子心【XGC】

　　【IT168专稿】引言

　　因为一个0day，让作者对java applet心血来潮，随着不断的失败，发现了一个又一个安全特性。本文提醒大家，除了activeX，还有这么一种东西，一旦出现了安全隐患，也会帮大家做些什么。如果你要找“0DAY”，请掠过;如果你要找“如何使用APPLET下载木马”，请看下集;如果你喜欢研究“applet可能存在的安全隐患 ”，请从这里开始。

　　第一部分 一个“0day”狂想

　　最近常听见有朋友说“只有跨站执行脚本才是王道”，但是我想，每一门艺术(技术)，都有自己的独到的美(特性)，就像后门除了使用“特洛伊”，还有可以用很多微小的途径，拼合起来，就可能达到比它更加完美的效果。

　　论坛上某帖发出一篇通杀FF和IE的0DAY代码：

　　说实话，刚拿到代码时很兴奋，看起来只要用户只要浏览applet的页面，就可以自动执行JAVA(applet)，在用户的机器上乱写乱画。这是多么美妙的事情啊，只要用户装了jre，就完蛋了。于是跟贴发表评论，解读这段代码的含义，甚至还发表了改进的看法。但是等朋友让我写出改进的代码，才在不断的实践中发现自己的回帖完全是纸上谈兵。

　　Java applet可以用来点缀html的页面，让它更加花哨，更加吸引MM的目光。某种程度上，它和微软的activeX是一个级别的，都是用来扩展HTML 效果。如果搜索“java applet”，可能会搜索到《java applet向activeX下跪》这篇文章，applet曾经风光一时，后来被微软的activeX垄断。但是毕竟功能还在，也就是说，值得探究的安全性因素还在。虽然必须要安装JRE环境才可以执行，但是毕竟可以“祸害一部分人”，随着sun的“进一步战略”，也许这个家伙有一天还会冒出来。

　　在网上找了applet安全的文章，也就那么可怜兮兮的几篇。大概内容都是先列举了他的写文件代码，然后告诉读者这些危险动作默认是不可做的，只有用户同意了安全证书，才会在用户的policy里加入“读，写，执行”等权限。但是你如果真的在问用户“嘿!哥们儿，咱有个东西，你先点同意，同意我在哥们儿脸上写点东西，同意我看看哥们儿暗恋的MM，同意我控制哥们儿几天，同意。。。。”。作者没那么深的钓鱼功力让用户签订不平等条约，所以，本文就不探讨当用户签订安全证书后发生的安全隐患了，因为那真的等于让用户使用最高权限执行一段不可预知的代码。

　　要研究applet的安全，首先要打开浏览器(IE，FF)，工具--?SUN java控制台，右下角会出现冒火的咖啡，右键选择“打开控制面板”，打开“高级”选项卡，选中“调试”里的勾。

　　选择之后，在每次浏览applet页面时，会看到控制台上会出现每一步的程序执行信息，便于我们知道发生的异常和程序运行结果。

　　回头看看这段“0day”代码的执行，我为什么会说“纸上谈兵”呢？分析“0day”的执行顺序：“新建文件--利用HTTP协议取文件--把取得的文件内容写入新建的文件--执行该文件”。好哇！整个就是一个下载者经典流程。看看我们执行后的控制台信息吧。

　　执行过程很明确，打印出了“aaa”，说明代码执行进入了start方法里。Applet的执行顺序为“初始化类(构造方法)--调用init 方法—调用start方法--。。。。。”，你可以认为只要代码写在start里，就会执行。这些都是由浏览器执行的，我们的找茬范围，就是当浏览器执行这些代码的同时：有没有忽略什么、还能做什么、在做什么的同时会不会触发什么。看这里的信息，并没有去那个URL地址拿EXE文件，反而到了aaa就结束了，是因为程序里抓了异常，但是故意不做处理。修改代码，打印异常信息到控制台。继续执行。

　　除了上面的信息外，又打印了

　　原来，在执行

时，发生了安全异常，不允许新建文件“C:\windows\system32\Client.exe”。好了，连这个新建文件的权限都没有，还谈什么去执行它。很显然，这段代码单纯的执行并不能达到“0day”的效果，可能有些触发条件没有被贴出来吧，它只能算是一段shellcode罢了。 “0day”梦想暂时结束。那，不能新建文件也可以，如果能把用户个人电脑的文件偷偷发出去，也是个不错的选择。

　　第二部分 尝试操作文件

　　所谓的危险性操作，在applet的执行环境下可能发生的有：

　　读文件

　　写文件

　　执行

　　跨域取东西

　　跨域通知

　　跨域建立socket链接

　　调用外部引擎(JDBC等)

　　调用APPLET外的JAVA代码

　　控制浏览器做一些不合理动作

　　等等。

　　发用户机器上的文件给某人，不错的想法，但是这里涉及两个基本权限：读文件，上传文件。上一篇里，因为权限问题，写文件的时候断电了。试想毕竟是JAVA，一门庞大的语言，真的无懈可击么?这次我们读个东西试试。

　　Start代码：

　　控制台打印出：

　　不能读文件，连最基本的“判断文件是否存在”都过不去。
　　读都不行，更别说执行了？

　　控制台打印出：

　　不能执行，文件相关操作都控制的死死的。好吧，我不奢求直接用java控制文件了。记得在玩注入时，可以调用ACCESS等数据库的引擎去写文件。如果可以在applet中访问数据库，那有意思了，一样可以做些什么。间接访问文件，只要没有控制applet访问JDBC驱动的权限，就能执行sql。

　　再看看结果：

　　又是失败，也就是说，applet控制了访问其他packet中的内容，只准访问自己内定的包，外部驱动不能用。我所知道的方法基本上都测试了，或许还有，但是这个层面上，最具代表性的都试了，其他的（跨域发送socket包等等）就不拿出来一一说明了。

　　第三部分 对浏览器的操作

　　几天前看到一篇文章，提到“鬼域”，也就是“鬼页”。文中提到可以控制子窗口内部FRAME，IE6可以控制子窗口执行JS，但是IE7，FF不能做。那么用applet来执行的结果，和这篇文章的内容对比，可以多做些什么，而又不能实现什么呢?

　　netscape.javascript.JSObject类可以在applet中调用JS，该类是个抽象类。这个类构造方法是protected的，也就是说，不能直接new出来，只能由子类new，调用其中的静态方法“getWindow(Applet applet)”返回它的一个实例。通常我们使用的时候，这样的设计，就限制了必须要有个applet执行时才可以实例化这个类，也就是当浏览器加载 applet时才可以实例化JSObject。其中的eval方法顾名思义是执行js代码的，applet都能做，只是在页面上看不到JS代码而已，当然，在js中也可以调用applet的方法。这就有个安全隐患了，如果程序仅仅限制了<script>标签，那么使用applet，一样可以达到绕过限制调用JS。当然如果直接限制了“<”，那也没辙。

　　下面是一般调用applet的html代码：

　　只要贴在HTML页面，就能执行applet，CLASS文件是applet小程序的代码，如果用户浏览器不支持JVM虚拟机，会打出中间的信息。

　　为了探究applet的安全性，本文拿那篇“浅析浏览器的跨域安全问题”一文的内容（没看过的自己去百度，如果不看该文，下面的内容会很生涩），来做个问题的模板，用applet来实现文中提到的一些技术，并对比一下和JS的安全性差异。

　　首先是“伪协议”问题
　　引用文章内容：

　　这段代码取得子窗体的域，如果两个HTML文件在同一个域，就可以做很多事情，比如用“AJAX”技术把该页面的敏感信息提交到另一个页面，并且只有同域下的iframe才可以控制父页面。如下面这段JS，只能在同域下的iframe中执行。

　　为了做对比，使用Applet来实现伪协议的效果：

　　这段代码第一行会弹出新的窗口，窗口名称为“kxlzx”（在程序中可以使用“kxlzx”访问弹出的窗口），第二行会在“kxlzx”这个窗口中继续显示"javascript:alert(document.domain)"。访问页面 http://192.168.0.3/test.htm，IE7和FF都弹出了“192.168.0.3”。请注意，这种情况发生在“当前页面和弹出页面都在同一个域”下。

　　父页和子页的关系

　　引用“浅析浏览器的跨域安全问题”一文的代码：

再次使用applet实现以上效果：

IE和FF都执行成功，子窗口先访问了sohu，过5秒，访问了sina，子页将永远受制于父页。

　　域与域之间的牵绊

　　那么不同域会出现什么情况呢？

　　这段代码和前面第一节部分唯一的差别是，打开了http://192.168.0.3/test2.htm（父窗体）页面后，父窗体的applet控制子窗体访问到了另一个域“192.168.0.2”中。执行结果，IE拒绝访问，FF却弹出了

　　奇怪，分明是让子窗体去访问"javascript:alert(document.domain)"，怎么会弹出父窗体的域名呢？更诡异的是，弹出框的title上居然写着 “来自192.168.0.3的页面说：”。猜测这个问题有两种可能：

　　1、子窗口（http://192.168.0.2/php.php）仍然认为自己属于父窗体的域（192.168.0.3）。

　　2、这个框（JS）根本就是由父窗体调出来的。

　　为了证明域的问题，我写了段JS来判断，在子窗体的页面中，写段AJAX，让他去给父窗体送点东西。如果同一个域，就能拿，如果不同域会拒绝访问。

　　几经测试，写出了可以通过的代码：

　　请注意变红的地方！代码会先控制子窗体打开页面，然后控制子窗体执行一段ajax代码访问a.asp。a.asp文件的作用是接收 context变量，然后把它的值保存在本地一个kxlzx.txt的文件里。从kxlzx.txt文件内容来看，执行成功了。也就是说，这段ajax成功的访问了位于192.168.0.3上的文件a.asp，并提交了参数。

　　这时的我非常兴奋！跨域“0day”？！！别高兴的太早，还有种可能就是父窗口执行了ajax。为了进一步扩大战果和分辨父子窗体，我立刻修改js，让他把cookie传过去，修改代码中传递参数的值为 “a.asp?context=aa'+document.cookie+document.getElementById(‘who’)”。然后修改子窗体访问的php.php：

　　再修改父窗体访问的页面(加载applet的页面test2.htm)：

　　这两段有什么用呢？首先是cookie问题，如果单纯靠两个页的cookie判断，可能达不到效果，别忘了他们的域是一样的，很可能两个页面cookie都是test2.htm的cookie。但是再加个input就不一样了，input的值可不会因为域而改变。

　　这样，不同的页面所调用ajax的结果就有所区别。测试结果很诡异，我在kxlzx.txt中只找到了test2.htm的cookie，没有后面紧跟的input的值。两个页面都有input，怎么会拿不到值？打开ff的错误控制台，看到了如下错误：

　　执行这段js的页面根本就没有这个input！两种解释：

　　1、还有个页面偷偷执行了这段ajax，然后消失的无影无踪。

　　2、这段JS在第二个页面（子窗体）中执行，但是执行的时候子窗体还没有访问php.php。

　　至少不可能是test2.htm执行了js，如果他执行js，一定能拿到“who”的值，input在applet之前就加载了。无论是哪种可能，跨域 0day梦，宣告结束。父窗体不能让子窗体执行脚本，只能让他访问一些页面。好吧，你狠！不过，我们回到一个话题来：“为什么要让子窗体执行脚本？”，很显然，我们想要子窗体的cookie。

　　整理思路：
　　1、父窗体可以控制子窗体到处访问。

　　2、父窗体不能让子窗体执行脚本。

　　3、我们想拿子窗体的cookie。

　　4、只有同一个域下，才能取cookie。

　　你应该感到有趣才是，因为作者不可能把一段废话一一列举在这里，你能想到什么呢？公布答案！假设我们能控制父窗体的代码，想要子窗体的cookie步骤：

　　1、我们可爱的IE浏览器打开/Article/UploadFiles/200808/20080808105155534.jpg时，如果jpg里面其实是js，发生什么？很好！会执行JS！步骤一的关键就是，往子窗口的域名下（网站），传一个jpg文件，里面是JS代码。Js代码用来：获取cookie，然后使用AJAX 技术将cookie提交到同一个域的某个能储存东西的地方，比如留言本。

　　2、既然要获取cookie，那浏览器至少要有子窗体的cookie，比如他登录过就会有cookie。让父窗体先打开子窗体的kxlzx.jpg，一秒，闪一秒就足够代码执行了，之后的事情就不用我说了。

　　如果步骤一的条件有出入，没有可以储存东西的地方，你可以尝试以下代码绕过AJAX的跨域限制：

　　以上步骤不仅仅可以应用于applet，还可以在js中实现。可以实现以上步骤的代码，本文已经写的够多了，请在楼上找吧。

　　作者技术有限，目前研究到这里，给大家个研究方向：往applet底层实现进发，研究能绕过applet权限的函数，去年就出了一个。实践出真知，作者的研究思路一定不是最好的，甚至文中或许还会有错误，但是文中代码都是作者通过无数次实践，才精挑细选出了最能说明问题的部分，希望能对大家有所帮助。

　　最后发几个小技巧：
　　1、跨域调用class文件。突破XSS的时候，如果不能上传class文件（通常都不可以），就可以把class文件放在其他地方。把class文件放在其他服务器上调用，有了这个功能，更利于我们没有限制的跨域调用class文件。

　　2、调试的时候，如果编译好了class文件，之后修改类，又重新编译了class文件，一定要关闭浏览器重新打开，才能看到新的效果。因为浏览器有缓存，同样会缓存class文件，如果不清空缓存或重新打开浏览器，就等于使用了原来的class文件。

　　3、调试的时候，一定要仔细考虑到整个流程执行顺序，特别是当你以为自己不小心发现“0day”的时候。

　　4、最后提醒，applet只能执行在JVM环境中。
　　参考文献：
　　《浅析浏览器的跨域安全问题》 Ph4nt0m Security Team  rayh4c
　　《Java security evolution and concepts, Part 3: Applet security》 Raghavan N. Srinivas
　　《Applet Security》 SUN官方
　　《Java 2 Applet Security》 Abdul Habra, 2.7.2000
　　《JDK帮助》

　　附件说明：
　　a.asp -------    接收变量，保存内容为kxlzx.txt的页面
　　Applet_ODBC.java  -------- 使用applet链接access数据库的代码
　　Applet_Control_Open.java -------- 父窗体控制子窗体到处访问的代码
　　Oday.java ----------  第一部分提到的0day
　　ReadFile.java  --------  applet读文件
　　writeFile.java  ---------  applet写文件
　　Xss.java  -----  控制子窗口弹cookie
　　test2.htm  ------  文中提到的加载applet页面
　　php.php  -----  没有这个文件，因为它代码改来改去的，文中找吧。

文中提到的附件下载地址：

http://www.inbreak.net/attachment.php?id=5