IE的XMLHttpRequest、XDomainRequest和ActiveXObject
今天看到⼀份代码：
2016年10⽉31⽇ 13:50:12
本⽂翻译⾃微软官⽹的⼀篇⽂章，名称是
本⽂原作者是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 的情况下，才能⾃动地把请求域解析成名-值对。网页设计html代码翻译
注意：截⾄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采⽤相同的协议
我们的意图就是阻⽌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的服务器）上运⾏。
为了跨越这条限制，你可以建⽴。
尽管存在这些限制和没有预料到的局限性，XDomainRequest对象还是提供了强⼤的功能。随着⽀持跨域资源共享（CORS）规范的服务器越来越普遍，XDomainRequest对象只会变得越来越有⽤。
更新：IE10现在⽀持使⽤XMLHTTPRequest对象来进⾏跨域资源共享（CORS）访问。应该使⽤XMLHTTPRequest对象⽽不是现在已经废弃的XDomainRequest对象。
注意：我们打算⽤XDomainRequest对象⽀持COMET流技术，但AJAX开发者可能需要处理⼀个对象⽀持响应流的BUG。
注意：IE8，在⽤户使⽤InPrivate浏览模式浏览⽹站的时候，所有的XDomainRequest 将会失败并报错。IE9修复了这个BUG。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。