XDomainRequest——限制、局限性和变通方案
本文翻译自微软官网的一篇文章，名称是 XDomainRequest – Restrictions, Limitations and Workarounds
本文原作者是EricLaw，前微软正式员工。2004到2012年在微软担任IE程序经理（Program Manager）。
译文如下：
更新：IE10 以上的浏览器支持使用 XMLHTTPRequest 对象，进行跨域资源共享(CORS)访问。IE11 废弃了 XDomainRequest 对象，并且此对象在IE11的Edge模式下不可用。
IE8 引入了 XDomainRequest 对象。XDomainRequest 对象允许 AJAX 应用程序在满足一定条件的时候，直接发起安全的跨域请求。这个条件是：当数据源指明 HTTP 响应是公共的，并且AJAX应用程序可以确保 HTTP 响应只被当前页面读取。在那种方式下，同源策略安全保证是受到保护的。为此，HTTP 响应需要指明自身是允许跨域访问的。实现方式很简单，只需给 HTTP 响应加上Access-Control-Allow-Origin响应头，并把这个响应头的值设置成 * 或者是发起这个请求的页面的域名。
当设计XDomainRequest这个新对象的时候，我们工作的最高优先级是确保不让现存的网站和服务置于险地。为了这个目标，我们把许多限制强加到使用XDomainRequest对象发送的各种各样的请求上。绝大多数限制被设计用来阻止针对遗留服务的跨站点请求伪造攻击（Cross-Site Request Forgery 即CSRF）。
这篇文章剩下的部分描述了这些限制和这些限制背后的原因。
1.必须使用 HTTP 或 HTTPS 协议访问目标 URL
这一条很简单——因为 XDomainRequest 对象依赖于一个HTTP响应头来实现访问控制，XDomainRequest 对象要求目标 URL 符合 HTTP 或 HTTPS 协议，以便于 XDomainRequest 对象检验响应头。检验响应头的目的是为了得到一个允许调用者访问 HTTP 响应的许可。
2.只能使用 HTTP 的 GET 方法和 POST 方法访问目标 URL
为了确保新加的XDomainRequest对象不会增加现有的服务器和服务的受到攻击的可能性，我们选择把这个对象可以调用的HTTP方法限制在只有GET方法和POST方法两种。符合HTML 4.01 标准的表单被限制只能使用这两个同名的方法。这意味着任何冒险使用 XDomainRequest 对象的服务，也容易受到来自于跨源 HTML 表单的攻击。既然 HTML 表单已经好好地存在了超过十年，大家都假设应用程序可以抵御使用 GET和POST方法的攻击行为。
我们假设使用其他方法发布的请求不会在服务器上做出和GET/POST一样的处理。除此之外，大多数开发者想要使用的其他方法 (比如 WebDAV / REST methods) 也要求发送自定义 HTTP 报头信息，请接着往下看：
3.请求中不能加入自定义的报头
这条限制类似于第二条。我们想要确保XDomainRequest对象不会允许攻击者发送一个HTML表单不会发送的请求。这一点非常重要。因为直到HTTP响应从服务器返回的时候， 浏览器才能使用Access-Control-Allow-Origin响应头，所以浏览器在请求发送之前没法分辨服务器是否愿意接受跨域的请求。没有了这些限制，即使服务器没有返回Access-Control-Allow-Origin响应头,也有可能发生针对遗留服务器的“即发即弃”跨站点请求伪造攻击（CSRF）。
所有XDomainRequest对象发送的请求带有一个 Origin 请求头，显示调用页面的源（域名）。
4.只支持 text/plain 作为请求报头Content-Type的取值
在 XDomainRequest 对象最开始的版本中，我们允许这个对象按照Content-Type规范发送 POST 请求。因为HTML表单仅限于用三种不同的内容类型（即Content-Type取值）发送数据：text/plain, application/x-www-urlencoded 和 multipart/form-data，所以让 XDomainRequest 遵循Content-Type规范的做法被认为违反了我们只让XDomainRequest发送HTML表单请求的目标。特别地，有人指出一些 AJAX服务器编程库会盲目地做出如下假设：如果编程库接收到 Content-Type 报头取值是SOAP或者JSON的请求，那么客户端要么是可信的，要么是同源的（因为以前HTML自身没法发送Content-Type为SOAP或JSON的请求）。
很不幸，当我们在一个较晚的IE8 beta版本修复了这个问题的时候，我们走得太远了；我们把 Content-Type 限制成 text/plain，但是不允许调用者指定数据是 application/x-www-urlencoded 形式的。上面的做法会人为制造困难，这是因为服务器端框架（比如ASP，ASP.NET等）只有在 Content-Type 请求头被设置成 x-www-urlencoded 的情况下，才能自动地把请求域解析成名-值对。
注意：截至2014年，XDomainRequest 看起来好像再也不会发送任何Content-Type请求头了，我不清楚什么时候变的。
为了应对这个问题，当服务器接收到来自XDomainRequest对象的请求的时候，当前处理HTML表单的服务器代码必须重写，来手动地把请求体解析成名-值对。这使得添加XDomainRequest对象的支持功能变得比原先困难得多。
5.身份验证和cookie不能和请求一起发送
为了阻止对用户的环境验证（比如cookies、HTTP身份验证、客户端证书等等）的误用，请求将会失去cookies和身份验证，并且将会忽略任何身份验证请求或HTTP响应中设置 cookies 的指令。因为一些 Windows 验证协议（比如NTLM/Kerberos）是基于每个连接的，而不是基于每个请求的；所以 XDomainRequests 不会在以前验证过的连接上发送请求。
那些希望发送跨域用户身份验证请求的网站，可以使用清楚明白的方法（比如把令牌放在POST请求体中或者是URL里）来传送验证信息，而不要冒险使用用户的环境验证。
6.只能在企业网域内发起指向企业内网URL的请求
正如文档表格所显示的那样，XDomainRequest 限制企业网域内的页面向本地基于企业内网的资源发起请求。这种安全预防措施不是被HTML表单直接强制加上去的，而是IE浏览器的区域提升安全特性提供了一种相似的网页导航保护，恰好表单提交只是一种特殊的网页导航。
7.请求URL必须和主页URL采用相同的协议
这条限制意味着如果你的发起AJAX请求的页面URL是 http://example.com ，那么你发起AJAX请求的URL必须是HTTP开头。相似地，如果你的发起AJAX请求的页面URL是 https://example.com ，那么你发起AJAX请求的URL必须是HTTPS开头。
我们的意图就是阻止HTTPS页面使用XDomainRequest向HTTP资源发起请求，这是由于此方案防止了许多开发者和绝大多数用户都不明白的混合内容安全威胁。
然而，这种限制过于宽泛，因为此限制阻止了HTTP页面向HTTPS页面发起XDomainRequest请求。当HTTP页面自身采用了妥协HTTPS方案的时候，就没有理由禁止HTTP页面接收公有的安全内容。
最蹩脚的是，相同URL协议的限制意味着，web开发者在本地使用本地文件传输协议file:// 做测试的时候，将会发现全部的XDomainRequests被阻塞了。原因是本地文件传输协议file:// 既不匹配HTTP协议，也不匹配HTTPS协议，同时只有HTTP协议和HTTPS协议是有效的请求URL协议（参考第1条限制）。为了解决这个议题，web开发者必须把他们的页面放在本地web服务器（比如IIS，Visual Studio的服务器）上运行。
为了跨越这条限制，你可以建立 postMessage-Proxy-for-XDR 。
尽管存在这些限制和没有预料到的局限性，XDomainRequest对象还是提供了强大的功能。随着支持跨域资源共享（CORS）规范的服务器越来越普遍，XDomainRequest对象只会变得越来越有用。
更新：IE10现在支持使用XMLHTTPRequest对象来进行跨域资源共享（CORS）访问。应该使用XMLHTTPRequest对象而不是现在已经废弃的XDomainRequest对象。
注意：我们打算用XDomainRequest对象支持COMET流技术，但AJAX开发者可能需要处理一个对象支持响应流的BUG。
注意：IE8，在用户使用InPrivate浏览模式浏览网站的时候，所有的XDomainRequest 将会失败并报错。IE9修复了这个BUG。
原文链接：XDomainRequest——限制、局限性和变通方案
