同一生成元策略/同源策略 Same-origin policy

在了解XSS攻击的时候遇到了 Same-origin policy的概念，日文是同一生成元Policy，中文的译法是同源策略。

Same-origin policy

这个概念的由来：因为JavaScript是世界上最不安全的语言，实际应用中肯定会对它的权限做一些限制。Same-origin policy便是限制JavaScript代码权限的一种策略，浏览器都会遵守的。

因为JavaScript太灵活，用得太乱，明明打开的是A网站，却可能有B网站的JavaScript在A的页面上运行！ 有了同源策略，可以限制来自B网站的JS代码的权限。

我的理解是，这里B网站的JS脚本实际上还是可以执行，并不是说完全不能执行。那么同源策略做了什么限制呢？查了网上的资料，好像是说“修改A网站HTML”的操作会被禁止。比如说B网站的脚本里面有document.write，想修改A网站的页面内容。而又有资料说，这种限制也可以被放宽（一个页面上显示了来自另一个网站的内容，这个确实很常见，没有被禁止）。还有的说法是，打开两个标签页，同源策略是禁止一个标签页的JS代码访问另一个标签页中的内容，这个也太扯了吧？ 总之没实际动手做过的话，很难体会。

同源策略的两个常见用途：一个是cookie，一个是XMLHttpRequest。

Cookie
B网站的脚本在A网站上面执行，可以做很多事情，可以getElementById等等，获取A网站页面上的信息。那么很自然想到，也可以获取A网站的cookie信息，这就导致用户隐私泄露了。

解决办法是，浏览器会遵守同源策略，如果B网站的脚本想获得A网站的cookie，会被浏览器拒绝执行。

所以，原理实际上很简单。很多安全漏洞，无非是浏览器说了算，浏览器让你这么干，你就可以这么干，出现漏洞，很简单，改成浏览器不让你这么干就行了。

XMLHttpRequest
即Ajax函数只能向当前页面所在域名发送请求。也就是说，iteye.com网页的Ajax代码，只能与iteye的服务器通讯，从iteye的服务器获取数据，而不能连到csdn去（浏览器会拒绝执行，发送不出这个请求）。


厂商与历史

很多安全漏洞的东西，都是一开始没发现，发现了之后才由厂商制定标准，进行修补的。同源策略便是由网景公司提出并实现。（Netscape Navigator 2.0）

后来，肯定又出现了更新颖，更先进的窃取cookie信息的方法，所以后来微软的IE 6.0浏览器又搞出来新的修补措施，就是cookie的HTTP-ONLY属性，不管你是哪个网站，都不让读cookie了。按照网景公司取的名字Same-origin policy，不妨称微软公司这一招为 No-origin policy。

总之，JavaScript的发展就是一路修修补补，哪里出漏洞，就在那里亡羊补牢。