document.domain<br>
为了解决不同源数据传输问题
允许两个拥有相同二级域名的相关网站，<br>协商认可彼此的同源检查
domain的修改策略
可以设置成非顶级域名，如qq.com,但是不能设置为com
那是否可以设置国家级域名，如aaa.sina.com.cn，是否可以设置为com.cn，那整个<br>国家都是我的了，<b>真是个机灵鬼，</b>答案是com.cn也算顶级域名，但是这里不同的<br>浏览数实现上就出现了混乱<br>
如：对http://a.qq.com/aa/a.php和http://b.qq.com/aa/a.php<br>进行document.domain="qq.com"则，两个页面具有了相同的源<br>
注意：设置了domain的页面不能访问未设置domain的页面,反之亦然<br>http://a.qq.com->domain='qq.com'，访问http://qq.com->domain未设置，访问失败<br>http://a.qq.com->domain未设置，访问http://a.qq.com->domain='qq.com'，访问失败<br>http://a.qq.com->domain未设置，访问http://a.qq.com->domain='a.qq.com'，访问失败 <br><br>
产生的思考
不同二级域名(如：qq.com和baidu.com)之间的页面怎么传输消息
产生的安全问题
任何子域的安全问题（主要是XSS漏洞），将影响其他设置了domain的页面<br><br>
如果http://mail.qq.com/a.html->domain='qq.com'<br>那么http://b.a.qq.com域下任意一个xss漏洞将导致跨域数据获取问题
<b>攻击方式：</b>攻击者自己的页面http://www.attack.com通过iframe嵌入存在xss漏洞的页面，<br>设置http://b.a.qq.com->domain='qq.com',再iframe目标页面http://mail.qq.com/a.html<br>通过contentDocument进行<b>DOM操作</b>
self-xss，代码回注，变废为宝，XSS后门
window.postMessage
为了解决不同二级域名之间页面数据传输问题
前提需要获取目标页面句柄
parent.window.postMessage
opener.window.postMessage
.....
window.onmessage监听<br>
onmessage=function(e){e.orgin,e.data}
orgin：发送方的源
data：接收到的数据
window.postMessage发送
postMessage(message, targetOrigin)
message：发送的数据
targetOrigin：设置接收方的源
遵循同源策略，但是不受window.domain影响
产生的安全问题
onmessage端的问题
origin判断错误，或者没有判断，导致数据污染，从而产生其他问题<br>如：直接eval(data)
<b>攻击方式</b>
postMessage端的问题
如：orgin设置为*，导致获取敏感信息
<b>攻击方式</b>
Ajax跨域
ajax 主要是实现页面和 web 服务器之间数据的异步传输
通过XMLHttpRequest对象与远程的服务器进行信息交互,并且受同源策略约束，<br>但是不受document.domain的影响<br>
跨域资源共享<br>（CORS，Cross-origin resource sharing）<br>
Access-Control-Allow-Origin
可以设置为*，设置*是最简单粗暴的，<br>但是出于安全考虑，如果是*的话，<br>游览器将不会发送cookies，即使你的XHR<br>设置了withCredentials<br>
withCredentials
默认为false
默认不会发送cookie也不会响应set-cookie头
document.cookie
基本特性
浏览器发送cookie不管请求来源（document.referrer）
COOKIE的出现早于同源策略，因此浏览器实现中会有很多问题
关于document.referrer可以单独出个专题
a.qq.com的<br>Cookie的设置<br>
domain属性
Cookie域是指服务端返回头：set-cookie头设置的域,或者js设置的域
完全未设置，精确匹配a.qq.com
设置为aa.a.qq.com,设置不成功
设置为a.qq.com，匹配*.a.qq.com
设置为qq.com，匹配*.qq.com
设置为baidu.com，设置不成功
path属性
设置配aa/a.html，必须匹配aa/a.html才会发送cookie
http-only属性
javascript不可读取cookie
Secure属性
https页面才允许发送cookie
产生的安全问题
CSRF（Cross Site Request Forgery）
跨站点请求伪造，本质也是跨域问题，<br>这个可以单独出一个专题，这里不展开<br>
DNS劫持之https-cookie偷取，本质也是跨域问题，可以单独出个专题，这里不展开
javascript跨域获取cookie
本质是document.domain的攻击方式，<br>需要注意Cookie的domain与path的匹配规则<br>
proxy.html
domain='qq.com'，很多网站提供的proxy页面
cookie作为认证机制，能获取cookie就等同于绕过同源策略了
cookie覆盖之Self-XSS
localhost.yahoo.com这种指向127.0.0.1的域名带来的安全问题
cookie与<b>“合法”DNS劫持（运营商劫持）</b>带来的问题，可以单独开专题，这里不展开
window.localStorage
在浏览器实现了一种简单的数据库
localStorage,关闭浏览器之后仍然有效
sessionStorage,浏览器会话结束后会被清理
遵循同源策略,但是不受document.domain的影响
产生的安全问题
XSS后门攻击，这个可以单独出个专题，这里不展开
