这篇文章介绍xss攻击相关补充知识。
同源
1995年，同源政策由 Netscape公司引入浏览器。目前，所有浏览器都实行这个政策。最初，它的含义是指，A网页设置的 Cookis，B网页不能打开，除非这两个网页”同源”
所谓“同源”指的是“三个相同”：
协议相同、域名相同、端口相同
看看示例来小试牛刀
同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。
设想这样一种情况：A网站是一家银行，用户登录以后，又去浏览其他网站。如果其他网站可以读取A网站的 Cookie，会发生什么？
很显然，如果 Cookie包含隐私（比如存款总额），这些信息就会泄漏。更可怕的是Cookie往往用来保存用户的登录状态，如果用户没有退出登录，其他网站就可以冒充用户，为所欲为。因为浏览器同时还规定，提交表单不受同源政策的限制。
由此可见，”同源政策”是必需的，否则 Cookie可以共享，互联网就毫无安全可言了。
随着互联网的发展，”同源政策” 越来越严格。目前，如果非同源，共有三种行为受到限制。
（1）Cookie、 LocalStorage 和 IndexDB 无法读取。
（2）DOM无法获得。
（3）AJAX请求不能发送。
当然，这些条件都是相对的，在某些特殊的情况下，我们也可以通过同源策略所允许的共享机制，完成非同源页面之间数据的传送。
跨域
所谓跨域，或者异源，是指主机名（域名）、协议、端口号 只要有其一不同，就为不同的域（或源）。浏览器中有一个基本的策略，叫同源策略，即限制”源”自A的脚本只能操作“同源”页面的DOM。 浏览器中，< script>//< iframe>/等标签都是可以跨域来加载资源的而不受同源策略的影响。带″src′属性的标签每次加载时，实际上都是浏览器发起次”GET”请求。
对于 XMLHttpRequest来说，它可以访问来自同源对象的内容。但是不能够跨域访问资源。他需要通过目标域返回的HTTP头授权是否允许跨域访问，因为HTTP头对于 javascript来说一般是无法控制的，所以认为这个方案是可行的。
对于浏览器来说：除了DOM、Cookie、XMLTttpRequest会受到同源策略的限制外，浏览器加载的第三方插件也有各自的同源策略。例如：flash,java applet, silverlight, coogle gears等。
跨域的方法
JSONP
JSONP跨城
JSONP劫持
(1）用户在网站B注册并登录，网站B包含了用户的d,name,emai等信息
(2）用户通过浏览器向网站A发出URL请求
(3）网站A向用户返回响应页面，响应页面中注册了 JavaScript的回调函数和向网站B请求的 script标签，示例代码如下`
(4）用户收到响应，解析JS代码，将回调函数作为参数向网站B发岀请求； (5）网站B接收到请求后，解析请求的URL，以SON格式生成请求需要的数据，将封装的包含用户信息的JSON数据作为回调函数的参数返回给浏览器，网站B返回的数据实例如下：Callback(){id”：l，”name”：test”，”email”：testatest com”})(6）网站B数据返回后，浏览器则自动执行 Callback函数对步骤4返回的JSON格式数据进行处理，通过alert 弹窗展示了用户在网站B的注册信息。另外也可将JSON数据回传到网站A的服务器，这样网站A利用网站B的JSONP漏洞便获取到了用户在网站B注册的信息。
CORS
CORS是一个W3C标准，全称是”跨域资源共享””（ Cross-origin resource sharing）
它允许浏览器向跨源服务器，发出 XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。 CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。
浏览器端：
目前，所有浏览器都支持该功能（IE10以下不行）。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。
服务端:
CORS通信与AJAX没有任何差别，因此你不需要改变以前的业务逻辑。只不过，浏览器会在请求中携带一些头信息，我们需要以此判断是否运行其跨域，然后在响应头中加入一些信息即可。这一般通过过滤器完成即可。
不符合简单请求的条件，会被浏览器判定为特殊请求，例如请求方式为PUT
特殊请求会在正式通信之前，增加一次HTTP查询请求，称为”预检”请求（ preflight）。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
与简单请求相比，除了 Origin以外，多了两个头
Access-Control-Request-Method：接下来会用到的请求方式，比如PUT
Access- Control- Request-Headers：会额外用到的头信息
服务的收到预检请求，如果许可跨域，会发出响应
除了 Access-Contro-Allow-Origin和Aces-Contro-Allow-Credentials以外，这里又额外多出3个头：
Access-Contro|-Allow-Methods：允许访问的方式
Access-Control- Allow- Headers：允许携带的头
Access-Control-Max-Age：本次许可的有效时长，单位是秒，过期之前的ajax请求就无需再次进行预检了
如果浏览器得到上述响应，则认定为可以跨域，后续就跟简单请求的处理是一样的
PostMessage跨城
SameSite
Chrome51开始，浏览器的 Cookie新增加了—个 SameSite属性，用来防止CSRF攻击和用户追踪。
Cookie的 Samesite属性用来限制第三方 Cookie，从而减少安全风险。它可以设置个值 Strict 、 Lax、 None
Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送Cookie。换言之，只有当前网页的URL与请求目标—致，才会带上 Cookie。
Set-Cookie:CookieName=CookieValue:SameSite=Strict;
这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub链接，用户点击跳转就不会带有 GitHub的 Cookie，跳转过去总是未登陆状态。
Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的Get请求除外。
Set-Cookie:CookieName=CookieValue;SameSite=Lax
导航到目标网址的GET请求，只包括三种情况：链接，预加载请求，GET表单。详见下表。
Chrome计划将Lax变为默认设置。这时，网站可以选择显式关闭 SameSite属性将其设为None。不过，前提是必须同时设置 Secure属性（ Cookie只能通过 Https协议发送），否则无效。
下面的设置无效:
Set-Cookie:widget_session=abc123;SameSite=None
下面的设置有效:
Set-Cookie:widget_session=abc123;SameSite=None;Secure