|
Sharon Cohen Rob Franco 微软公司  本页内容
概述 本文的主要内容 本文主要描述了在Internet Explorer 7中，通过默认的“ActiveX Opt-In”特性，减少了开启的ActiveX控件的数量。 本文也描述了一些开发运行在Internet Explorer 中ActiveX控件的最佳实践。这些最佳实践出自安全开发生命周期以及开发和测试用于Internet安全应用的ActiveX控件的开发人员。 ActiveX Opt-In – IE7对ActiveX有什么创新 ActiveX控件对于Internet是非常重要的，因为它允许开发人员通过额外的软件程序来增强Web页面的功能，而不是工作在基本的HTML Web页面下。Web开发人员使用ActiveX控件来添加动画、多媒体和其它特效到他们的Web站点上。 因为ActiveX控件或浏览器的扩展，以及添加Web站点的特效，都会增加安全的风险。Internet Explorer 7 (IE7)将会减少可用于Internet上Web站点的ActiveX控件的数量，并且因此降低了安全的风险。IE7应用重要的控件让用户更加方便地访问常规的站点，用户在应用增强的功能同时，避免通过ActiveX控件面临更多安全风险。 这个IE7的功能称为ActiveX Opt-In。默认情况下，ActiveX Opt-In禁用用户计算机上的控件。当用户遇到禁用控件的Web页面时，将会看到一个显示以下内容的信息栏：“此网站需要安装以下加载项‘XYZ Publisher’中的‘ABC Control’。如果您信任该网站和该加载项并打算安装该加载项，请点击这里”，用户可以从此信息栏选择来开启ActiveX控件，如下图所示：  在用户选择了“运行ActiveX控件”之后，将会出现以下是否允许控件运行的对话框。.  [Caption] 一些ActiveX控件将不会被ActiveX Opt-In禁用：
运行受信任列表中的控件将不会有Opt-In提示弹出，但是如果控件是受信任的，但没有安装到计算机上，用户将不得不通过现有的XPSP2下载行为来获得控件。 ActiveX Opt-In应用到何处？不会应用到哪里？ ActiveX Opt-In应用到运行在Internet Explorer和其它通过特征控制键值管理插件的应用程序中。ActiveX Opt-In可以在IE安全设置面板中启用或禁用。通过设置“允许运行以前未使用的ActiveX控件而不提示”设置项来启用和禁用这个功能。 默认情况下，ActiveX Opt-In应用到Internet和受限站点，而本地Intranet和可信站点不会受到ActiveX Opt-In的影响。  [Caption] 您的控件在受信任列表中么？ 将您的控件列入受信任列表中有时使很有价值的，但根据情况不同会有所区别。以下情况将帮助您决定是否需要将您的控件加入到受信任列表中。 将控件列入受信任列表会引起安全研究组织的注意和安全审查。如果您的控件不在受信任列表中，那么您控件中的任何问题都会暴露大量用户面前。保持您的控件不在受信任列表中，将会保持用户的安全，并且会保护那些没有使用您控件的用户。 以下情况您的控件应该在受信任列表中：
以下情况您的控件不应该在受信任列表中： 您的控件不用于运行在Internet上的页面 如果您的控件不用于运行在Internet上的页面，那么就不应该被列入到受信任列表中。我们强烈建议以下两个步骤来防止控件运行在IE中：
您的控件被下载到用户的计算机上。 如果您的控件不是本地安装在用户的计算机上，那么不需要列入到受信任列表中。当用户下载控件并且选择安装控件时，控件将会被许可。当从确认对话窗口中选择安装之后，用户不会被再次提示。注意：仅有控件的CLSID被包含在对象标签中时才会被许可。如果您有一个单独的cab文件来安装多个控件，则仅有在对象标签中的初始化控件会被许可。您需要预先许可cab文件中的其它控件才能完成安装。 您的控件仅仅用于公司内部网络或用于商业应用程序。 您不应当添加这些控件到受信任列表中。ActiveX Opt-In在intranet区域中默认被关闭，因此您公司的ActiveX控件不会受到影响。当不在Intranet运行的时候，根据区域锁定这些控件或限制他们的功能将是一个很好的主意。 如果您有用于不可发布的商业应用程序的控件，这些控件应当不在受信任列表中。您应该同网络管理员协同工作，以确保用户的计算机能够获得正确的控件许可。这些操作可以可以通过管理加载项组策略或在注册表中添加受信任的控件来完成。 如何将我的控件添加到受信任列表中？ 因为受信任的控件添加到用户系统中直接面对攻击的风险，因此您应当确保您的控件在设计上是安全的。作为您ActiveX控件的所有者，您应该负责设计并且测试它以确保符合本文所描述的最佳实践。添加您的控件到受信任列表中，您需要确保您查看过本文中安全开发最佳实践的内容，并且要确保您控件的执行遵循安全开发ActiveX控件的原则。您也需要确保最大限度地降低您控件的安全风险。 将您的控件加入到受信任列表中，您需要在以下注册表位置写入控件的CLSID： HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Ext PreApproved 如果Microsoft侦测到控件有漏洞并且给最终用户带来了风险，Microsoft保留任何时间从受信任列表中删除控件的权力。 如何构建安全的ActiveX控件 构建安全的ActiveX控件需要设计人员、开发人员和测试人员在产品生命周期始终关注安全问题。设计人员需要限制控件的能力，以保证仅仅满足工作需求，而不会有任何额外的能力。开发人员需要适当地编写控件的代码，并且保障处理数据的安全。测试人员需要测试对控件有潜在威胁的情况。安全在开发生命周期的每个阶段的都十分重要。下面会详细讨论控件开发生命周期的每个阶段。  返回页首设计安全的ActiveX控件的原则 因为ActiveX控件可能会向恶意网站暴露内容，因此设计上的安全是十分重要的。任何站点都能够试图使用控件，所有这些需求也需要控件的类标识符（CLSID）。当您在设计控件时，您首先需要考虑用于正当网页的控件，就像用于您自己的站点。为了安全的运行在Internet区域，您必须在保障在Internet上加载任何页面时，您的控件设计都是安全的，特别是访问恶意的页面时。您需要确保恶意Web站点不能够利用您的控件来伤害用户的系统。您在设计时，需要考虑您控件的功能如何被利用以及如何保护用户。 限制您控件的功能 因为ActiveX控件是微软的Win32组件，所以它可以没有任何限制地运行。您应该考虑如何限制您控件的功能，来防止他人利用您的控件进行恶意的破坏。在考虑编写ActiveX控件时，首先您需要考虑的是，您是否确实需要ActiveX控件来完成您所要实现的功能。如果您不需要访问系统资源，您可以利用动态 HTML (DHTML) 来编写控件。 为了保障您控件的安全，接口需要在满足您功能需求的同时尽可能少的暴露给IDispatch （以及网站）。如果您的函数不是必须输入参数，那么可以删除它们。如果您能够根据已知的输入来缩小输入参数的范围，那么一定照此执行。如果您的控件向本地计算机写入数据，或通过任何方式改变系统的状态和行为，那么需要认真考虑您的控件不会被第三方恶意程序所利用。 以下是在您设计控件时需要考虑的一些场景：
很多ActiveX控件从本地或远程站点的数据初始化，并且很多ActiveX控件被脚本化，能够支持多种方法、事件和属性 。所有持续数据的初始值和使用的控件均通过脚本来请求安全。如果您的控件不读取持续的数据，则不要将它的初始值标记为安全。 将您的控件锁定到站点 一种有效限制您控件功能的方式是锁定它到一个制定的域中运行。如果您的ActiveX控件仅设计为一个特定的Web站点使用，锁定它在该站点的域内，那么其它站点企图恶意使用该控件将变得十分困难。但是，您应该注意到站点锁定不能够保证其它站点一定不能使用您的控件。跨站点脚本和中间攻击能够将您的控件暴露给其它站点。站点锁定应该用于深度防御，不应该被用于首要的防御。 如何将您的控件锁定在一个域内，更多相关信息请查看How To Tie ActiveX Controls to a Specific Domain。 将您的控件锁定到区域 即使您的控件通过站点锁定进行了很多限制，您仍然应当将您的控件锁定到区域。您应当将您的控件锁定到IE工作时的特定区域、Internet、intranet、可信站点、或受限站点。同站点锁定一样，区域锁定也应当用于深度防御，而不是首要的防御。 确保ActiveX运行在最小权限环境下 默认情况下，Windows XP用户通常使用管理员用户登录，因为很多特性和程序不能在非管理员权限下正常运行。在Windows Vista中，将不会出现这种情况，登录的用户默认将不再是管理员。ActiveX控件必须要能够在非管理员环境下运行。此外，当IE保护模式开启时，所有的进程将运行在低权限级别，级别1。控件需要在普通用户账户下进行测试，并且如果可能，甚至应当在这些账户下进行开发。 关于用户账户权限的更多信息请查看Security in Longhorn: Focus on Least Privilege和Understanding and Working in Protected Mode Internet Explorer。 返回页首威胁建模 威胁建模是您用来评估、计划以及降低控件可能面临风险的一个过程。为了更全面地保护控件不受到黑客的攻击，您需要了解对您应用程序的威胁。威胁建模由三个高级别步骤组成：了解攻击者的想法、描绘安全系统和确定威胁。 请您注意，本段仅会表述对威胁建模的概述，并不包含更多细节以及如何学习威胁建模。我们强烈建议您学习威胁建模的其它相关资源。本段最后会列出一些推荐的相关资源。 威胁建模过程 威胁建模过程包含以下几个步骤：
下图展示了威胁建模几个步骤的相互关系。  当您贯穿于整个开发生命周期并且发现了更多关于您控件设计的细节时，您应当添加更多的内容到威胁建模您的威胁建模中。因为在威胁建模中确定的关键资源通常也是对性能和功能所期望的关键资源，您可以根据您的需求来调整您的模型。这是一个标准的、有价值的过程。 数据流图 数据流图（DFD）对于理解您的ActiveX控件是十分有用的工具。创建一个DFD能够帮助您理解控件如何工作，通过分析DFD能够帮助您理解您的控件所面临的威胁。DFD应该是您控件的路线图。应该指出您控件所有的输入和输出参数，控件中的数据流以及处理数据组件相关的信任级别。建议使用不同的图形和线型来表示不同的组件特性。例如，您可以使用：
使用颜色表示具体项目的信任级别
使用这些惯例来约束您的图表。例如您不应该有信任的数据流来自于不信任的数据源。但是，在两个相互信任的组件之间可以有不信任的数据流。这种情况会指出数据流的方法是不可靠的，并且需要接受组件考虑数据的潜在危险。 一旦创建好了您的DFD，您可以检查是否有威胁存在。在您的控件中，红色的组件越多、越远，您控件所面临的威胁也就越多。在您检查DFD时，您需要考虑绿色数据发送到红色项目的位置。这些位置可能会造成信息的泄漏。红色数据发送到绿色项目的位置是另外一个需要认真检查的位置。需要以安全的方式处理不信任的数据。您需要在执行任何不安全操作之前检查检查数据的有效性和安全。要特别关注从外部资源流入您控件的敏感数据，包括：Web页面的脚本、本地计算机上读取的文件、用户输入和从注册表中读取的数据。例如，您有需要写入本地计算机的配置文件，并且您可能认为“我第一次写入这些文件，所以我信任这些数据”。但是，一些第三方恶意软件可能能够访问您的配置文件而不是整个系统。它可能会试图修改您的文件，并且促使您的控件帮助它们做一些它们本不能做的事（如写入其它系统文件、修改注册表、利用缓冲区溢出漏洞等）。 在您检查您的DFD时，最好的策略就是考虑每个数据入口可能的各种威胁。下面将描述STRIDE模型，能够帮助您评估威胁。 更多信息，请查看Guerrilla Threat Modelling。 考虑威胁：STRIDE STRIDE是一种划分已知威胁影响的分类方法。如下英文首字母代表：
当您在考虑控件受到哪些威胁时，您可以使用STRIDE来指导您的研究。 威胁建模的其它资源 在网站上有很多关于威胁建模和保障控件安全的内容，下面仅列出部分内容：
返回页首安全的开发实践 一旦您设计好并且完成您控件的威胁建模，接下来开始进行实现。 防止拒绝服务的攻击 确保在得到错误数据或内容时，控件不会死循环或停止响应。攻击者可能会绑定用户的计算机使用您的ActiveX控件。 安全的内存操作 检查全部输入并且防止缓冲区溢出对安全的ActiveX控件是十分重要的。例如，如果控件收到了一个输入的字符串，没有检查它的长度就放入到固定长度的缓冲区中，这就可能为恶意人员提供了溢出缓冲区的字符串，写入其它信息。某些情况下，这些问题能够被利用来执行一些不安全的操作。作为ActiveX控件的开发者，您需要十分小心。不要认为确定的输入一定会遵守确定的需求。总是要检查数据以避免受到攻击。即使输入没有明确的规格，所有的输入也应该有最大的空间，并且控件应该进行安全测试。更多信息请查看Fix Those Buffer Overruns。 限制拖拽功能 对于用户而言，拖拽功能能够带来更好的交互体验，但是，ActiveX控件需要采用一种可靠的方式来开启拖拽功能。如果您的控件作为拖动的对象，则应当在执行不安全操作时提示用户。如果您的控件是一个拖动源，您应该确保设置成为CFSTR_UNTRUSTEDDRAGDROP剪切板格式。这可以确保任何程序读取拖动的数据时，明确它是否被完全信任。您应该注意到，IE中的拖拽能力受到安全设置的限制，因此可能会限制您控件的拖拽能力(URLACTION_SHELL_ENHANCED_DRAGDROP_SECURITY)。 关于剪切板数据的更多信息，请查看Shell Clipboard Formats 。 IE安全设置中关于拖拽的更多信息，请查看URL Action Flags。 脚本安全和初始化安全 IE有很多种不同的机制来侦测控件的初始化和脚本是否安全。IE使用IObjectSafety 接口和组件分类管理器来进行侦测。 首先要注意到，仅仅要对您确实需要操作的初始化或脚本记控件安全。如果您的控件不需要脚本功能，则不要标记。 IObjectSafety 是IE加载完成后，用于查询控件以及侦测控件是否被安全的初始化和安全的脚本化的接口。组件分类管理器是IE注册自身为安全的方式。IE加载控件之前会首先检查两项注册表设置。 IObjectSafety 接口支持两种方式，IObjectSafety::GetInterfaceSafetyOptions和IObjectSafety::SetInterfaceSafetyOptions。GetInterfaceSafetyOptions 方式会返回控件的安全能力，初始化或脚本是否安全。SetInterfaceSafetyOptions 方式从容器、IE到控件的请求，并且指出了控件应配置自身安全的初始化或脚本化。 组件分类管理器是IE使用注册表来侦测控件是否安全初始化和脚本的方式。您应该确定安装您的控件时注册它到组建分类管理器。关于注册表键值的详细信息请查看How to mark MFC ActiveX controls as Safe for Scripting and Initialization。 更多关于通过IObjectSafety和组件分类标记ActiveX控件安全初始化和脚本的信息，请查看Safe Initialization and Scripting for ActiveX Controls。 在本地机器区域中操作的控件 ActiveX控件在本地机器中操作不应该允许任意内容由Internet不经用户交互，就直接写入到指定位置的文件中。此外，控件在本地机器中操作不应允许直接或间接执行任意的代码。 设计您的控件有数据执行保护的功能 数据执行保护（DEP）是执行额外内存检查的一套硬件和软件技术，它能够防止恶意代码运行在系统中。DEP可用于Microsoft Windows 2003 Server SP1，Windows XP Service Pack 2，Windows XP Tablet PC Edition 2005，和Windows Vista上。 DEP通过阻止内存数据中没有标记为EXECUTABLE代码的执行来完成工作，就像堆和栈。强制硬件DEP侦测从这些位置运行的代码，并且在执行发生时进行阻止。强制软件DEP是强制硬件DEP的子集，很多计算机没有支持DEP的处理器，强制软件DEP能够阻止恶意代码在Windows中执行。 有了DEP功能的控件不能执行任何被标记为不可执行页面上的代码。注意，如果您使用ATL，那么ATL 7.1和更早的版本不支持DEP功能，您需要在ATL8.0或之后的版本中进行编译。 IE提供了可以测试您控件DEP功能的设置。在IE中，打开工具－Internet选项 －高级标签，检查“Enable memory protection to help mitigate online attacks”设置。（注意如果您是在Windows Vista中运行，此设置仅能在保护模式关闭时进行修改。一旦此功能被启用，您可以运行在保护模式。）您应当使用IE设置来测试您的控件，并且确保它和DEP兼容。一旦您的代码和DEP兼容，您应当使用/NXCOMPA链接您的代码。  关于改变功能的信息，请查看Microsoft Windows XP Service Pack 2, Part 3: Memory Protection Techniques和A Detailed Description of the Data Execution Prevention (DEP) Feature。 使用自动化的工具来评估您的代码 代码复查和品质测试时非常有价值的，能够发现并且改正很多问题和风险，但是，有了自动化的工具能够复查您的代码，并且标记出潜在的问题所在。微软发布的PreFast就是其中之一。它是Visual Studio Team System 2005中的一部分，也包含在Windows DDK中。PreFast检查您源代码的所有执行路径并且会检查以下位置的错误：
这种自动代码检查方式能够极大地增加您代码的安全性，并且在测试后也能够减少程序缺陷的数量。 更多关于PreFast的信息，请查看PREfast Step-by-Step。 为您的控件数字签名 您控件上的数字签名能够使得用户来检验控件的发布者，并且确保发布后没有被篡改。数字签名能够帮助用户在安装控件时做出更好的信任决定，并且能够帮助用户在Internet Explorer 中的管理加载项中识别您的控件。 如果您希望用户能够简便地安装您的控件，数字签名控件非常重要的。用户不希望安装没有签名的控件，并且没有签名的控件默认会被阻止安装。 Internet Explore的管理加载项对话框显示所有用户系统上加载项的信息。（打开对话框，从工具菜单中选择管理加载项。）签名您的控件将会确保发布者能够正确显示在列表中。您可以查看下面的图片，一些发布者显示为“（Not Verified）”－说明这些控件没有被签名。  如果您的控件通过一个CAB文件或其它可执行文件安装，您必须签名了所有的安装文件（为了能够安装）和包含ActiveX控件的.dll或ocx文件（为了确保您的发布者名称不会显示为“Not verified”）。 在管理加载项对话框名称栏中显示的名称从以下注册表设置中读取： HKEY_CLASSES_ROOT CLSID {Control CLSID} AppName="contose.exe" (Default)=(REG_SZ)"Control Name" LocalizedStringPolicy=(REG_SZ) Localized Control Name 如果您有其它语言的名称，则设置LocalizedString来指向您控件源文件中包含其它语言名称的源ID。管理加载项首先会检查此值，如果已设定就使用它。如果没有设定，则会显示默认值，通常是英文名。 更多信息请查看以下资源：
如何判定控件的安全性 控件的安全性是主观上的判断。以下设计好的问题能够帮助您考虑您控件的安全性。您可以使用这些问题作为您大量安全复核的一部分。
在您设计控件时，还有一些其它通用的问题：
另外，推荐将以下信息编辑成文档。
安全的测试实践 使用以下四项实践来验证控件是否安全。 基于在威胁建模中已识别的威胁创建测试案例 对于在威胁建模中已识别的每个威胁，您都应当创建测试案例。测试案例应该确定已识别的威胁是否会通过您控件的设计或执行而减轻。设计和开发文档会描述控件如何运行，但只有测试才能够证实控件确实如此运行。 渗透测试 渗透测试是测试人员围绕应用程序的安全特性，在本案例中就是一个控件，所作的安全测试。渗透测试包括拒绝服务、网络压力测试以及用于控件的所有文件格式的模糊测试，但不仅仅只限于这几项。渗透测试应当验证任何外在的访问控制，如ACL，并且也要验证处理不信任数据所有代码的正确性。您也应当测试控件潜在的任何安全风险。例如，如果您对您的控件进行了站点锁定，您应当测试在其它Web站点上进行测试，以确定站点锁定是否被正确执行。 模糊测试 模糊测试应当在任何加载数据的ActiveX控件上执行。模糊测试用于提供在您控件上没有错误输入的结构。这种测试方法需要大量的测试案例，通过大量的数据变化和转换来测试您的控件。通常，使用自动工具来进行模糊测试。模糊测试的目标不是要确保在错误的数据上控件也能正常执行，而是要确保在得到错误的数据时您的控件能够以安全的方式运行。您的控件在得到错误数据时应当不会崩溃或引起缓冲区溢出。 模糊测试应当在您控件的以下区域执行：
在选择您控件上的模糊数据时需要考虑两种不同的参数。首先您应当考虑是否使用智能还是非智能数据生成。这两种窗体的不同之处很像黑盒和白盒测试的不同。非智能数据生成，就像黑盒测试，生成的输如不考虑数据格式或处理函数。智能数据生成 就像白盒测试，生成的输入是基于正确的数据结构和控件流程的。接下来应当考虑在生成数据时，是否会生成新的数据或改变正确的数据。当进行非智能模糊测试时，生成新的错误数据可能更适合。改变正确的数据更适用于智能模糊测试。对于很多控件，您应当结合使用智能和非智能测试，既生成新的测试数据也改变已有的其它数据。 回归测试 回归测试确保代码的改变不会破坏任何功能。回归测试需要在开发周期的每个主要阶段进行。不仅对于控件的功能，对于控件的安全，回归测试也是十分重要的。 感谢 感谢以下人员为此文所作的贡献： David Ross、Philip Nachreiner、Eric Lawrence、Mike Friedman、Patrick Mann, Levent Besik、Cullen Sauls、Josh Cain、和Madhuvan Gupta。
|
