ActiveX安全



ActiveX安全:改进和最佳实践

Sharon Cohen

Rob Franco

微软公司


*
本页内容
概述概述
设计安全的ActiveX控件的原则设计安全的ActiveX控件的原则
威胁建模威胁建模
安全的开发实践安全的开发实践

概述
本文的主要内容

本文主要描述了在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禁用:

1.

一般用途的控件以及被设计用于安全审查的控件将不会禁用。这些控件将会出现在受信任列表中。

2.

升级到IE7之前已经在IE中使用的控件。

3.

用户通过IE7下载和安装过程中被自动开启的控件。

运行受信任列表中的控件将不会有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]


您的控件在受信任列表中么?

将您的控件列入受信任列表中有时使很有价值的,但根据情况不同会有所区别。以下情况将帮助您决定是否需要将您的控件加入到受信任列表中。

将控件列入受信任列表会引起安全研究组织的注意和安全审查。如果您的控件不在受信任列表中,那么您控件中的任何问题都会暴露大量用户面前。保持您的控件不在受信任列表中,将会保持用户的安全,并且会保护那些没有使用您控件的用户。

以下情况您的控件应该在受信任列表中:

?

您的控件是由Windows或OEM预安装在用户机器上的ActiveX控件。.

通过Windows或OEM安装的控件将会被ActiveX Opt-In 禁用,除非之前许可了该控件。预先许可您的控件将会确保用户访问您的Web站点有最好的体验,正如您和用户所期待的那样。

?

您的控件用于在Internet区域页面中运行

在安装您的应用程序进程中,ActiveX控件也被安装来用于运行在Internet上,您可能会希望添加这些控件到受信任列表中。由于控件是通过软件被安装的,而不是通过用户安装,因此控件将会被ActiveX Opt-In 禁用。

以下情况您的控件不应该在受信任列表中:


您的控件不用于运行在Internet上的页面

如果您的控件不用于运行在Internet上的页面,那么就不应该被列入到受信任列表中。我们强烈建议以下两个步骤来防止控件运行在IE中:

?

Killbitting控件将确保控件不会在IE中加载。Killbitting控件仅需要设置注册表键值,并且非常容易完成。

?

不要标记控件为安全的初始化或执行脚本。您应该确保在组件栏中以及在通过IObjectSafety 机制时都不标记为安全。

您的控件被下载到用户的计算机上。

如果您的控件不是本地安装在用户的计算机上,那么不需要列入到受信任列表中。当用户下载控件并且选择安装控件时,控件将会被许可。当从确认对话窗口中选择安装之后,用户不会被再次提示。注意:仅有控件的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 (以及网站)。如果您的函数不是必须输入参数,那么可以删除它们。如果您能够根据已知的输入来缩小输入参数的范围,那么一定照此执行。如果您的控件向本地计算机写入数据,或通过任何方式改变系统的状态和行为,那么需要认真考虑您的控件不会被第三方恶意程序所利用。

以下是在您设计控件时需要考虑的一些场景:

?

您的控件需要多少以及何种类型的参数?您能够减少这些参数的数量或尽可能地限制它们接受数据的类型么?

?

控件是否依赖于页面的URL来做出安全决定?如何控件不能从Internet Explorer 中获得页面的URL,会发生什么情况?安全设置是否会失效?

?

控件是否被设计成为能够调用页面中的包括Java程序在内的其它对象?在页面上通过控件调用微软虚拟机(Microsoft VM)可能会比调用脚本得到更大的权限。如果脚本能够利用控件调用微软虚拟机,则可能会发生间接的攻击。

?

控件能否穿透架构访问另一个架构的内容?被访问的数据可能潜在地暴露了用户的隐私。您必须限制控件运行在特定的域内来保护用户的隐私。

很多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 PrivilegeUnderstanding and Working in Protected Mode Internet Explorer


返回页首返回页首

威胁建模

威胁建模是您用来评估、计划以及降低控件可能面临风险的一个过程。为了更全面地保护控件不受到黑客的攻击,您需要了解对您应用程序的威胁。威胁建模由三个高级别步骤组成:了解攻击者的想法、描绘安全系统和确定威胁。

请您注意,本段仅会表述对威胁建模的概述,并不包含更多细节以及如何学习威胁建模。我们强烈建议您学习威胁建模的其它相关资源。本段最后会列出一些推荐的相关资源。


威胁建模过程

威胁建模过程包含以下几个步骤:

1.

识别安全目标: 明确的目标能够帮助您关注威胁建模,并且帮您确定在后面的步骤中花费多少努力。.

2.

创建一个控件摘要:详细列出您应用程序的重要特征和元素,能够帮助您在步骤4识别相关的威胁。

3.

分解您的控件: 详细地理解您控件的结构,可以使您更容易地找到有关详细的可能的威胁。

4.

识别威胁:通过步骤2和步骤3的细节,识别您控件所处环境下的威胁。

5.

识别问题: 重新查看您控件的各个层面来识别相关的问题。使用问题分类有助于您关注到经常出现问题的区域。

下图展示了威胁建模几个步骤的相互关系。


.


当您贯穿于整个开发生命周期并且发现了更多关于您控件设计的细节时,您应当添加更多的内容到威胁建模您的威胁建模中。因为在威胁建模中确定的关键资源通常也是对性能和功能所期望的关键资源,您可以根据您的需求来调整您的模型。这是一个标准的、有价值的过程。


数据流图

数据流图(DFD)对于理解您的ActiveX控件是十分有用的工具。创建一个DFD能够帮助您理解控件如何工作,通过分析DFD能够帮助您理解您的控件所面临的威胁。DFD应该是您控件的路线图。应该指出您控件所有的输入和输出参数,控件中的数据流以及处理数据组件相关的信任级别。建议使用不同的图形和线型来表示不同的组件特性。例如,您可以使用:

?

矩形代表外部实体

?

圆形代表您控件的数据处理组件

?

实线代表您的组件和外部实体内部或相互之间的数据流

?

虚线代表信任边界、设备边界、过程边界或其它“有意义”的转换

使用颜色表示具体项目的信任级别

?

红色项目代表不信任

?

橙色项目代表部分信任

?

绿色项目代表信任

使用这些惯例来约束您的图表。例如您不应该有信任的数据流来自于不信任的数据源。但是,在两个相互信任的组件之间可以有不信任的数据流。这种情况会指出数据流的方法是不可靠的,并且需要接受组件考虑数据的潜在危险。

一旦创建好了您的DFD,您可以检查是否有威胁存在。在您的控件中,红色的组件越多、越远,您控件所面临的威胁也就越多。在您检查DFD时,您需要考虑绿色数据发送到红色项目的位置。这些位置可能会造成信息的泄漏。红色数据发送到绿色项目的位置是另外一个需要认真检查的位置。需要以安全的方式处理不信任的数据。您需要在执行任何不安全操作之前检查检查数据的有效性和安全。要特别关注从外部资源流入您控件的敏感数据,包括:Web页面的脚本、本地计算机上读取的文件、用户输入和从注册表中读取的数据。例如,您有需要写入本地计算机的配置文件,并且您可能认为“我第一次写入这些文件,所以我信任这些数据”。但是,一些第三方恶意软件可能能够访问您的配置文件而不是整个系统。它可能会试图修改您的文件,并且促使您的控件帮助它们做一些它们本不能做的事(如写入其它系统文件、修改注册表、利用缓冲区溢出漏洞等)。

在您检查您的DFD时,最好的策略就是考虑每个数据入口可能的各种威胁。下面将描述STRIDE模型,能够帮助您评估威胁。

更多信息,请查看Guerrilla Threat Modelling


考虑威胁:STRIDE

STRIDE是一种划分已知威胁影响的分类方法。如下英文首字母代表:

?

Spoofing 允许对手作为另一个用户、组件或在已经建模的其它系统中的身份

?

Tampering 是在系统中恶意的数据修改

?

Repudiation 因为系统没有足够的证据,使得对手否认执行过恶意行为的能力

?

Information Disclosurerefers 将保护的数据暴露给无权限访问数据的用户

?

Denial of Service 对手组织合法用户使用系统的正常功能

?

Elevation of Privilege 使用非法手段来获得比当前验证更高的信任级别

当您在考虑控件受到哪些威胁时,您可以使用STRIDE来指导您的研究。


威胁建模的其它资源

在网站上有很多关于威胁建模和保障控件安全的内容,下面仅列出部分内容:

?

Threat Modeling resources on MSDN

?

Threat Modeling,Frank Swiderski和Window Snyder编写

?

Writing Secure Code,Michael Howard和David LeBlanc编写

?

Threat Modeling Tool


返回页首返回页首

安全的开发实践

一旦您设计好并且完成您控件的威胁建模,接下来开始进行实现。


防止拒绝服务的攻击

确保在得到错误数据或内容时,控件不会死循环或停止响应。攻击者可能会绑定用户的计算机使用您的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 TechniquesA Detailed Description of the Data Execution Prevention (DEP) Feature


使用自动化的工具来评估您的代码

代码复查和品质测试时非常有价值的,能够发现并且改正很多问题和风险,但是,有了自动化的工具能够复查您的代码,并且标记出潜在的问题所在。微软发布的PreFast就是其中之一。它是Visual Studio Team System 2005中的一部分,也包含在Windows DDK中。PreFast检查您源代码的所有执行路径并且会检查以下位置的错误:

?

内存: 潜在的内存泄漏,废弃的空指针,访问未初始化的内存,过度使用内核模式堆栈以及标记符的不正确使用。

?

资源: 释放资源失败被锁定,调用函数时应当保持的资源,以及调用其它函数时不应保持的资源。

?

函数用法: 潜在的错误的函数使用,函数出现错误,函数类型使用不当,如不正确的检查类型,可能使用失效的函数,以及函数调用使用了错误的IRQL。

?

不固定的指针状态: 在驱动中保护不固定的硬件指针状态发生错误,以及在保存它为不同的IRQL之后试图修复不固定的指针状态。

?

优先规则: 由于C的优先规则,代码可能不表现为程序员设想的样子。

?

内核模式代码实践: 代码实践可能会引起错误,如修改内存描述符列表(MDL)结构,通过调用函数检查变量失败,以及使用C/C++字符串处理函数而不是在Ntstrsafe.h中的安全字符串。

?

特殊驱动的代码实践: 特殊的操作通常是内核模式驱动错误的根源,如没有修改成员就复制完全的I/O请求包(IRP)以及使用拷贝在DriverEntry 程序中的内容来代替保存字符串或结构体的内容。

这种自动代码检查方式能够极大地增加您代码的安全性,并且在测试后也能够减少程序缺陷的数量。

更多关于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。管理加载项首先会检查此值,如果已设定就使用它。如果没有设定,则会显示默认值,通常是英文名。

更多信息请查看以下资源:

?

Signing and Checking Code with Authenticode

?

Introduction to Code Signing


如何判定控件的安全性

控件的安全性是主观上的判断。以下设计好的问题能够帮助您考虑您控件的安全性。您可以使用这些问题作为您大量安全复核的一部分。

?

您能限制域或区域的使用么?查看站点锁定章节可以得到更多信息。

?

您是否在网络上暴露了用户的隐私信息或暴露给了其他用户?

?

您能够在如文件系统、注册表、照相机或其它USB设备上读、写、创建、检查或删除持续的数据么?。

?

这个控件是否使得数据从Internet的一个站点传递到另外一个站点?或者从本地计算机传递到Internet上?

?

这个控件能加载其它代码或脚本么?如果可以,这些代码和脚本来自哪里?

?

这个控件会引起强制性的操作或者在不通知用户的情况下执行程序么?

?

这个控件是否会绕过浏览器、操作系统或其它应用程序中的安全功能?

?

Web页面使用此控件会引起系统的不稳定或停止响应么?

?

这个控件是否会在用户不知情的情况下运行?

?

跨站点脚本攻击是否会利用此控件呢?

?

此控件是否加载自己的数据格式?这种数据类型是否有自身的安全执行?此种数据类型是否允许大量使用?

?

历史、统计或调试信息会一直存在本地计算机么?用户能够清除这些信息么?这些信息是否会被发送到网络中?是否有全球唯一标识符(GUID)用于跟踪用户?

在您设计控件时,还有一些其它通用的问题:

?

从网络得到的字符串是否经过验证、分析或过滤?这些字符串会带来什么?如果它们包含脚本,会发生什么?这些脚本传递到其它组件后会产生什么效果?

?

在哪可能会发生缓冲区溢出?您是否对所有方法、属性和事件进行了完全的缓冲区溢出测试?

?

如何停止外部站点调用控件?

?

如果您没有标记控件为“安全的脚本”或“安全的初始化”,是否要使您的控件失效呢?默认情况下,控件会被标记为不安全脚本或不安全的数据初始化。不要使用它们,除非控件的函数需要它们。

?

控件展现给用户的信息是否是真实的呢?您是否需要对控件进行数字签名呢?

另外,推荐将以下信息编辑成文档。

?

方法

?

属性

?

CLSID

?

事件

?

所有者

?

DLL/OCX名称和版本


安全的测试实践

使用以下四项实践来验证控件是否安全。


基于在威胁建模中已识别的威胁创建测试案例

对于在威胁建模中已识别的每个威胁,您都应当创建测试案例。测试案例应该确定已识别的威胁是否会通过您控件的设计或执行而减轻。设计和开发文档会描述控件如何运行,但只有测试才能够证实控件确实如此运行。


渗透测试

渗透测试是测试人员围绕应用程序的安全特性,在本案例中就是一个控件,所作的安全测试。渗透测试包括拒绝服务、网络压力测试以及用于控件的所有文件格式的模糊测试,但不仅仅只限于这几项。渗透测试应当验证任何外在的访问控制,如ACL,并且也要验证处理不信任数据所有代码的正确性。您也应当测试控件潜在的任何安全风险。例如,如果您对您的控件进行了站点锁定,您应当测试在其它Web站点上进行测试,以确定站点锁定是否被正确执行。


模糊测试

模糊测试应当在任何加载数据的ActiveX控件上执行。模糊测试用于提供在您控件上没有错误输入的结构。这种测试方法需要大量的测试案例,通过大量的数据变化和转换来测试您的控件。通常,使用自动工具来进行模糊测试。模糊测试的目标不是要确保在错误的数据上控件也能正常执行,而是要确保在得到错误的数据时您的控件能够以安全的方式运行。您的控件在得到错误数据时应当不会崩溃或引起缓冲区溢出。

模糊测试应当在您控件的以下区域执行:

?

控件中的任何方法l

?

所有控件使用的参数

?

从远程资源得到的任何数据,例如您得到一个URL,您不仅应当模糊测试URL本身,还需要测试从URL下载的所有文件。

在选择您控件上的模糊数据时需要考虑两种不同的参数。首先您应当考虑是否使用智能还是非智能数据生成。这两种窗体的不同之处很像黑盒和白盒测试的不同。非智能数据生成,就像黑盒测试,生成的输如不考虑数据格式或处理函数。智能数据生成 就像白盒测试,生成的输入是基于正确的数据结构和控件流程的。接下来应当考虑在生成数据时,是否会生成新的数据或改变正确的数据。当进行非智能模糊测试时,生成新的错误数据可能更适合。改变正确的数据更适用于智能模糊测试。对于很多控件,您应当结合使用智能和非智能测试,既生成新的测试数据也改变已有的其它数据。


回归测试

回归测试确保代码的改变不会破坏任何功能。回归测试需要在开发周期的每个主要阶段进行。不仅对于控件的功能,对于控件的安全,回归测试也是十分重要的。

感谢

感谢以下人员为此文所作的贡献: David Ross、Philip Nachreiner、Eric Lawrence、Mike Friedman、Patrick Mann, Levent Besik、Cullen Sauls、Josh Cain、和Madhuvan Gupta。



返回页首返回页首
本文来自http://www.microsoft.com/china/MSDN/library/NetComm/ActiveX+Security.mspx?mfr=true






Microsoft


ActiveX安全 - Alaric - 记录在编程世界里成长的历程
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
需要用来获得所需的功能在步骤涉及到 IObjectSafetyImpl 用作您的控件派生的类之一,和重写 GetInterfaceSafetyOptions 和 SetInterfaceSafetyOptions。 这使您实现所需的功能在这种情况下意味着将标记为可安全编写脚本和初始化该控件。 若要将 IObjectSafetyImpl 需要将其添加到您的控件派生的类的列表。 是例如多边形教程中您看到以下: class ATL_NO_VTABLE CPolyCtl : ... public IObjectSafetyImpl // ATL's version of // IObjectSafety { public: BEGIN_COM_MAP(CPolyCtl) ... COM_INTERFACE_ENTRY_IMPL(IObjectSafety) // Tie IObjectSafety // to this COM map END_COM_MAP() STDMETHOD(GetInterfaceSafetyOptions)(REFIID riid, DWORD *pdwSupportedOptions, DWORD *pdwEnabledOptions) { ATLTRACE(_T("CObjectSafetyImpl::GetInterfaceSafetyOptions\n")); if (!pdwSupportedOptions || !pdwEnabledOptions) return E_FAIL; LPUNKNOWN pUnk; if (_InternalQueryInterface (riid, (void**)&pUnk) == E_NOINTERFACE) { // Our object doesn't even support this interface. return E_NOINTERFACE; }else{ // Cleanup after ourselves. pUnk->Release(); pUnk = NULL; } if (riid == IID_IDispatch) { // IDispatch is an interface used for scripting. If your // control supports other IDispatch or Dual interfaces, you // may decide to add them here as well. Client wants to know // if object is safe for scripting. Only indicate safe for // scripting when the interface is safe. *pdwSupportedOptions = INTERFACESAFE_FOR_UNTRUSTED_CALLER; *pdwEnabledOptions = m_dwSafety & INTERFACESAFE_FOR_UNTRUSTED_CALLER; return S_OK; }else if ((riid == IID_IPersistStreamInit) || (riid == IID_IPersistStorage)) { // IID_IPersistStreamInit and IID_IPersistStorage are // interfaces used for Initialization. If your control // supports other Persistence interfaces, you may decide to // add them here as well. Client wants to know if object is // safe for initializing. Only indicate safe for initializing // when the interface is safe. *pdwSupportedOptions = INTERFACESAFE_FOR_UNTRUSTED_DATA; *pdwEnabledOptions = m_dwSafety & INTERFACESAFE_FOR_UNTRUSTED_DATA; return S_OK; }else{ // We are saying that no other interfaces in this control are // safe for initializing or scripting. *pdwSupportedOptions = 0; *pdwEnabledOptions = 0; return E_FAIL; } } STDMETHOD(SetInterfaceSafetyOptions)(REFIID riid, DWORD dwOptionSetMask, DWORD dwEnabledOptions) { ATLTRACE(_T("CObjectSafetyImpl::SetInterfaceSafetyOptions\n")); if (!dwOptionSetMask && !dwEnabledOptions) return E_FAIL; LPUNKNOWN pUnk; if (_InternalQueryInterface (riid, (void**)&pUnk) == E_NOINTERFACE) { // Our object doesn't even support this interface. return E_NOINTERFACE; }else{ // Cleanup after ourselves. pUnk->Release(); pUnk = NULL; } // Store our current safety level to return in // GetInterfaceSafetyOptions m_dwSafety |= dwEnabledOptions & dwOptionSetMask; if ((riid == IID_IDispatch) && (m_dwSafety & INTERFACESAFE_FOR_UNTRUSTED_CALLER)) { // Client wants us to disable any functionality that would // make the control unsafe for scripting. The same applies to // any other IDispatch or Dual interfaces your control may // support. Because our control is safe for scripting by // default we just return S_OK. return S_OK; }else if (((riid == IID_IPersistStreamInit) || (riid == IID_IPersistStorage)) && (m_dwSafety & INTERFACESAFE_FOR_UNTRUSTED_DATA)) { // Client wants us to make the control safe for initializing // from persistent data. For these interfaces, this control // is safe so we return S_OK. For Any interfaces that are not // safe, we would return E_FAIL. return S_OK; }else{ // This control doesn't allow Initialization or Scripting // from any other interfaces so return E_FAIL. return E_FAIL; } } ... } ATL 3.0 中, IObjectSafetyImpl 的实现已更改,使您现在可以作为模板参数提供安全选项。 例如,上述类的声明将显示为 class ATL_NO_VTABLE CPolyCtl : ... public IObjectSafetyImpl { public: BEGIN_COM_MAP(CPolyCtl) ... ,您将不必重写两个方法。 有关其他信息,单击下面,文章编号,以查看 Microsoft 知识库中相应: 192093 PRB: 编译器错误时移植到 ATL 3.0 IObjectSafetyImpl

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值