JavaScript 同源策略

同源策略在什么情况下会起作用呢？当web页面使用多个元素或者打开其他浏览器窗口的时候，这一策略就会起作用。

同源策略的含义：脚本只能读取和所属文档来源相同的窗口和文档的属性。
这里就涉及到了一个浏览器如何判断两者是否同源已经如何判断脚本来源的问题。

注意一点：脚本本身的来源并不作为判断是否同源的依据，而是将脚本所属文档的来源作为判断依据。
1. 判断脚本来源
例如：文档A中通过script的src引用了一个外部脚本，这个脚本时google提供的，也是从google的主机上加载到文档A中的，那么这个脚本的所属文档是谁呢，答案是文档A。
2. 判断是否同源
理解了脚本来源，接着理解怎么判断是否同源：如果两个文档在协议、主机以及载入文档的URL端口这三点中有一点不同，就认为他们不同源。
同源策略固然在安全性上有了很大提高，但这种做法属于“宁可错杀三千，不可放过一个”。如果一个多域名站点需要在不同的子域之间共享属性，同源策略就会变得很烦人了。

以下介绍三种实现“不严格的同源策略”的方法：
1. 使用Document对象的domain属性
默认情况下，属性domain存放的是载入文档的服务器的主机名。这一属性是可写的。
如果两个窗口包含的脚本把domain设置为了相同的值，那么这两个窗口就不再受同源策略的约束，它们就可以相互读取对方的属性。
2. 跨域资源共享（Cross-Origin Resource Sharing）
这种方法用新的“Origin：”请求头和新的响应头“Access-Control-Allow-Origin”来扩展HTTP。
3. 跨文档消息（Cross-Document Messaging）
允许来自一个文档的脚本可以传递文本消息到另一个文档里的脚本，不管来源是否相同。
调用window对象的postMessage()方法，可以异步传递消息事件到窗口的文档里。这种方法仅仅是一种消息传递技术。

为什么要有同源限制？

我们举例说明：比如一个黑客程序，他利用IFrame把真正的银行登录页面嵌到他的页面上，当你使用真实的用户名，密码登录时，他的页面就可以通过Javascript读取到你的表单中input中的内容，这样用户名，密码就轻松到手了。

Ajax应用：

在Ajax应用中这种安全限制被突破。

在普通的Javascript应用中，我们可以修改Frame的href，或者IFrame的src，以实现GET方式的跨域提交，但是却不能访问跨域的Frame/IFrame中的内容。

而Ajax它通过XMLHTTP进行异步交互，这个对象同样能够与远程的服务器进行信息交互，而且更加危险的是，XMLHTTP是一个纯粹的Javascript对象，这样的交互过程，是在后台进行的，不被用户察觉。因此，XMLHTTP实际上已经突破了原有的Javascript的安全限制。

如果我们又想利用XMLHTTP的无刷新异步交互能力，又不愿意公然突破Javascript的安全策略，可以选择的方案就是给XMLHTTP加上严格的同源限制。这样的安全策略，很类似于Applet的安全策略。IFrame的限制还仅仅是不能访问跨域HTMLDOM中的数据，而XMLHTTP则根本上限制了跨域请求的提交。

浏览器支持:而IE其实给这个安全策略开了两个想当然的后门，一个是：他假设你的本地文件，自然清楚将会访问什么内容，所以任何你的本地文件访问外部数据， 都不会收到任何的警告。另一个是：当你访问的网站脚本打算访问跨域的信息时， 他居然仅仅是弹出一个对话框来提醒你一下。如果一个欺诈网站，采用这样的手段，提供一个假页面给你，然后通过XMLHTTP帮你远程登录真实的银行服务器。只要10个用户里，有一个用户糊涂一下，点了一个确定。他们的盗取帐号行为，就成功了！ 你想想看，这是何等危险的事情！

FireFox就不是这样的做法，缺省的情况下，FireFox根本就不支持跨域的XMLHTTP请求，根本就不给黑客这样的机会。

避免同源策略：

JSON和动态脚本标记

<script type="text/javascript"
src="http://yoursiteweb.com/findItinerary?username=sachiko&
reservationNum=1234&output=json&callback=showItinerary" /> 

当 JavaScript 代码动态地插入 <script>标记时，浏览器会访问 src 属性中的 URL。这样会导致将查询字符串中的信息发送给服务器。在 清单 1中，所传递的是 username 和 reservation 作为名称值对传递。此外，查询字符串还包含向服务器请求的输出格式和回调函数的名称（即 showItinerary）。<script> 标记加载后，会执行回调函数，并通过回调函数的参数把从服务返回的信息传递给该回调函数。

Ajax代理

Ajax 代理是一种应用级代理服务器，用于调解 Web 浏览器和服务器之间的 HTTP 请求和响应。Ajax 代理允许 Web 浏览器绕过同源策略，这样便可以使用 XMLHttpRequest 访问第三方服务器。要实现这种绕过，有如下两种方法可供选择：
客户端 Web 应用程序知道第三方 URL 并将该 URL 作为 HTTP 请求中的一个请求参数传递给 Ajax 代理。然后，代理将请求转发给 [url]www.jb51.net[/url]。注意，可以把代理服务器的使用隐藏在 Web应用程序开发人员所使用的 Ajax 库的实现中。对于 Web 应用程序开发人员而言，它看上去可能完全不具有同源策略。
客户端 Web 应用程序不知道第三方 URL，并且尝试通过 HTTP 访问 Ajax 代理服务器上的资源。通过一个预定义的编码规则，Ajax 代理将 所请求的 URL 转换为第三方服务器的 URL 并代表客户检索内容。这样一来，Web 应用程序开发人员看上去就像是在和代理服务器直接进行通信。

Greasemonkey

Greasemonkey 是一个 Firefox 扩展，它允许用户动态地对 Web 页面的样式和内容进行修改。Greasemonkey 用户可以把用户脚本（user script）文件与一个 URL 集合建立关联。当浏览器通过该 URL 集合加载页面时，便会执行这些脚本。Greasemonkey 为用户脚本的 API 提供了额外的许可（与运行在浏览器沙盒中的脚本的许可相比较）。

GM_XMLHttpRequest 是其中的一个 API，它从本质上说就是一个不具有同源策略的 XMLHttpRequest。用户脚本可以将浏览的内置 XMLHttpRequest 替代为 GM_XMLHttpRequest，从而许可 XMLHttpRequest 执行跨域访问。

GM_XMLHttpRequest 的使用只能通过用户同意的途径才能受到保护。也就是说，Greasemonkey 只有在建立新用户脚本与特定 URL 的集合之间的关联时才会要求用户配置。然而，不难想象一些用户可能会被欺骗，在没有完全理解其后果时就接受该安装。