一般来说浏览器是不允许跨域的脚本访问的,也就是说来自某个域的脚本是不允许访问（连接）另一个域的资源的.但是如果这个脚本是来自本地的,那就没有限制了!这就是上面的漏洞产生的原因。
我们所说的脚本访问,就是使用XmlHttpRequest对象进行数据提交，Ajax的核心。那为什么不允许跨域的脚本访问呢?我们设想一下,你在公司内网 (intranet)里,然后通过浏览器（不小心的）访问了Internet上的一个恶意站点.其返回的HTML页面上有一段隐藏的Javascript脚本会连接你的公司的内部 Web服务器（注意，脚本是运行在你的浏览器里的）,然后（悄悄的）把这些数据发到其站点,从而窃取了你公司的数据!你看,本来该站点是不能直接连接你的内网的,现在你的机器却充当了跳板, 公司的网络于是大门洞开!当然了,实际情况是,浏览器是不允许来自一个域的脚本访问其来源域之外的资源的,所以它是无法连接你的内网服务器的--除非你修改了浏览器的默认设置.
前些天我们讨论了为什么在浏览器里允许Javascript创建COM组件是危险的,那么Browser Helper Object(BHO)又如何呢?还有,我们还可以通过注册URL协议来让浏览器启动特定的应用程序.比如电驴的下载链接就是以"ed2k:"开始的，而不是常见“http:”,点击链接后就会启动电驴程序并自动下载。还有，对于特定的文件后缀（比如“.doc”），浏览器还会启动关联的程序（比如Word）----这么多的安全隐患存在！
实际上，IE的安全设置只是对Javascript创建COM有限制，而对BHO和URL协议等不予限制。问题就来了，恶意程序完全可以也通过BHO对象，注册URL协议和关联文件后缀来达到启动的目的啊！？--真是站着说话不腰疼,下面解释.
一开始我也很纳闷，是啊，为什么啊？仔细想想，IE这样做还是有理由的。首先，不管是COM，BHO对象、URL协议以及文件关联等，都不能简单的在网页里完成，都需要首先安装也就是有用户手动确认的过程。这样的话，就表明用户是信得过(至少看起来是这样的)这个程序(站点)的，所以就没有理由限制其使用。问题其实出在这里,如果这些COM/程序的使用(调用)者是恶意脚本(站点)的话会怎样呢？比如我有一个COM组件，可以格式化硬盘.一般情况下用户是不会去使用它的，而偏偏你访问了一个恶意网站，它知道这个COM组件的存在并利用其格式化了你的硬盘！所以COM是一把双刃剑，放在好人的手里可以做好事，而落在坏人手里就会祸害无穷。同时，这也是为什么IObjectSafety要存在的原因。作为COM的开发者，你有责任向系统说清楚你有没有危险性，万一落到坏人手里会不会有危险。这也是为什么创建Scripting.FileSystemObject对象时IE会有安全提示，而XmlHttpRequest没有的缘故。但是在 Windows的世界里，COM组件实在是太多了，而且不守规矩的COM组件也很多（比如很危险的组件，也实现IObjectSafety声称自己是安全的----贪一时方便，却给整个系统留下了隐患）。另外，即便是看起来不危险的组件，也可能会带来危险。比如一个只能读硬盘数据的组件（不能写，看起来挺安全的），却可能被恶意的站点所使用，把读取的数据发回服务器，从而窃取用户的信息！就像本文开头所说的RSS阅读器的安全漏洞。
所以，可以通过设置,让所有的 COM组件都不能运行--这样省心啊！而对BHO，URL协议以及文件关联对应的程序来说，其功能一般都比较单一，或者说针对性很强，比如电驴就是下载文件/Word就是文档编辑，而且都是带有用户界面的，对其要操作的数据也有一定的校验功能，很难利用其(偷偷摸摸的)进行恶意攻击，所以也就没有阻止运行的必要了--一些流氓软件除外。
既然制定了规则还是应该按照规则办事的,每个人都尊守很重要,革命靠自觉嘛.但是有人就是不愿意按照规则办事怎么办?目前的IE还是搞不定,你已经引狼入室了,只好自认倒霉了----当然这需要另一套游戏规则了.
说到用户数据泄露，今天还遇到这样的情况。通过HTML里的Form表单也是可以提交一个文件的，那么万一恶意网站使用Javascript脚本在暗地里插入(修改)了文件路径.在一个(伪装的)提交页面里,在用户点击了提交按钮后,偷偷就把用户的文件给提交到服务器了怎么办？汗!后来才发现，你根本不可能通过Javascript来动态修改那个文件路径，只能是用户通过界面来选择。哦!
关于浏览器的安全问题，真是好复杂啊，呵呵。