浏览器差异带来的XSS风险1

解析顺序问题
其实哪都一样,不一定是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

3 comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注