转自http://www.ibm.com/developerworks/cn/lotus/mashup-openajax/

Mashup 应用的安全隐患

什么是同源策略

要了解不受信 Widget 给 Mashup 应用带来的危险，首先要理解浏览器的同源策略（Same-Origin Policy）。

浏览器的同源策略是 Web 安全的基础，所有的主流浏览器都会有相应的实现。同源策略中“源”是一个包含主机名、协议和端口号的三元组。在同源策略的限制下，浏览器只允许网页中的脚本（如 JavaScript. 或 VBScript）访问与之同源的 HTTP 请求和 cookie。比如，http:///same1.htm 和 http:///same2.html 是属于同一个源，网页之间的脚本访问不受限制；而在 http:///diff1.html 页面中的脚本无法对 http://12.34.56.78/diff1.html 里的数据进行读和写，即使 域名对应的 IP 就是 12.34.56.78。下表给出了一些与 http:///directory/page.html 做同源比较的结果：

这里需要注意的是同源策略只对网页的 HTML 文档对象做了限制，而对静态的资源文件，如 JavaScript. 文件、CSS 文件、图片都可以被导入到 HTML 文档对象中（例如 , , ）。因此，对于静态文件可以从任意其它域名下导入 HTML 文档。这些从其他域名导入的文件都会被认为在导入的 HTML 文档的上下文中操作，所以是符合同源条件的。对于 XMLHttpRequest, 同源策略会限制应用程序不能够访问“非同源”的服务。

同源策略保证了 Web 应用的安全。这样，用户在访问网上银行的时候就保证不会被网页中插入的恶意代码窃取密码再发送到别的服务器上去。但是这一策略恰恰在 Web2.0 时代成为了一个应用开发的障碍。Web2.0 时代的网页应用不仅要求用户可以查看页面，同时也允许用户贡献，分享数据。尤其是像 Mashup 这种需要集成多方的数据源的应用。比如，作为显示多家航空公司票价的 Mashup 应用，我们希望在同一个页面上能够同时显示来自多个航空公司网站的票价数据。但是由于同源策略的限制，我们无法直接在 Mashup 的 Web 客户端用脚本语言访问这些航空公司来取得数据。为此，我们必须绕过浏览器的同源策略限制。

如何绕过同源策略的限制

要绕过浏览器的同源策略限制，主要有以下几种方法：

Ajax 代理

通常的做法是在服务器端实现 Ajax 代理。比如 http://foo.com/airticket.html 中的脚本需要取得来自 http://bar.com/airticket.html 中的机票信息，可以在 foo.com 的服务端实现一个 Ajax 代理。这样，当客户端需要往 bar.com 发送请求的时候，客户端可以向服务器端的 Ajax 代理 http://foo.com/ajax_proxy/http/bar.com/airticket 网址发送请求。Ajax 代理在服务端向 http://bar.com 转发请求，返回后再转发给 Web 客户端。通过这样的方式，foo.com 的 Web 客户端实际上是往自己域名下的发送请求而不会受到浏览器的限制。这是常见的 Mashup 平台惯用的做法。不过，显然 Ajax 代理带来的便利也变成了恶意代码滋生的温床。通过 Ajax 代理，彻底破坏了浏览器的同源策略。运用代理 , 任何一个脚本都可以不受限的与远端的服务器进行通信。

JSON 和动态 Script. 标签

浏览器的同源策略仅限于页面的 HTML 文档，而对静态的资源文件没有要求。对于脚本文件来说，不管来自于什么域名下的脚本，只要导入到当前页面上，在当前页面上执行，则脚本运行的上下文就是当前域名。这也给了我们另一个机会用在 Web 客户端直接用脚本语言来访问其他域名下的内容。JSON with Padding（JSONP）这种方法通过动态添加