原型链的总结

目录

1、什么是原型链

2、prototype和__proto__分别是什么？

3、XSS

3.1 XSS解码

3.2 URL解码

3.3 JavaScript 解析

3.4 解析流

---

1、什么是原型链

原型链通俗易懂的理解就是可以把它想象成一个链条，互相连接构成一整串链子！
而原型链中就是实例对象和原型对象之间的链接。每个函数都有一个prototype属性，这个prototype属性就是我们的原型对象，我们拿这个函数通过new构造函数创建出来的实例对象，这个实例对象自己会有一个指针(_proto_)指向他的构造函数的原型对象！这样构造函数和实例对象之间就通过( _proto_ )连接在一起形成了一条链子。

2、prototype和__proto__分别是什么？

每个实例对象下都有__proto__属性，通过属性__proto__指向构造函数的原型对象，当到达末端时，返回null，这样一层一层向顶端查找，就形成了原型链。

prototype是函数特有的，__proto__是对象有的，js中万物皆对象

prototype把共有属性预先定义好，给之后对象使用

prototype的存在实现了继承，节省内存空间

__proto__对象原型的意义就在于为对象的查找机制提供一个方向，或者说一条路线，但是它是一个非标准属性，因此实际开发中，不可以使用这个属性，它只是内部指向原型对象 prototype

一般情况下，对象的方法都在构造函数的原型对象中设置。如果有多个对象的方法，我们可以给原型对象采取对象形式赋值，但是这样就会覆盖构造函数原型对象原来的内容，这样修改后的原型对象 constructor 就不再指向当前构造函数了。此时，我们可以在修改后的原型对象中，添加一个 constructor 指向原来的构造函数。

3、XSS

3.1 XSS解码

1.<a href="%6a%61%76%61%73%63%72%69%70%74:%61%6c%65%72%74%28%31%29">aaa</a>

a标签中的href属性放的是url，然后现在里面全是url编码，URL模块解码出来就是javascript:alert(1),因为是url解码后才能看到javascript所以最后没识别到这个协议，即alert没被执行

2.<a href="&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;:%61%6c%65%72%74%28%32%29">aaa</a>

先通过HTML解码得到javascript:%61%6c%65%72%74%28%32%29，再丢给URL模块，URL模块识别到Javascript协议，把：后边的内容解码后丢给js的模块去处理

3.<a href="javascript%3aalert(3)"></a>

URL要识别到完整的javascript:才会执行，即这个执行失败

4.<div>&#60;img src=x onerror=alert(4)&#62;</div>

当遇到&#60的时候，它会解码‘<’,但是不会进入标签开始状态，就不会解析里面的内容

5.<textarea>&#60;script&#62;alert(5)&#60;/script&#62;</textarea>

在“<textarea>”和“<title>”的内容中不会创建标签，就不会有脚本能够执行

3.2 URL解码

URL解析器也是一个状态机模型，从输入流中进来的字符可以引导URL解析器转换到不同的状态。解析器的解析细则在这里。其中有很多有关安全或XSS转义的内容。

首先，URL资源类型必须是ASCII字母（U+0041-U+005A || U+0061-U+007A），不然就会进入“无类型”状态。例如，你不能对协议类型进行任何的编码操作，不然URL解析器会认为它无类型。这就是为什么问题1中的代码不能被执行。因为URL中被编码的“javascript”没有被解码，因此不会被URL解析器识别。该原则对协议后面的“：”（冒号）同样适用，即问题3也得到解答。然而，你可能会想到：为什么问题2中的脚本被执行了呢？如果你记得我们在HTML解析部分讨论的内容的话，是否还记得有一个情况叫做“属性值中的字符引用”，在这个情况中字符引用会被解码。我们将稍后讨论解析顺序，但在这里，HTML解析器解析了文档，创建了标签token，并且对href属性里的字符实体进行了解码。然后，当HTML解析器工作完成后，URL解析器开始解析href属性值里的链接。在这时，“javascript”协议已经被解码，它能够被URL解析器正确识别。然后URL解析器继续解析链接剩下的部分。

3.3 JavaScript 解析

JavaScript解析过程与HTML解析过程有点不一样。JavaScript语言是一门内容无关语言。对应着有一份内容无关的语法来描述它。我们可以利用内容无关语法来解释JavaScript是如何解析的.

开始之前，让我们来回到HTML解析过程中的“原始文本”元素。我故意将HTML中的一部分留到这个章节是因为它与JavaScript解析有关。所有的“script”块都属于“原始文本”元素。“script”块有个有趣的属性：在块中的字符引用并不会被解析和解码。如果你去看“脚本数据状态”的状态转换规则，就会发现没有任何规则能转移到字符引用状态。这意味着什么？所以如果攻击者尝试着将输入数据编码成字符实体并将其放在script块中，它将不会被执行。

 “ECMAScript 与 JAVA 编程语言在对待Unicode转义序列时的行为不同。在Java程序中，如果Unicode转义序列\u000A出现在单行字符串注释中，它会被解释为行结束符（换行符），因此会导致接下来的Unicode字符不是注释的一部分。同样的，如果Unicode转义序列\u000A出现在Java程序的字符串常量中，它同样会被解释为行结束符（换行符），这在字符串常量中是不被允许的——如果需要在字符串常量中表示换行，需要用\n来代替\u000A。在ECMAScript程序中，出现在注释中的Unicode转义序列永远不会被解释，因此不会导致注释换行问题。同样地，ECMAScript程序中，在字符串常量中出现的Unicode转义序列会被当作字符串常量中的一个Unicode字符，并且不会被解释成有可能结束字符串常量的换行符或者引号。”

3.4 解析流

Example A: <a href="UserInput"></a>
Example B: <a href=#   οnclick="window.open('UserInput')"></a>

在例A中，HTML解析器将首先开始工作，并对UserInput中的字符引用进行解码。然后URL解析器开始对href值进行URL解码。最后，如果URL资源类型是JavaScript，那么JavaScript解析器会进行Unicode转义序列和Hex转义序列的解码。再之后，解码的脚本会被执行。

在例B中，HTML解析器首先工作。然而接下来，JavaScript解析器开始解析在onclick事件处理器中的值。这是因为在onclick事件处理器中是script的上下文。当这段JavaScript被解析并被执行的时候，它执行的是“window.open()”操作，其中的参数是URL的上下文。在此时，URL解析器开始对UserInput进行URL解码并把结果回传给JavaScript引擎。因此这里一共涉及三轮解码，顺序是HTML，JavaScript和URL。