解析顺序问题
其实哪都一样，不一定是web世界，前后端解释型语言，还有HTTP头部等。都有个解析顺序的问题，从上到下，从左到右，从右到左。一旦顺序能被干扰，就有可能出现安全问题。比如字符集编码问题、content-type问题、标签属性type问题等等。

随便说两句跑题的，下面才是正文:)

一些标准实现差异问题
浏览器们都想独霸世界，有些标准的实现各行其道，导致总是会出现些差异。如果程序员没意识到这些差异，可能就会引入安全隐患。这部分很多。最近发现浏览器们对这个地址的解析差异：
http://www.0x37.com:8989/test.php?c='”`<>!@$%^*(){}[]:;.,?~

发送请求时，抓包发现，浏览器们的默认行为：
FireFox
GET /test.php?c=%27%22%60%3C%3E!@$%^*(){}[]:;.,?~ HTTP/1.1
Chrome
GET /test.php?c=’%22`%3C%3E!@$%^*(){}[]:;.,?~ HTTP/1.1
IE内核
GET /test.php?c='”`<>!@$%^*(){}[]:;.,?~ HTTP/1.1

发现有什么不一样了？最近我们的扫描器发现了一些主流团购网的XSS，分析时发现了这个，这个差异导致XSS在有的浏览器可以成功，有的却失败，由于XX原因，案例不能给出。不过有经验的人一看，估计会怀疑，因为%27这些只是urlencode而已，正常输出的话还是urlencode前的原始字符。所以我怀疑这个差异不应该都怪罪到浏览器身上，应该还与这些团购网的具体代码设计有关系。

还有一个字符集的差异
http://www.0x37.com:8989/test.php?c=你好
页面默认编码为utf-8

发送请求时，抓包发现，浏览器们的默认行为：
FireFox
GET /test.php?c=%C4%E3%BA%C3 HTTP/1.1
双字节编码，为什么FF会选择这个？
Chrome
GET /test.php?c=%E4%BD%A0%E5%A5%BD HTTP/1.1
这是utf-8，urlencode的最直接表现。
IE
GET /test.php?c=你好 HTTP/1.1
没做任何编码，IE奇怪的很。

今天pan同学发现某团购网的这个XSS时，也很奇怪为什么XSS只在Chrome上有效，原来Chrome在这个场景中处理中文是走utf-8路线，满足目标网站。又是团购网。。

都是比较神奇的XSS。困~还在加班奋战中，所以写的有点乱，大家将就看吧。:P