绕过浏览器相同来源策略的一些方法

浏览器的相同来源策略大家都很清楚。它在保证了用户安全性的同时，也为实现某些类型的Ajax应用造成了很大困难。经常有人尝试用各种方法来绕过相同来源策略，但是很少有人成功。相同来源策略是W3C所规定的一个严格的限制机制，如果能够轻易绕过，那将是这个浏览器版本的重大安全漏洞。

我来总结一下我至今见到过的绕过相同来源策略的几种方法。

1. 通过同一个服务器请求来自不同来源服务器的页面。 
在客户端，需要对XMLHttpRequest对象做一下封装。就是以GoF的Decorator模式对XMLHttpRequest对象做封装，得到一个接口完全相同的新对象。这个新对象可以接受对不同来源服务器的请求（XMLHttpRequest对象本身是不接受的），如果发现是对不同来源服务器的请求，在这个新对象的内部将URL转为相同来源服务器上的某个镜象URL。
在服务器端，识别出对不同来源服务器的请求，得到其真实URL，获取其内容返回给客户端。服务器端实现的是一个GoF的Proxy模式。

2. 实现一个HTTP代理服务器，将浏览器设置为使用这个HTTP代理服务器。 
客户端和HTTP代理服务器要做的事情和方法1完全相同。 
这是Selenium RC所采用的方法。它为了测试任意来源服务器页面中的脚本，运行时自动将自己设置为IE或Firefox的HTTP代理服务器，将一些页面（及其所包含的测试脚本）插入到被测试页面的来源服务器的URL空间，使得浏览器误以为这些测试脚本与被测试页面属于相同的来源服务器。

3. 如果不同的来源服务器提供的是JSON格式的数据，那情况就简单多了。 
动态创建一个script标签，将其src属性指向这个URL就可以了。浏览器获取这些JSON数据，立即对其执行eval。你无法做其他什么事情，因为你无法控制这个过程。 
这也是以JSON格式暴露出Web服务越来越流行的原因。因为这种方式非常便于客户端脚本集成来自多个数据源的数据。Yahoo!的论坛暴露出的数据就是JSON格式的。

注意：使用这种方法是非常危险的！除非你仔细检查过获取到的JSON数据的内容，确保这些内容没有做任何危害用户的事情；或者你100%信任Yahoo!的服务器管理员，因为他正是你的亲兄弟。否则用户受到的任何恶意攻击，他们都会迁怒于你，你会很快成为众矢之的，甚至会遭到法律诉讼。

4. 使用一个IFrame，父页面的脚本可以修改子页面（就是那个IFrame）URL中#后的内容，子页面也可以修改父页面URL中#后的内容。 
这样你在子页面中就可以设置一个onload函数，加载完后通过修改父页面URL中#后的内容，将一些信息传递给父页面。父页面中使用一个周期运行的轮询函数，从自己的URL中取出这些信息。 
Dojo里面使用这个技术实现了一种来自不同来源服务器的页面之间的通信机制。

不过这种方法局限性很大： 
首先，要给IFrame所加载的页面加onload函数，你必须对这个页面所在的服务器有控制权。否则你就只能试图以木马攻克这个网站，或者行贿这个网站的服务器管理员。 
其次，在URL中#后面能够传输的数据量非常少。如果数据量很大，必须要以多次搬运和组装的方式来实现，那样将是非常低效的。

应该还有更多的方法，不过这些方法都有局限，不是那么容易实现的。大家如果感兴趣，可以用电骡去搜索： 
XSS Exploits: Cross Site Scripting Attacks and Defense 
这本书。这是一本关于这个特定领域非常有趣的书。