WEB安全第十课 浏览器插件产生的内容

    浏览器插件(plug-in）可谓林林总总，形态各异，最常见的就是用插件在浏览器里显示各种新奇的文件格式，效果类似于显示常规的HTML文件。

    浏览器做的只是把收到的文件转给相应的插件，然后在文档显示窗口里为这些帮助应用程序提供一个长方形的绘图区域，浏览器自己基本上就退居幕后了。这种用于内容呈现的插件明显有别于浏览器里的扩展，浏览器扩展的分支有很多，但扩展通常只是用JavaScript代码来调整浏览器原本就支持的内容，再供给用户访问。
    
👨‍🎨‌💄🪣😀🤝
    长期以来，浏览器插件的安全漏洞不但数量众多且千奇百怪。实际上，据分析数据显示，在2014年最易受攻击的15个客户端风险里，有12个都与插件程序有关系。这类问题大多是由于插件里的解析器未能妥善地处理恶意输入，而且插件往往不像Web其他方面的安全问题那样会受到严密的关注。

    另一个方面，这是因为插件开发人员设计的安全模型，以及这些插件安全模型的权限、传统浏览器的设计思路和Web应用程序员的常规期待值之间往往是相互冲突的。
    
    在接触到这部分内容之前，有必要先看看这些插件是如何与其他在线内容交互的，以及插件都提供了哪些常见功能。

👵‌🩲🔍☠🦴

    
    1.对插件的调用

    有好几种方式能激活用于内容呈现的插件。最常见的显式的做法是在“宿主”(Host)HTML文档里用<embed src=...>或<object data=...>标记语言来调用插件，在该标记项里再用src或data参数指向插件实际需要访问文件的URL。可用CSS给插件分配其画图区域的大小和位置(或用使用更古老的HTML参数的形式)。
    🧑‍🎤‍🕶🪦🙄👂
    在这种用法里，每个<embed>或<object>标签都要有一个额外的type参数。在type参数里设定的MIME类型会与浏览器里注册的有效插件的MIME类型做个对比，如果匹配上了，就把该文件转给相应的插件进行处理。如果没有匹配上，理论上应该会出现一个提示窗口，提示用户去下载插件，尽管大多数浏览器不会轻易出现这种提示，而是尽量从其他信息去猜测文件的类型;检查Content-Type头域或URL里的文件后缀是最常见的两种做法。
    
    注意:已经弃用的<applet>标签，以前用于加载Java小程序(大致相当于<object type="application/x-java-applet">.，工作方式与前述两种类似，但会忽略其他的额外信息。
    
    插件里其他输入信息一般是通过在<object>区块里嵌入<param>标签进行设置，或者在<embed>标记里直接写这些非标准的参数设置项。前一种情况现在更为常见，写法如下：👨‍🚒‏🕶🪝🤬🤞
    
[mw_shl_code=html,true]    <object data="app.swf" type="application/x-shockwave-flash">
    <param name="some_param1" value="some_valuel">
    <param name="some_param2" value="some_value2">
    ...👨‍⚕️‌🧣✒😴🙏
    </object>[/mw_shl_code]
    
    在使用这种插件引用形式时，除非无法识别上述type参数，浏览器一般来说会忽略服务器对该子资源返回的Content-Type响应头。这个设计可真糟糕，我们马上会说明原因何在。
    
    显示插件内容的另一种做法是直接访问插件文件。这种情况下，会类似于<embed>和<object>没有设置type参数时的处理，此时就会采纳服务器端提供的Content-Type值，随后浏览器对比MIME类型列表，找出匹配的插件。如果匹配到了，就会将该内容转由相应的组件处理。如果根据Content-Type没有找到匹配的插件或压根就没有Content-Type响应头，有些浏览器还会检查返回的响应数据，在其中尝试识别某些内容特征;另外一些浏览器就完全放弃了。

👮‍♂️‏🩳🧬😊👍

    
    注意:此前提到的这些插件都和内容相关，但还有若干插件可以直接在JavaScript或VBScript里被调用，而无须通过HTML标记语言的写法或需要先加载外部数据。例如只有IE浏览器支持的臭名昭著的ActiveX机制，就直接把脚本和系统整合到一起了。


    
👂🚂🥄♊🐞‎    2.对插件Content-Type处理的风险
    
    如上面所提到的，在某些场景里，插件处理的文件所对应的Content-Type参数往往被忽略掉了，通常是以引用插件的页面标记语言里的type参数为准。

    这种设计有点类似HTML引用其他类型文件时的标签写法(例如<img>)，但在插件的世界里，这种处理会产生某些独特甚至可能致命的后果。

🦴🗽🥣©🐮‌

    
    最大的问题是若干插件实际上都有自己完整的代码执行环境，而且这些可执行的插件应用(即插件小程序applets.在与它们所在的原站点进行交互时拥有一系列的特权。例如，恶意站点bunnyoutlet.com蓄意加载一个来自站点fuzzybunnies.com的Flash文件，这个Flash插件实际上就具有原站点的授权信息了(配合上用户的Cookie)。
    
    在这种情况下，对fuzzybunnies.com来说最好能明确控制哪些特定类型的文件是以插件形式执行的，哪些不是。但很遗憾，居然完全没法做到这点：要怎么处理取回的文件实际上完全听命于嵌入该插件的站点(以我们这个例子来说，就是由躲在bunnyoutlet.com背后的龌蹉坏蛋决定的)。因此，如果原站点上有任何用户控制的内容，即使是常规无害的格式(例如text/plain或image/jpeg)，bunnyoutlet.com的坏蛋站长仍然可能诱使浏览器妄顾已有的元数据信息，强制把文档按坏人选择的插件格式进行处理。只要通过以下简单的代码就能实现这一邪恶的目标：
    

🤳🚤🍌🈷🐴‎

[mw_shl_code=html,true]    <object data=“"
            type="application/x-shockwave_flash">[/mw_shl_code]
            
    如果运行出错了，那是因为这个文件的确是错的。但安全研究人员已经多次演示过，很容易构造出一个图片同时也能被识别为有效插件文件并获得执行。众所周知的“GIFAR”漏洞，是在2008年由Billy Rios发现并力口以利用：一个Java小程序(applet.偷偷地隐藏在一个看起来很完美很无害的GIF图片里。据说在那之后Sun Microsystems对Java JAR文件解析器的控制更严厉，就为了消除这种风险，但这类错误的风险仍然普遍存在，并且很可能会再次卷土重来。
    ‌👜🛒😥💅
    有趣的是，在碰到无法识别的type参数时，仅靠Content-Type和其他信息来做判断也不是个好主意。假设正常站点fuzzybynnies.com希望通过简单地设定 type="video/x-ms-wmv"内嵌一个来自问题站点bunnyoutlet.com的无害视频，而恰好访问者的浏览器不能自动识别这种文件格式，就突然使bunnyoutlet.com能控制引用该文件的站点应以何种格式加载了。

    某些浏览器，如IE浏览器、Chrome或者Opera，还可能会根据URL里明显的文件后缀做出自己的判断，这样就导致了一个有趣的场景，无论是引用这个文件的站点，还是存放这个文件的站点，实际上都不能真正控制地这个文件在浏览器里是怎么解析和显示的——而这种情况往往就由攻击者说了算。
    
    更安全的设计应该是判断引用时的type参数和存放服务器所返回的Content-Type响应头是否匹配(至少在表面上)。不幸的是，目前还没有办法做到。有些插件希望自己能在这方面做到位(例如，在2008年一次大规模安全自查之后，AdobeFlash就拒绝解析响应头为Content-Disposition:attachment的Flash小程序，在Chrome浏览器里内置的PDF阅读器亦是如此)，但这类改进不太多，也并不成熟。
🙌🛑🦞™🐋‌
    
    3.文档显示帮助程序
    
    插件世界里很重要的一部分任务，就是在浏览器里直接显示某些“非”Web类型的传统文档格式。在这方面某些程序的确非常管用：譬如Windows Media Player、RealNetworks RealPlayer和Apple QuickTime，至少在Adobe Flash把它们挤出市场之前，这些程序是过去10多年来在线多媒体播放的主角。
💅🌕🥑🆘🪶‎
    但除此之外，另外一些用于内容显示的插件就比较有问题了。例如，Adobe Reader和Microsoft Office都会在浏览器里安装自己的文档查看器，这明显增加了用户受攻击的可能性，然而在这些内置的查看器里直接阅读文档，真的就比再多点击一次，先打开单独的应用再阅读文档，会更有优势吗？
    
    当然，在一个完美的世界里，无论是存放还是引用PDF或Word文档，都不应该对相关的网站带来直接的安全隐患。然而，可以预见到，现实总是残酷的。在2009年，一位研究人员发现PDF文件里的表单提交可以触发javascript:URL,如果某站点引用了该PDF,会造成其访问者的客户端代码执行。比这个报告本身更令人忧心的是，这位研究人员说，Adobe公司开始时并未把这份报告当回事，他们的答复是：“我们认为，PDF文件和HTML页面一样，也属于活动内容。”
👨‍⚕️‍🎩🧪😅👌
    活动内容(Active Content)指的是网站上可以交互的内容，如投票功能，或动态显示的内容，如动画格式的GIF、股票行情显示组件、天气地图、JavaScript应用、内置的对象、流媒体视频和音频还有ActiveX应用。
    
    遗憾的是，活动内容被检测和执行的时候，存放的服务器竟然不能完全控制这些文档的解析方式，若非如此，网站管理员确实可以认为PDF或者Word文件是一种炫酷的展示方式呢。实际上，这些文档表面上似乎无害，看起来也还很漂亮，但很多这类文档格式都支持超链接甚至脚本语言。

    例如，PDF文档就可以内嵌JavaScript代码，而微软Office文档里则可以使用Visual Basic宏。当一个包含脚本的文档展示在HTML页面里时，必定会需要触发“插件-浏览器”的桥接处理，这种处理往往使得此类文件和引用它们的站点之间有了一定的交互能力，这种插件-浏览器的桥接既可能导致隐晦的潜在问题，也可能直接产生非常荒唐的错误。
🤟🚘🧊☣🐝‌    
    在2007年的一个案例里，Petko D.Petkov发现只要简单地在PDF文件的片段ID位置上放人任意JavaScript代码，就能轻易地攻击存放该PDF文档的站点。通过插件的桥接功能，在引用这个链接的宿主文档(Hostingpage.上，以下脚本就会获得执行。:
    
    http://example.com/randonudocument.pdf#foo=javascript:alert(1)
    🧑‍⚕️‍🕶✒😇👌
    以上提到的两个漏洞现在都已修复，但换来的教训是对敏感的站点来说，无论存放还是引用任何由用户提供的文档，都需要做额外的考量。没有什么资料能告诉你这么做会带来什么问题，也很难预测会有什么后果。

    
    4.插件的各种应用框架
    

✊🛩🦞🈚🐺‏

    渲染和显示各类文档这类枯燥的活儿一直是浏览器插件的主打任务，但一些野心勃勃的开发商却有心突破这一固定成规。某些插件的目标就是通过提供另一种功能更齐全的平台，来创建更具交互性的Web应用，以取代HTML和JavaScript。

    这么做也不是全然没有道理：长期以来，浏览器无论在性能和图形功能，还是在多媒体编码方面，都颇为欠缺,也限制了Web的各种潜在应用的发展。而插件是能在短期内突破这些限制的办法。但不好的方面是，一旦这些专用的涉及专利和版权限制的插件被推选为创建在线生态环境的最佳途径，而不再去改善和提高浏览器自身，会不可避免地损害Web的开放性。

    关于这点颇有一些批评者，最著名的就是Steve Jobs,他认为建立一个被牢牢掌控的线上生态环境正是某些插件厂商，特别是Adobe公司的阴谋。
👃🚐🍖🈸🐟‎    
    人们逐渐意识到这类插件想接管Web世界的野心和威胁，但他们的应对方式却是把当前浏览器的诸多不足，都匆忙地推给另一套应用框架，也就是说指望HTML5机制能解决所有这些问题;如<video>标签和WebGL是主要的例子。

    但另一方面，某些插件的功能在短期之内也不会被加到浏览器的自身标准里。例如，现在HTML5还没有计划会支持Java，由于能在浏览器内部提升应用程序的权限所以Java插件本质上非常危险，另外还有把保密当做安全手段的内容保护策略(Digital Rights Management，DRM.也属此类。
    
🖕🦼🍌ℹ🐤‎    因此未来的日子里浏览器的前景还会有诸多变数，但我们能想象得到，总有某些专用Web应用框架会被保留下来。
    
    4.1.Adobe Flash
    
    在1996年第一次浏览器世界大战打得正酣时，Adobe Flash作为Web应用框架登场了。在2005年被Adobe收购之前，Flash的全名还叫Macromedia Flash或Shockwave Flash(因此Flash文件的后缀名为.swf)，直至今日，有时候它还是指代这个意思。
🤛⛴🔪ℹ🐺‎    
    Flash这个平台相当实际，它的底层技术是衍生自JavaScript的ActionScript。另外还包括一个2D向量和位图图像渲染引擎，内置支持若干种的图片、视频和音频格式，如广泛使用且效率极高的H.264编码(也是现在绝大多数在线多媒体播放的格式)。
    
    按最乐观的估计，Flash在全世界桌面系统上的安装占有率高达95%到99%。用户基数远远高于其他的多媒体播放插件(尽管采用了强势的捆绑策略，微软公司的Windows Media Player和苹果公司的QuickTime才占到PC总量的60%，而份额越来越萎缩的RealPlayer格式也仍有25%份额)。

👳‍🕶🔋🙃🦴

    Flash获得今日的市场地位要归功于它最重要也最让人意外的用法：Flash取代了之前所有的多媒体播放插件，几乎垄断了在线实时流媒体视频的播放。尽管Flash还有很多其他的用场(包括在线游戏，互动广告等等)，但最简单地用作多媒体播放器所占的比例大得惊人。
    
    注意:让人困惑的是，还有一个单独的Adobe Shockwave Player(没有“Flash”这个字眼)播放器，能用来播放由Adobe Director创建的内容。有时候这个插件会被误当成Adobe Flash安装，又或者和Adobe Flash一同被安装，也大概占有20%的安装率,但这个插件几乎完全没什么用，其安全特性未被深入研究过。
    
    4.2.ActionScript 的属性
🤳🪐🥚™🐖‍    
    在SWF文件里的ActionScript功能，大体上相当于HTML页面里的JavaScript代码，只除了一些轻微但有意思的差异。例如，Flash程序可以随意枚举在系统里安装的所有字体，收集其他有用的系统识别特征，而其他的常规脚本是没有这些功能的。Flash程序还可以用于全屏显示，创建UI界面进行欺诈攻击，能获取得到数码相机或麦克风这类设备的输人数据(当然这个要经过用户的同意)。Flash还会忽略浏览器的安全和隐私设定，对于类似插件里的持久数据保存机制，会使用插件自身的安全配置(尽管在2011年5月，Adobe公司宣称在Flash的安全上做了许多改进)。
    
    其他的特点就比较平淡了。在后面，我们还会更详细地讨论Flash的网络和DOM访问许可问题，但简而言之，默认情况下Flash小程序可以直接使用浏览器的HTTP堆栈(以及该堆栈所管理的全局身份凭证信息)，然后和Flash所在的服务器进行互动，向别的站点请求获取特定的子资源，控制当前浏览器窗口的访问或者打开新的窗口。ActionScript也可以和浏览器里其他正在运行的Flash应用进行交互，在某些情况下，还可以访问引用它的网页的DOM元素。最后这个功能是通过向目标JavaScript执行环境注入类似于eval(...)这样的代码实现的。
    🧑‍⚕️‎💎🪥😰🙌
    ActionScript为Web应用漏洞提供了肥沃的土壤。例如它的getURL(...)和navigateToURL(...)函数原本用于控制浏览器的访问或打开新的窗口，有时候攻击者控制的输入也会触发这些功能。而这种用法是很危险的。即使javascript:URL这样的地址对Flash来说没有什么特殊的含义，但利用前面那两个函数就可以把这串字符传递给浏览器，在某些情况下，就可能给引用这个Flash的站点带来脚本注入。
    
    在第前面讨论过的，从不受信任站点加载脚本可能产生的问题，在插件的世界里也有同类的问题。在Flash里，攻击者可以通过控制URL来触发某些函数，影响ActionScript的执行环境，这是非常不安全的(例如LoadVars.load(....)，即使这些URL资源对应的协议不过是http:或https:。
    
    另一个被忽视的攻击层面是Flash插件自带的内部简化版HTML解析器：它可以把简单的HTML标记语言赋值给Flash里的TextField.htmlText和TextArea.htmlText属性。在这种情况下，很容易忘记要对用户提供的数据进行正确的转义。未正确转义的后果是令攻击者可以修改应用UI的外观或注入能触发脚本执行的URL链接，带来潜在的安全风险。
🙌🚂🍽🈳🐤‍    
    另一类Flash相关的安全缺陷可能是由于插件自身的设计或实现问题所导致。例如，以ExternalInterface.call(....API的调用为例。它的本意是让ActionScript能调用引用页面上的已有的JavaScript函数，ExternalInterface.call(...)有两个参数：要调用的JavaScript函数名和可选的要传递进去的字符串。可以想象，既然第一个参数攻击者是没法控制的，那在第二个参数里传递用户数据应该是安全的吧。以下程序片段就是官方文档提供的例子，描述了以上使用场景：
    
    ExternalInterface.call("sendToJavaScriptM, input.text.;
    🧑‍🍳‍👓🛏😍👄
    这个调用实际上会对引用页面造成以下代码执行，这相当于以eval(...)方式执行了以下代码：

[mw_shl_code=javascript,true]    try{
    __flash__toXML(sendToJavaScript，"input,text的值"));
    }catch(e){
🦴⛪🥣♂🦋‎    "<undefined/>";
    }[/mw_shl_code]
    
    插件的开发者倒是记得对这个调用的实现采用反斜杠转义，所以输出第二个参数的值时：hello"world实际上会变成hello\"world。但不幸的是，他们忘了对单独出现的反斜杠本身也要做转义处理。因此如果iriput.text的内容为以下字符串的话，嵌入的脚本就被意外地执行了：
    🧑‍💻‌🩴🔒😥🤟
[mw_shl_code=javascript,true]    Hello world!\"+alert(1); } catch(e){}//[/mw_shl_code]

    4.3.Microsoft Silverlight
    
    Microsoft Silverlight是一个功能强大的开发平台，隶属于微软的Windows Presentation Foundation，这套界面技术属于微软.NET框架的组成部分。它诞生于2007年，结合了Extensible Application Markup Language(XAML)(Microsoft版本的Mozilla XUL)与几种托管.NET语言(如C#或Visual Basic)创建而成的。

👊🌕ℹ🐴‍

    
    尽管在设计上两者完全不同，Silverlight在架构上也更庞大(和混乱)，但其主要目标就是为了和Adobe Flash—争高下。Silverlight应用里的许多功能，都和其竞争对手Flash相差无几，包括几乎完全一样的安全模型和类似的对引用页面的eval(...)桥接功能。但要表扬一下微软，Silverlight没有asfunction:协议或者内置HTML渲染器这类东西。
    
    Microsoft对Silverlight的市场营销相当强势，把它和某些版本的IE浏览器绑定在一起。因此，根据数据统计显示应该有60〜75%的桌面占有率。尽管广为传播，但在Web应用里，实际很少用Silverlight来做开发，也许是因为和它那更深人人心的竞争对手相比，Silverlight实在没有什么突出优势，又或者Silverlight的架构看起来更别扭而且不能跨平台(视频播放和租售服务站点Netflix是极少真正使用Silverlight的用户之一，这是为某些设备提供视频播放的主流站点。

👦‌👠🛋💩👍

    4.4.Sun Java
    
    Java是一门与操作系统无关，通过托管代码执行平台来运行的编程语言。由James Gosling于20世纪90年代初到中期为Sun Microsystems公司开发，长期以来，Java主要作为服务器端编程语言，在许多领域里都能看到它活跃的身影，包括手机设备。然而，Sim公司从一开始就渴望Java在浏览器端也能占上重要的一席之地。
    
    Java在浏览器端的出现要早于Flash和大多数同类插件，从现在已经弃用的<applet>标签就能看出，在过去的日子里，Java小程序曾经是多么重要、特别和新颖啊。然而，尽管先人一步，但Java程序作为浏览器端的开发平台如今已几乎绝迹，而且即使在它最辉煌的岁月里，其实也从未真正兴盛过。Java插件仍然保有80%的安装率，但这么高的百分比主要归功于Java插件与Java实时运行环境(Java Runtime Environment,JRE)的绑定，往往为了运行系统里常规的桌面型Java程序，才需要预装JRE这套有用且常见的组件，但这实际上已和浏览器没啥关系了。
👎🧳🦞♑🦊‌    
    很难确定Java在浏览器端一败涂地的原因。可能由于它作为插件运行时启动性能很差，笨拙的UI库也很难用于开发炫酷并且用户友好的Web应用界面，也可能由于Sun公司和微软之间漫长的恶意法律争端，使得Java在微软操作系统上一直前途未卜。不管出于何种原因，Java极高的安装率和极低的使用率，意味着Java插件带来的风险远高于对用户可能带来的好处(这个插件在2010年有80项安全漏洞,而且开发商缓慢的补丁速度也常为人所垢病。)

    Java的安全策略与其他的插件大体类似，但在某些方面，如对同源策略的理解，或限制对引用页面的访问权限上，可都不咋的
。另外值得注意的是，和Flash和Silveriight不同的是，经过加密签名的某些Java小程序可以使用危险的操作系统功能，譬如不受限制的网络和文件访问，这中间只需要稍许哄骗一下，获得用户的同意即可。
🤳🚤🍏❌🐅‏

    4.5.XML Browser Applications
    
    XML Browser Applications(XBAP)是微软在Java开始没落，而自家的Silverlight还没有发布之前，在Web应用框架领域里的一次重拳出击。🧑‍💻‍👗📐😉👏
    
    XBAP是Silverlight的前辈，它们使用同一套Windows Presentation Foundation和.NET架构。然而，Silverlight作为独立的浏览器插件，不需要额外的支持就能直接使用，而XBAP却依赖于庞大且笨重的.NET运行环境，和Java插件要依赖于JRE运行环境差不多一个意思。XBAP的托管代码运行在独立PresentationHost.exe进程里，在初始化时需要加载大量的依赖关系。

    Microsoft自己也承认，要加载一个中等大小，未被缓存过的新应用可以轻易耗掉10秒的时间。XBAP于2002年推出时，绝大多数互联网用户都已无法容忍这么长的响应时间。
    

👨🦱‏👠😚👎

    关于XBAP安全模型的文档非常欠缺，而且直到现在也没有什么特别深入的研究，一方面这和XBAP在实际环境里的应用少到可忽略不计有关，另一方面也可能是因为它的多层架构非常混沌不堪。但你能想象得到，XBAP的安全属性应该和它的继任者Silverlight相类似，但它涉及的.NET库和UI部件的使用范围会更宽广。另外，显然从Sim公司的做法里照搬过来的，通过本地文件系统方式来加载XBAP程序或使用经过加密证书签名的程序时，它的权限可以获得提升。
    
    微软会以静默且不可卸载的方式来安装Windows Presentation Foundation插件，并以绑定的方式把XBAP和.NET框架一起装进系统——不单止装在IE浏览器里，甚至连竞争对手的Firefox和Chrome也不放过。这种做法当然引起了强烈的争议，特别是XBAP的一些安全漏洞也陆续被发现(Mozilla甚至在一次自动更新之后，临时禁用了该插件以保护自己的用户)。然而，尽管微软推动的力度很大也很受争议，实际上没人幵发XBAP小程序，逐渐地，这个技术也和Java小程序一同被扫进了历史的垃圾堆。
    
    最后，连微软也开始承认XBAP确实失败了，并转而把精力集中在Silverlight上。从IE9开始，来自互联网的XBAP内容就默认被禁用了，而备受质疑的Firefox和Chrome插件也不再自动推给用户了。估计XBAP到现在还占有至少10%的安装率，这部分用户还仍然在机器上带着这个复杂且被弃置的无用插件，而且可预期往后的一段日子里这种情况依然如故。

🧓‎🦺✏😇🤞

    
    5.ActiveX Controls
    
    从本质上来说，ActiveX是对象链接和嵌人模型(Object Linking and Embedding，OLE.的继任者，从20世纪90年代开始，OLE技术使得程序能用与具体编程语言无关的标准方式来重用在其他应用里的组件。譬如电子表单(spreadsheet.程序希望能内嵌一个原本在图像编辑软件里的向量图，或者某个简单的游戏想嵌人一个视频播放器，都属于AcitiveX的应用场景。
✊🏦🥛❎🐂‌    
    这一理念本身没什么可争议的，但到了90年代中期微软觉得ActiveX对浏览器也会有意义。毕竟，网站难道就不应该和桌面应用一样，也享受到Windows组件的好处吗？但这种做法实际上侵害了Web的开放性和平台无关性，当然，除此之外，这个想法乍看起来很让人惊叹，就像以下JavaScript例子描述的一样，在Web环境里创建、编辑和保存Excel的电子表单变得轻而易举了：
    
[mw_shl_code=javascript,true]    var sheet = new ActiveXObject(”Excel.Sheet");
    sheet.ActiveSheet.Cells(42,42).Value = "Hi mom!";
🖐🏝🎂🚷🪶‎    sheet.SaveAs("c:\\spreadsheet.xls");
    sheet.Application.Quit();[/mw_shl_code]
    
    即使不谈标准的合规性，微软的做法从安全角度上来说也是场灾难。许多公开的ActiveX组件其实完全未准备好与不信任环境进行互动，在过去15年里，研究人员发现了几百项和通过Web访问的ActiveX组件有关的严重安全漏洞。只要想想看，在第二次浏览器世界大战的初期，Firefox仅靠不支持ActiveX，就树立起了自己的安全形象。
    
🤝🗼🍟✔🐉‍    尽管败绩累累，但微软一直坚定地支持着ActiveX，包括逐渐限制它对互联网的访问能力，并修复了许多微软认为重大的缺陷。一直熬到Internet Explorer 9的发布，微软才终于决定罢手：InternetExplorer9默认禁用了所有的ActiveX访问权限，如果真的要用，需要再额外多点几个选项设置。
    
    注意:实在不太明白这种把选择权完全交给用户的做法是怎么想的，特别是，如果对某个站点授予了权限，那不但会放行了该站点的合法内容，也会放开由于注入导致的任何应用漏洞，如XSS。当然，IE9还算是有进步的。

    👨‍🎨‌🧢🦯🙄🖐
    6.其他插件的情况
    
    说到这里，我们已经讲完了目前会碰到的大部分常规浏览器插件。尽管还有一长串各种专用或者试验性质的插件，但都不算太重要，考量在线整体系统的可靠性时一般可以忽略。
    
    呃，还有一个例外。未知但恐怕有很大比例的在线用户在他们自己还未意识到，或即使觉得可疑也被迫安装了许多能从Web访问到的插件或ActiveX控件，实际上他们根本不可能从这些插件所号称的功能里获得什么好处。👳‍🧢📡😊👆
    
    甚至某些原本令人尊重和信任的公司也采用了这种令人无法原谅的做法。例如，Adobe公司在用户下载Adobe Flash的同时，还要强制安装GetRight，这是一个完全没必要的第三方下载工具。微软开发者站点上的Akamai下载管理器也属此列，它还有一份可笑的声明：
    
    什么是 Akamai Download Manager 以及为什么必须使用它？
    
✍🗼🔪🉑🐝‍    为帮助您在下载大文件时降低传输被中断的概率，某些下载会需要用到Akamai下载管理器。
    
    由于这类软件是强制安装的，且直接暴露于互联网的恶意输入之下，除非设计时做过非常严谨的考虑，否则很有可能会出问题(显而易见，GetRight和Akamai下载管理器都出过问题)。这种只为特定场合才用一、两次而平时浏览网页时完全没必要的插件，所带来的风险已完全超过了它理应带来的好处(实际上这好处也往往不太受欢迎)。