正 文

Visual Studio 2005:在组织内部采用 Visual Studio Express


www.7dspace.com  更新日期:2006-2-2 8:35:52  七度空间


启用安全性

如上所述,安全性是 Express 版本的关键设计目标。它既能在默认情况下实现 Visual Studio 产品套件本身的安全性,而且还提供一个安全开发环境,并允许开发人员在默认情况下轻松生成安全的应用程序。构思了这些目标之后,需要有大量的关键功能帮助实现这一目标:

内置 Web 服务器:对于生成 Web 应用程序的开发人员而言,一个最大的约束是需要在开发计算机上安装 Internet 信息服务。站在管理立场看,这经常会引发激烈的争辩,因为 IT 员工现在必须确保每台开发人员计算机上运行的 Web 服务器不受 Web 服务器的攻击,并且不能从本地网络之外进行访问。此外,通常还需要开发人员具备 Web 服务器的管理权限,使他们能够在开发、配置设置和调试其应用程序的过程中更有效地工作。

要处理这些以及其他一些问题,Visual Web Developer 2005 Express 版本配备了一个内置的 Web 服务器,该服务器在开发环境内部运行。最初,该配置相对于之前的环境而言似乎有一些麻烦且安全性较低。但是,通过最小化攻击面并因此降低了危险,大量安全功能为安全部署做好了准备。这些功能如下所示。

配置内置的 Web 服务器,以便只能接受本地系统的请求。这样,它就不能从网络的其他主机进行访问,并因此免受通过网络利用 Web 服务器漏洞的恶意攻击。

内置于 Express 版本的 Web 服务器不使用通常由 HTTP 服务器使用的、标准的 80 端口。相反,端口号随机选取并在每次启动 Visual Studio 环境时进行分配。这再次确保了恶意攻击或试图发现并使用 Web 服务器的软件无功而返。

内置 Web 服务器带来的结果是,终端开发人员不再需要在计算机上完全安装 IIS Web 服务器或修改该服务器的设置。该功能使开发人员无需具备其开发计算机的管理员用户身份即可编写代码。尽管该功能本身在安全性方面非常出色,但是相应而生的好处是:在无需管理员权限的情况下,它还使开发人员更能意识到其应用程序能够(和不能够)执行的操作。因此,开发人员几乎可以全神贯注地生成应用程序,而不再需要管理员权限。

内置 Web 服务器的使用会带来一些部署问题。然而,其中最主要的问题是从内置 Web 服务器迁移到运行完整 IIS Web 服务器的生产系统的方式和时机。答案经常取决于组织的策略。应用程序是否得到部署,IT 管理员或开发人员是否能够将应用程序发布到产品 Web 服务器,已确定并且进行了安全地配置。实际上,Visual Studio 环境本身就提供这种功能。因此,管理员只需关注对产品系统的维护,并且无需对开发人员计算机进行额外管理。此外,在本文后面的内容中,我们还会描述,管理员如何使用代码访问安全性策略来控制这一过程,以及控制应用程序本身的执行。

IntelliSense-in-zone Debug-in-zone:IntelliSense -in-zone(区域内智能感知)功能可以与代码访问安全性策略一起使用,以帮助开发人员正确选择在其应用程序中使用的 API。在 Visual Basic 中运行时,智能感知功能提供可视化的反馈,从而让开发人员了解在当前执行区域内不可用的任何 API,以及引起应用程序违反安全策略的 API。例如,如果从本地企业内部网内执行,应用程序只能读取默认的“用户名”环境变量。因此,IntelliSense-in-zone 功能将可视化地标记违反该策略的任何尝试,例如试图访问其他环境变量。

Debug-in-zone(区域内调试)功能也有点类似,它帮助实现同一个目标。在这种情况下,开发人员进行代码调试就像是在一个特定区域内,或利用定义的代码访问安全性策略执行代码。因此,开发人员能够及早地检测到违规并了解每个区域提供的执行沙盒。

通过在开发过程中为开发人员提供这些工具,开发人员能够预先进行正确的选择并避免代价高昂的重新编码和部署,前提是这些问题仅出现在产品阶段。这样还能让开发人员轻松地编写在指定沙盒中执行的代码,然后管理员能利用它控制与应用程序(由使用 Express 版本的非专业开发人员创建)相关的访问权限。

ClickOnce:ClickOnce 是一种新的应用程序部署技术,它试图使部署一个基于 Windows 窗体的应用程序像部署一个 ASP.NET Web 应用程序那样简单。站在最终用户角度看,通过 ClickOnce 运行一个 Windows 窗体应用程序就像在 Web 页面上单击一个链接一样简单。对于管理员也如此,部署或更新这样一个应用程序就像更新服务器上的适当文件一样简单,无需修改每个单独的客户端。因此, ClickOnce 应用程序基本上是低影响、完全独立且每用户安装的。重要的是,开发人员不需要以管理员身份对本地系统进行访问。同样,不存在 ClickOnce 应用程序中断其他应用程序的危险,因为它们独立于客户系统上的其他应用程序运行。但应该注意,如果安装时应用程序不需要执行复杂或特权操作(如,安装设备驱动程序),则组织会很好地利用 MSI。虽然其后续过程更棘手、更复杂,但管理员还希望 ClickOnce 解决更复杂的情况。

ClickOnce 应用程序可通过 Web 服务器、文件服务器或 CD 进行部署。这样的应用程序可选择在本地计算机上安装,即在“开始”菜单和“添加或删除程序”中创建项;或应用程序只能从其当前位置和缓存中运行。 ClickOnce 应用程序还提供一些自打检查应用程序更新的手段。应用程序还以选择使用 System.Deployment 命名空间下的 ClickOnce API,从而可以更细粒度地控制更新发生的时间和方式。

Express 产品具有对 ClickOnce 部署技术丰富的本机支持。开发人员可以选择从 Visual Studio 本身发布应用程序,同时开发环境将自动创建启动 ClickOnce 过程必需的 XML 清单文件。很明显,管理员希望能够灵敏地控制谁可以向哪些服务器进行发布,本文会提供一些特殊的建议(例如使用授权),请查看本文的其他建议一节。

ClickOnce 应用程序在由代码访问安全性策略提供的安全沙盒中运行。即,上面描述的 IntelliSense-in-zone 和 Debug-in-zone 工具可在开发过程中为希望创建 ClickOnce 应用程序的开发人员提供巨大的帮助。使用诸如 PermCalc.exe 这样的工具还可以帮助开发人员准确识别应用程序成功执行所需的权限,帮助他们比较授予区域(应用程序将从这里执行)的权限。对于需要较高权限集合来执行的应用程序而言,ClickOnce 模型既支持用户进行决策,也支持以管理员身份定义的、基于预部署安全策略的方法。

部分信任开发部分信任的应用程序以简化的权限运行,从而使它们无需写入文件系统的任意组件;无需与 Internet 主机(除源主机之外)连接;无需执行授权的操作(例如,调用非托管代码)。这些限制旨在保护底层主机的安全免遭因被怀疑的应用程序中漏洞的波及,保护其他运行于同一台服务器上的应用程序。这在共享主机方案(有外包提供程序),以及组织在同一计算机上运行多个 Web 应用程序时都相当普遍。

在 .NET Framework 和 Visual Studio 的早期版本中,创建部分信任的应用程序并不轻松。开发人员工具不可用,也许甚至更重要的是,部分信任沙盒受到严格的限制,以至于创建任何有意义的、以部分信任方式成功运行的应用程序几乎是不可能完成的任务。该版本的一个主要的目标是安全性,因此,用 .NET Framework 2.0 版本和 Visual Studio 2005 编写代码是相当简单且真正合理的。尽管一些更改对您有所帮助(例如,上述的 PermCalc.exe、Debug-in-zone 和 IntelliSense-in-zone),但下面的内容讨论了一些关键的更改,这些更改使创建真实的部分信任应用程序这一目标至少实现了一部分:

部分信任的开发人员最终具备与数据库连接的能力。利用以默认的中等信任权限集授权的 SQLPermission 和 SQLNotificationPermission,开发人员能够进行诸如使用 System.Data.SQLClient 命名空间的类与 Microsoft SQL 数据库连接这样的操作。因此,开发人员现在可以生成丰富的 2 层和 3 层应用程序,尽管依旧以部分信任执行应用程序,但这些应用程序可以利用后端数据库进行永久存储。该版本提出的以完全信任运行应用程序的真正原因只有一个:如果 Web 应用程序必须通过 P/Invokes 或 COM Interop 利用旧式代码。如果使用一个非 Microsoft SQL Server 数据库,则开发人员可以选择使用 .NET Framework 中可用的 OleDb 类。尽管 OleDbPermission 不是 ASP.NET 默认的中等或高信任权限,但开发人员可以选择将该特定的权限添加到一个自定义的代码访问安全策略中,然后使用它。只有 .NET Framework 2.0 中的 OleDb 提供程序不再需要完全的信任并且是可访问的,这种情况才可能发生。

与 SQLClient 命名空间类似,发送电子邮件的功能是大量应用程序需要的另一种功能。.NET Framework 2.0 具有一个新权限 SmtpPermission,它包含在 ASP.NET 2.0 Web 应用程序默认的部分信任权限中。该权限反过来由 SmtpClient 类使用。

曾经备受争议的 SecurityException 现已在 .NET Framework 2.0 中得到了显著增强。此外,关键的目标是让开发人员更轻松地解密引发异常的主体以及开发人员本身缺失但需要的权限。因此,开发人员能够轻松地决定他们是试图避免该操作还是将缺失的权限添加到权限组。该新的异常对象已紧密集成到 Express 版本以及 Visual Studio 2005 的全部产品之中。在调试期间引发这种异常时,IDE 将观察该对象的全部属性值,然后为开发人员显示区分上下文的帮助和丰富的反馈,使他们能够了解问题的症结所在。

.NET Framework 2.0 还提供一个简单的沙盒 API,在信任的宿主应用程序中,它可以通过插件或第三方组件的形式用于执行非受信代码。因此,宿主可以选择它希望授权非受信代码的权限。特别是,启用该机制的方法是 AppDomain.CreateDomain 方法的一种新的重载。类似地,引入 AppDomainManager 类还旨在允许宿主应用程序能够更细粒度地控制操作集合,宿主代码允许执行该操作集合,实际上即该代码的常规执行。该机制易于约束和限制由新手和非专业开发人员创建的应用程序。

在 .NET Framework 以前的版本中,一个名为 AllowPartiallyTrustedCallersAttribute(或 APTCA)的属性可用于允许部分信任代码调用通常在全局程序集缓存 (Global Assembly Cache,GAC) 中运行的强命名代码。没有该属性,部分信任的代码将不能隐式要求由强命名程序集引入的全部信任。尽管该机制旨在帮助部分信任的开发人员调用系统函数和公共库,但它也会存在诱发攻击的危险。标记为 APTCA 的程序集现在可由任意的部分信任代码调用,这样也可能被 Web 应用程序(而非最初希望的应用程序)进行非法调用。这种强命名程序集经常会在执行授权操作之前断言特定的权限,以停止在完全信任的签名程序集中进行堆栈审核,并防止它传播回可能失败的部分信任代码。一个代码访问安全断言几乎可看作是一种提升或授权,因此必须非常仔细地处理。要帮助更轻松地管理和处理 APTCA 程序集,.NET Framework 2.0 引入安全性透明这一概念。将程序集标记为安全性透明会让运行时了解,该程序集从未打算执行断言,因此,任何断言权限的调用将导致引发异常。同样,应用程序可标记为临界安全性,这意味着程序集通常是安全性透明的,但也许有一些功能或属性需要断言,所以将以一个特定的安全性临界属性进行标记。因此,任意调用权限断言的企图都将导致一个异常(除了带有安全性临界属性的代码块)。除了可以帮助开发人员更轻松地编写更好更安全的代码以外,该功能也可简化代码审核者查看标记为 APTCA 代码的工作,并使其更高效。通过 FxCop 分析工具,还对该功能提供了自动支持。

.NET Framework 2.0 还引入了一个 HostProtectionAttribute,应用程序可使用它来通知运行库,其中的某些功能可能潜在地破坏底层主机、应用程序本身或应用程序内外的线程。这是另一种让开发人员权衡使用默认软件编写安全代码的机制,该机制以某种防止系统安全受到威胁的方式处理潜在的错误。

重点要说明的是,上面列出的功能仅代表 Express 版本和 .NET Framework 中可用功能的一小部分,它们可用于启动安全性,并防止非专业的开发人员创建可能导致将组织的重要数据暴露给恶意用户的应用程序。本文的其他内容关注管理员能够防止漏洞的其他手段,同时还使开发新手了解这些内容并更有效地工作。

3页,页码:[1] [2] [3] 

上一篇:用ASP.NET 2.0改进的ViewState加快网站速度
下一篇:编写 SQL 查询:让我们从基础知识开始
标题:Visual Studio 2005:在组织内部采用 Visual Studio Express 作者:Rudolph Araujo 来源:MSDN
收藏此页】【打印】【关闭
站 内 搜 索
 

热 点 导 读
特 别 推 荐