xss编码-浏览器解析原理
在IE中,HTML本身的渲染是由mshtml.dll
来解释生成对象并展示出来的,而JS的代码会交给Jscript9.dll去解释执行。大家可以参考MVC结构,模型就是HTML中定义得那些元素,View就是我们看到得输入框、超链接的样子(可理解为style),这些都是在mshtml.dll中在匹配、分析、生成的,而Control就由Jscript9.DLL
来完成,所以JS引擎不过就是把生成的模型和View按照树形组织并管理起来。
日常中引起执行JS代码的场景:
1 | 1 <script> |
那么在执行时,mshtml.dll到底把值字符串到底以什么形式传给jscript9.dll去解释执行的呢?在IE中,所有Javascript代码编译均由jscript9!ScriptEngine::DefaultCompile函数编译,此函数断下时,esp+4的值即指向由mshtml传过来的JS代码字符串。
- 对于script标签定义的JS,可以泛理解为IE会直接产生script对象,之后把innerHTML,也就是JS代码内容直接原封不动传给JS引擎去解释执行。
- 在javascript伪协议形式,全部字符串可以是任意的URL编码和实体字符。
- 在事件类型中,JS代码并不是直接解释直接,而是被封装成了一个名为onclick的function,参数是event,函数体即用户代码。查看字符串,可看到只有实体字符被还原解码,其他均无处理。可得出结论:在事件触发的情况下,只有实体字符是亲儿子,只认识解码实体字符。
最终结论就是:在IE解析HTML时,只对所有实体编码做出解码,在解析URL时,会解码URL编码,script标签时,原始文本均不做处理!
下面摘自网络的一段XSS姿势。我们结合分析结论做出解释
1 | [ ](javascript:alert(2)) |
浏览器在拿到URL后,全字符串做URL解码,会得到javascript:开头的字符串 | Y |
---|---|---|---|
2 | `` | 同上 | N |
3 | `` | 现浏览器只认<,这里根本没有在文本里扫描到<,故根本就不是对象,不产生IMG元素 | N |
4 | <script>alert(5)</script> |
只扫描到了textarea类型,产生了textarea,其余字符串只是作为值字符串,值里含有<字符。 | N |
5 | <script>alert(6)</script> |
探测到了textarea对象的定义,故成对匹配出来中间的内容作为了属性来看待。 | N |
高级部分
6 | Button |
一切值原始文本均会做出实体解码。 | Y |
---|---|---|---|
7 | Button |
事件触发情形,只解码实体编码 | N |
8 | alert(9); |
在script标签里,原封不动交给js引擎。 | N |
9 | \u0061\u006c\u0065\u0072\u0074(10); |
在script标签里,原封不动交给js引擎。之后涉及JS引擎对字符串的解码。不做详细讨论。 | Y |
10 | \u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029 |
同上 | N |
11 | \u0061\u006c\u0065\u0072\u0074(\u0031\u0032) |
同9 | N |
12 | alert('13\u0027) |
同9 | N |
13 | alert('14\u000a') |
同9,稍微提一下,JS引擎解析也是查找调用(函数)的过程。不做详细讨论 | Y |
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Rick!
评论