浅谈Javascript函数劫持(1)(2)
3、实现DOM XSS自动化扫描,目前一般的XSS自动化扫描的方法是从http返回结果中搜索特征来确定是否存在漏洞,但是这种方法不适用于扫描DOM XSS,因为DOM XSS是由客户端脚本造成的,比如前段时间剑心发现的google的跨站(见附录[2])原理如下:
|
这样的跨站无法反映在http response里,所以传统扫描方法没法扫描出来。但是如果你从上个例子里受到启发的话,一定会想到设置陷阱的办法,DOM XSS最终导致alert被执行,所以我们hook alert函数设置陷阱,如果XSS成功则会去调用alert函数,触发我们的陷阱记录结果,这样就可以实现DOM XSS的自动化扫描,陷阱代码类似于上面。
4、灵活的使用js劫持辅助你的页面代码分析工作,比如分析网页木马时,经常会有通过eval或者document.write来进行加密的情况,于是我们编写段hook eval和document.write的小工具,辅助解密:
|
在input框里输入加密的代码:
|
在output框里输出解码后的代码:
|
当然你还能想到更多的灵活应用:)
三、反劫持
谈到劫持也就必然要谈谈反劫持的话题,假设你要写一个健壮的xss playload,就需要考虑反劫持,有两个问题要解决:
◆如何判断是否被劫持了?
◆如果发现被劫持了,如何反劫持?
1、判断某个函数是否被劫持,这个好办,写个小程序对比一下一个函数被hook前后,有什么差别:
|
结果:
|
我们发现那些内置函数是[native code],而自定义的则是具体的函数定义,用这个特征就可以简单的检测函数是否被劫持:
|
2、如何反劫持,第一个想法就是恢复被劫持的函数,如果劫持的人把原函数保存在某个变量里那还好办,直接调用原函数就可以了,但是劫持者自己也没保存副本怎么办,只能自己创建个新的环境,然后用新环境里的干净的函数来恢复我们这里被hook了的,怎么创建新环境?整个新的iframe好了,里面就是个全新的环境。ok,动手吧!
|
3、不是上面两个问题都解决了吗,为什么要有第3节?因为那不是个最好的解决办法,既然我们可以创建全新的iframe,何不把代码直接放到全新iframe里执行呢,这样做的话绿色环保,既不用考虑当前context里的hook问题,也不用改动当前context,不会影响本身的程序执行。给出两个比较通用点的函数:
|
把你的payload封装进一个函数,然后调用这两个方法来在iframe里执行:
|
四、最后
由于国内很少有见文章提及这个东西,所以才草成这篇,希望能够抛砖引玉。由于本人水平有限,难免有错误或者疏漏之处请谅解,没有说清楚的地方,欢迎和我交流。