Visual Basic .NET 和 Visual C# .NET 程序员需要解决的安全问题

Visual Basic .NET 和 Visual C# .NET 程序员需要解决的安全问题
Robin Reynolds-Haertle
Visual Studio Team
Microsoft Corporation
2002 年 1 月

摘要：本文着重讨论了 Visual Basic .NET 和 Visual C# .NET 开发人员在开始使用 .NET 框架时需要解决的主要安全问题。此概述讨论了 Windows 应用程序和 Web 应用程序，以及开发过程的实现、调试和部署阶段。

本文适用于 Visual Studio .NET 和 .NET 框架的最终版本。如果您使用的是预发布版本，则其中应用程序的运行可能与本文所讨论的略有不同。

目录

• 简介
• 代码访问安全性
  • 完全信任
  • 部分信任
  • 部分信任环境的开发
  • 测试
  • 其他资源
• Web 应用程序
  • 动态发现
  • 身份验证、模拟和委托
  • ASPNET 进程标识
  • 在 ASPNET 标识下运行时保护文件资源的安全
  • 使用 ASPNET 标识进行调试
• Visual Studio .NET 开发环境中的安全机制
• 总结

简介

与早期版本的 Visual Studio 相比，Microsoft? Visual Studio? .NET 为应用程序的运行提供了更好的安全控制。.NET 框架提供了更多的控制，同时也要求您承担更多的编程责任。在为用户创建友好易用的应用程序时，您需要解决一些安全问题。

通常在以下三种情况下需要解决安全问题：

• 运行您的应用程序的用户可能拒绝该应用程序的权限，因为应用程序所运行的位置已被指定为拒绝该用户访问某些系统资源。例如，用户可以通过配置公共语言运行时来拒绝存储在网络驱动器上的所有应用程序的文件权限。您在编写代码时应注意此问题，并且应编写代码对这种拒绝作出恰当的回应。
• 需要防止从您的 Web 服务器访问 Web 应用程序的用户在服务器上运行恶意代码或破坏数据。
• Visual Studio 的设置方式将或多或少地使服务器面临受到恶意代码攻击的危险。

代码访问安全性

代码访问安全性是 .NET 框架的一个系统，它通过控制代码的执行来控制对资源的访问。这种安全功能独立于操作系统提供的安全性，并且是对操作系统提供的安全性的补充。当用户运行您的应用程序时，应用程序将由 .NET 公共语言运行时分配到五个区域之一。这五个区域是：

• 我的电脑 - 用户计算机上的应用程序。
• 本地 Intranet - 用户的 Intranet 上的应用程序。
• Internet - 来自 Internet 的应用程序。
• 可信站点 - 来自由 Internet Explorer 定义为“可信”站点的应用程序。
• 不可信站点 - 来自由 Internet Explorer 定义为“受限”站点的应用程序。

上述每个区域都由系统管理员设置了特定的访问权限。可以将每个区域的安全级别设置为完全信任、中级信任、低级信任或不信任。信任级别定义了应用程序可以访问的资源。区域与其他安全凭证（例如发布者、强名称、Web 站点以及代码的 URL）一起确定在运行时授予该代码的权限。您无法控制用户计算机上的安全设置，但您的应用程序在运行时仍会受到即时设置的限制。这就意味着应用程序可能会被拒绝访问某些特定资源。例如，应用程序可能需要将数据写入文件，但用户的系统将通过引发异常而拒绝在运行时进行写入访问。有关安全凭证的详细信息，请参阅 Evidence（英文）。

您的工作就是开发应用程序来处理这种情况。这并不表示让您的应用程序用另外一种方法来写入数据，而是说您的应用程序应该预计到可能无法写入数据，然后对这种可能性作出响应。您可能需要使用更多的异常处理（Visual Basic 中的 Try...Catch 或 C# 中的 try...catch）或 System.Security.Permissions 命名空间中的某些对象，以使应用程序代码更加可靠。本文后面“部分信任环境的开发”一节对这些方法进行了简要说明。

区域的安全级别可以通过随 .NET 框架一起安装的“管理工具”来进行设置。有关在计算机上设置区域安全级别的详细信息，请参阅 Administration Tools（英文）。

完全信任

开发人员通常在完全信任环境中工作。他们将源代码存放在硬盘驱动器上，并在用于开发的计算机上对其应用程序进行测试。在这种完全信任环境中，开发人员编译的任何代码都可以在本地计算机上运行。由于本地计算机被默认定义为完全信任环境，因此不会出现安全异常。

部分信任

部分信任是指完全信任区域以外的所有区域。部署应用程序时，应用程序可能会移至新的区域，而新区域可能不完全信任应用程序。在部分信任环境中运行代码的两种最常见的情况是：

• 运行从 Internet 下载的代码。
• 运行驻留在网络共享位置 (Intranet) 的代码。

在部分信任区域中可能会被拒绝访问的资源示例包括：

• 文件 I/O，包括文件的读取、写入、创建、删除或打印。
• 系统组件，如注册表值和环境变量。
• 服务器组件，包括目录服务、注册表、事件日志、性能计数器和消息队列。

在部分信任环境中哪些内容是不允许的呢？这不太容易确定。.NET 框架中的每个类以及每个类中的每种方法都有一个安全属性，用于定义运行该方法所需的信任级别，并且正是由于这些安全功能，使得在运行时可能无法访问该属性。区域级别并不只是信任级别到属性的简单映射，而是一个授予特定类和方法的特定权限的集合。您的应用程序无法只是简单地查询信任级别然后就可以预计哪些资源不可用。您可以确定应用程序是否在完全信任环境中运行。在下一节“部分信任环境的开发”中，我们将介绍一种方法。

部分信任环境的开发

本节简要介绍了安全问题可能会对编写的代码产生什么样的影响。部分信任环境的开发没有单一的解决方案。您的解决方案取决于您所编写的应用程序。此外，由于信任级别在应用程序的执行过程中可能会发生变化，因此不能仅测试现有的信任级别，然后就继续执行。

开发部分信任区域的第一步是编写能够识别即将发生安全异常的代码。请注意以下代码：

' Visual Basic Public Sub MakeABitmap() Dim b As Bitmap = New Bitmap(100, 100) ' 此处的代码将以位图格式绘制一张漂亮的图片 b.Save("c:/PrettyPicture.bmp") End Sub // C# public void MakeABitmap() { Bitmap b = new Bitmap(100, 100); // 此处的代码将以位图格式绘制一张漂亮的图片 b.Save("c://PrettyPicture.bmp"); }

如果项目和项目程序集存储在您计算机的硬盘驱动器上，并且您是计算机 Administrators 组的成员，则此方法在运行时不会引发异常。如果将此应用程序部署到您的 Intranet，则当应用程序试图保存位图对象时，将引发 System.Security.SecurityException（请参阅 SecurityException Class [英文]）。如果此代码周围没有 Try...Catch（在 Visual Basic 中）或 try...catch（在 C# 中）块，则应用程序将因异常而终止。这会令用户感到不满意。如果您添加异常处理代码，应用程序就能够：

• 警告用户应用程序无法完成所有需要完成的任务。
• 清除所有现有对象，以便 catch 块后面的代码能够成功运行。

您可以按如下所示修改保存位图的代码。添加的代码将警告用户该文件因安全性被拒绝而未能保存，从而将安全性失败与文件 I/O 失败（例如不正确的文件名）区分开来。这种方法不会产生任何安全漏洞。用户应修改安全设置以信任您的应用程序，否则应用程序将不会运行。

' Visual Basic Public Sub MakeABitmap() Dim b As Bitmap Try b = New Bitmap(100, 100) b.Save("c:/PrettyPicture.bmp") Catch ex As System.Security.SecurityException ' 告知用户保存失败。 MessageBox.Show("拒绝授予保存该文件的权限，" & _ "未保存此位图。") Catch ex As System.Exception ' 此处对其他异常作出反应。 MessageBox.Show(ex.Message) End Try End Sub // C# public void MakeABitmap() { Bitmap b = null; try { b = new Bitmap(100, 100); b.Save("c://PrettyPicture.bmp"); } catch (System.Security.SecurityException ex) { // 告知用户保存失败。 MessageBox.Show("拒绝授予保存该文件的权限，" + "未保存此位图。"); } catch (System.Exception ex) { // 此处对其他异常作出反应。 MessageBox.Show(ex.Message); } }

使用 System.Security.Permissions（英文）命名空间中的类、属性和枚举，可以对应用程序中安全任务进行更多的控制。如果您在编写可从其他应用程序调用的库，则可以让库验证调用代码的权限。例如，您只需在代码文件的顶部添加以下程序集级别的属性。加载该程序集时，运行时将验证权限。如果运行时拒绝所请求的权限，程序集将无法加载并且将引发一个安全异常。如果向独立的应用程序添加此属性，则应用程序可能不会运行。如果此属性出现在类库中，则可能不会在运行时加载该库。您需要在调用此类库的代码中添加 try/catch 块。

' Visual Basic 
  
  
   
    // C# [assembly: System.Security.Permissions.FileIOPermissionAttribute( SecurityAction.RequestMinimum, Write="c://PrettyPicture.bmp")]
  
  

您也可以专门向运行时请求权限，下面的示例中使用了 Demand 方法。运行时可能允许或拒绝该请求。拒绝请求是通过引发安全异常来实现的。您可以按如下所示重新编写代码，以明确请求写入位图文件的权限：

' Visual Basic Public Sub MakeABitmap()  Dim filename As String = "c:/PrettyPicture.bmp"  Dim permission As FileIOPermission = _  New FileIOPermission(FileIOPermissionAccess.Write, _  filename) Dim b As Bitmap = Nothing Try b = New Bitmap(100, 100)  permission.Demand() b.Save(filename) Catch ex As System.Security.SecurityException ' 告知用户保存失败。 MessageBox.Show("拒绝授予保存该文件的权限，" & _ "未保存此位图。") Catch ex As System.Exception ' 此处对其他异常作出反应。 MessageBox.Show(ex.Message) End Try End Sub // C# using System.Security.Permissions; public void MakeABitmap() {  string filename = "c://PrettyPicture.bmp";  FileIOPermission permission = new   FileIOPermission(FileIOPermissionAccess.Write,   filename); Bitmap b = null; try { b = new Bitmap(100, 100);  permission.Demand(); b.Save(filename); } catch (System.Security.SecurityException ex) { // 告知用户保存失败。 MessageBox.Show("拒绝授予保存该文件的权限，" + "未保存此位图。"); } catch (System.Exception ex) { // 此处对其他异常作出反应。 MessageBox.Show(ex.Message); } }

测试

开发部分信任区域的第二步是在多个环境中进行测试，尤其是在您的 Intranet 和 Internet 上。这将强制引发安全异常。

其他资源

除了上面的概述中介绍的内容外，还有许多其他内容可供选择。以下主题更详细地讨论了代码访问安全性：

• Introduction to Code Access Security（英文）
• Code Access Security（英文）
• Security Namespaces in Visual Studio（英文）

Web 应用程序

解决 Web 应用程序的安全问题，可以保护您的服务器免受恶意代码的攻击，并保护数据不被破坏。您可以使用多种方法来保护服务器。

• 通过禁用 XML Web services 的动态发现功能来禁止用户查找和运行您的 XML Web services。
• 在允许用户访问服务器之前，通过身份验证来验证用户的标识。
• 通过使用 ASPNET 进程标识，可以更好地调整用户可以使用的资源。

下面将详细讨论每一种方法。

动态发现

动态发现是 .NET 框架的一项功能，它允许 Web 浏览器查找在服务器上运行的 XML Web services。找到 XML Web service 后，用户就可以调用该 XML Web services 的方法。动态发现虽然为用户提供了强大的功能，但同时也给服务器带来潜在的安全危险。多数情况下，您不需要启用动态发现功能。安装 .NET 框架时，动态发现在默认情况下处于禁用状态。这并不表示 XML Web services 不可用，而只表示服务器将不提供可用服务的目录。客户端仍然可以使用 XML Web services，但您需要向其提供该服务的确切位置。

警告：禁用动态发现后，您需要将 XML Web services 的位置发送给客户端。

在部署服务器上，有两个项可以控制 XML Web services 的发现功能。第一项（machine.config 文件）控制服务器的整体发现功能。machine.config 文件是一个包含控制服务器上 Web 应用程序的设置的 XML 文件，它位于 /%windows%/Microsoft.NET/Framework/Version/Config 文件夹。此文件包含一个默认情况下被注释掉的元素。要启用发现功能，您需要删除这些注释字符。还需要使用 ASPNET 帐户来运行应用程序，如下一节“ASPNET 进程标识”中所述。

第二项是一个发现文件。发现文件可以是默认的发现文件 (default.vsdisco)，也可以是 XML Web services 特定的发现文件。它是一个 XML 文件，包含有关 XML Web services 文件位置的信息。

要客户端能够发现特定的 XML Web services，您需要在 machine.config 文件中启用发现功能，并创建和部署应用程序的发现文件。发现文件是一个仅列出不包含 XML Web services 的路径的 XML 文件。下面提供了一个示例。有关创建和部署此文件的完整说明，请参阅 Deploying XML Web Services in Managed Code（英文）。

如果您的部署服务器安装有 Visual Studio .NET，则 Web 根文件夹将包含默认的发现文件 (default.vsdisco)，该文件是在 Visual Studio .NET 的安装过程中创建的。如果服务器中包含此文件并且在 machine.config 文件中启用了发现功能，则可以发现服务器上的所有 XML Web services。如果要禁止发现 XML Web services，则需要删除此文件。

警告：如果部署服务器安装了 Visual Studio .NET，则在服务器投入使用之前应该删除 default.vsdisco 文件。

建议您不要在已安装 Visual Studio .NET 的服务器上部署 XML Web services。Visual Studio .NET 安装程序会将可以使用的文件和用户都添加到您的系统上。您可以保护已安装 Visual Studio .NET 的系统的安全，但是，如果不需要在部署服务器上安装 Visual Studio .NET，建议您不要安装。

有关启用动态发现的详细信息，请参阅 Enabling Discovery for an XML Web services（英文）和 Fine-Tuning Discovery Mechanisms（英文）。

身份验证、模拟和委托

默认情况下，Web 应用程序将以匿名模式运行，也就是说，应用程序不需要任何有关用户标识的信息。这对于那些包含公共信息的站点非常适用。如果要对访问应用程序或其他资源的用户进行控制，则需要向应用程序添加身份验证。身份验证是识别应用程序的用户并验证该用户是否有权访问此应用程序的过程。ASP.NET 支持多种身份验证方法。其中最常用的方法有：

• 匿名   无需用户提供任何标识信息。此方法适用于包含公共内容的 Web 站点。如果需要个性化站点，则可以使用 cookie。有关在 ASP.NET 应用程序中使用 cookie 的详细信息，请参阅 Introduction to Web Forms State Management（英文）。
• 窗体   应用程序向用户提供一个登录窗体，要求用户提供登录信息（如姓名和密码）。窗体将被发送回服务器，服务器将该信息与数据仓库进行比较。
• 基本   基本身份验证是使用 Internet 信息服务 (IIS) 配置的，大部分浏览器都支持基本身份验证。如果启用，浏览器将提示用户输入姓名和密码，然后用 Base64 编码（此编码易于解密）将信息传回 ASP.NET 应用程序。此方法要求用户拥有 Windows 帐户。如果在基本身份验证之外再使用安全套接字层 (SSL)，则可以确保此身份验证方法的安全性。有关 ASP.NET 中的 SSL 支持的信息，请参阅 Using Secure Sockets Layer（英文）。
• 简要   简要身份验证是使用 IIS 配置的，可用于运行 Microsoft Windows? 2000 或 Windows XP 的服务器。简要身份验证提供了比基本身份验证更高的密码加密级别。此方法要求用户拥有存储在 Microsoft Active Directory? 中的 Windows 帐户。
• 集成 Windows   集成 Windows 身份验证类似于基本身份验证和简要身份验证，唯一区别是用户的姓名和密码不传回 Web 应用程序。此方法尤其适用于 Intranet 环境。它要求用户拥有 Windows 帐户，并且只有 Internet Explorer 浏览器支持该方法。
• 证书   证书是安装在计算机中的数字密钥。当用户试图访问服务器时，需要提供此密钥。然后服务器在域或 Active Directory 中对该证书进行验证。此方法适用于那些需要高度安全性而不惜付出管理证书成本的应用程序。
• Passport   Microsoft 提供了这种集中的身份验证服务。Passport 身份验证适用于以下情况：当您的 Web 站点与其他 Passport 站点一起使用时，使用户只需登录一次就能够访问所有站点；或者您不想维护用户数据库。

身份验证允许您为应用程序的用户授权，但这并不足以使用户能够访问资源，例如文件和数据库。您可以对资源进行配置，使其对特定的用户（而不是 Web 应用程序本身）可用。在这种情况下，可以使用模拟来允许用户访问这些资源。使用模拟时，服务器进程以通过身份验证的用户标识来运行。当应用程序使用模拟并查询数据库时，数据库应用程序在处理查询时会认为查询来自用户，而不是服务器。如下例所示，可以通过在应用程序的 Web.config 文件中设置 identity 元素的 impersonate 属性来启用模拟。Web.config 文件作为每个 Web 应用程序项目的一部分而创建。

比模拟更进一步的是委托，委托在访问远程资源（其他计算机）时使用用户标识。如下表所示，并非所有的身份验证方法都支持委托。

支持委托	不支持委托
基本	匿名
集成 Windows	简要
证书	Passport
	窗体

有关选择和实施身份验证方法的详细论述，请参阅 Authentication in ASP.NET:.NET Security Guidance（英文）。有关 Web 应用程序安全性的详细信息，请参阅 Web Application Security at Run Time（英文）。

ASPNET 进程标识

当 Web 应用程序开始在服务器上运行时，它并不是像以您（Web 应用程序的作者）的身份登录那样运行。而是像使用服务器上定义的一个 Windows 用户帐户登录那样运行。该帐户（也称作标识）可以是以下三个帐户之一：ASPNET 标识、SYSTEM 标识或自定义标识。该标识是在 machine.config XML 文件（位于服务器的 /%windows%/Microsoft.NET/Framework/Version/Config 文件夹中）中指定的。以下所示是该元素三种配置方法的简化示例。文件中的元素具有若干个属性，此示例中并未显示出来。

ASPNET 是在随 .NET 框架安装 machine.config 文件时所选择的默认标识。ASPNET 帐户是 Users 组的成员，默认情况下，Users 组只拥有最小的权限。ASPNET 帐户还拥有其他几个权限，其中包括对 ASP.NET 和 Windows 临时目录的全部权限。

如果将标识更改为 SYSTEM，则应用程序将在 SYSTEM 标识下运行，该标识拥有 Administrators 组的权限。SYSTEM 帐户几乎可以访问服务器上的所有资源。

警告：如果服务器在 SYSTEM 标识下运行，受恶意代码攻击和数据遭到破坏的危险非常大。

要使用自定义标识，必须创建帐户并按特定方式配置其权限。有关创建自定义标识的详细信息，请参阅 Authentication in ASP.NET:.NET Security Guidelines（英文）。

默认情况下，有几种系统资源对 ASPNET 帐户不可用。下面概要介绍了常见的限制和解决方案。建议您使用 ASPNET 帐户和所介绍的解决方案，而不要在 SYSTEM 标识下运行应用程序。

• 文件资源   可以通过 Windows 资源管理器访问各个文件和文件夹的访问控制列表 (ACL)，来调整授予 ASPNET 帐户的文件和文件夹权限。对 ASPNET 的 ACL 的更改不会自动通过部署传播。例如，您可能允许 ASPNET 帐户对开发计算机上的 c:/picture.bmp 文件拥有写入权限。当部署应用程序时，应用程序将在另一台计算机上运行，该计算机也具有 ASPNET 帐户。您需要在部署计算机上为 ASPNET 帐户添加对部署计算机上 c:/picture.bmp 文件的写入权限。幸运的是，您可以在部署项目中使用自定义操作对 ACL 进行更改，但必须对所要做的更改进行跟踪。
• 事件日志   ASPNET 帐户可以向现有日志添加条目，但不能创建新的事件日志类别。这时您可以在使用 ASPNET 帐户时启用模拟，以便创建新的事件日志类别。模拟标识必须具有足够的权限才能创建事件日志类别。如果应用程序需要的事件日志可以在投入使用前指定，则可以由部署项目来创建这些日志。
• 目录服务和 Active Directory   要对它们进行访问，需要使用模拟和委托，或者将特定的安全凭据传递给 DirectoryEntry 对象。如果选择将特定安全凭据传递给 DirectoryEntry 对象，则需要确保已正确存储此信息。
• 性能计数器   ASPNET 帐户只能写入而不能读取性能计数器，并且不能创建新的性能计数器类别。这时您可以在使用 ASPNET 帐户时启用模拟，以便创建新的性能计数器类别。模拟标识必须具有足够的权限才能创建性能计数器类别。如果应用程序需要的性能计数器可以在投入使用前指定，则可以由部署项目来创建这些性能计数器。

在 ASPNET 标识下运行时保护文件资源的安全

注意：本节中的说明适用于运行 NTFS 文件系统的系统。如果您的服务器运行的是 FAT32 文件系统，请参阅文件系统说明文件，了解有关保护文件安全的信息。

默认情况下，ASPNET 帐户只拥有 Users 组的读取和执行权限。如果 Web 应用程序需要写入或创建新文件，则可以通过修改访问控制列表 (ACL) 为特定文件和文件夹授权。要访问某个文件的 ACL，可以在 Windows 资源管理器中右击该文件，然后依次选择“属性”和“安全”选项卡。最好是修改特定文件的 ACL，而不是向 ASPNET 帐户添加通用权限。最常使用的权限包括：

• 读取 - 数据文件和可执行文件需要读取权限。
• 写入 - 由应用程序更新的数据文件需要写入权限。
• 执行 - 在 Web 应用程序中，.asmx 文件为可执行文件。
• 创建 - 要创建文件，需要为要在其中创建文件的文件夹添加创建权限。

这些权限适用于：

• 文件
• 文件夹

  警告：应避免允许对同一文件或目录同时拥有执行权限和写入或创建权限。在这种情况下，用户可能会设法在文件中写入恶意代码，然后再执行。

以下是有关简化授权过程的一些技巧：

• 根据应用程序中文件所需的权限，将文件分别放入不同的目录。例如，如果在一个目录中只存放读取/执行文件，则只需要为一个目录设置这些权限，而不必单独为每个文件设置权限。请考虑在应用程序中为读取/执行、读取/写入和读取/创建权限分别创建目录。
• 应用程序可以包含在部署时为空的数据文件，还可以包含首次运行应用程序时创建文件所需的代码。这需要为目录添加创建权限，这是一种较高的安全设置。为了避免添加代码来创建新的空文件，请考虑在部署时即给应用程序提供一个空文件。这样，您只需给该文件添加写入权限，而不必给目录添加创建权限。

在开发应用程序时，您将为开发计算机上的文件和目录添加权限，以便精确调整应用程序的安全级别。不幸的是，ACL 不会被传递到部署计算机上的相应文件。要规划传递这些 ACL，请记住以下几点：

• 可以在部署程序包中使用自定义操作来更改 ACL。有关详细信息，请参阅 Custom Actions（英文）。
• 可以使用第三方工具来跟踪和查找所做的更改。
• 可能需要同系统管理员确认每一个设置。您需要记录进行更改的原因，以及为什么必须通过更改设置来达到目的。

使用 ASPNET 标识进行调试

调试 XML Web services 时，如果在 machine.config 文件中定义了 ASPNET 标识，将使用该标识来调用此 XML Web services。默认情况下，ASPNET 标识不是 Debugger Users 组的成员（请参见下一节“Visual Studio .NET 开发环境中的安全机制”），因此不能在调试过程中访问 XML Web services 代码。要调试 XML Web services，请打开 XML Web services 的代码并设置一个断点。

建议您在测试计算机（而不是部署计算机）上进行调试。这将在下一节“Visual Studio .NET 开发环境中的安全机制”中讨论。

有关配置进程标识的详细信息，请参阅 ASP.NET Process Identity（英文）和 ASP.NET Impersonation（英文）。

Visual Studio .NET 开发环境中的安全机制

除了保护服务器的安全外，还要保护开发计算机免受恶意代码的攻击和数据破坏。您可以利用开发环境中的多种机制来保护开发服务器的安全：

VS Developers 和 Debuggers   安装 Visual Studio .NET 时将添加这两个帐户组。VS Developers 组具有在服务器上创建和开发 Web 应用程序的必要文件、共享和 IIS 权限。Debuggers 组可以在特定计算机（本地或远程）上调试进程。这两个组都是服务器上具有很大权限的用户，可以访问大多数资源。有关详细信息，请参阅 Web Application Security at Design Time in Visual Studio（英文）。

调试   建议您在测试计算机（而不是部署计算机）上进行调试。如果必须在部署服务器上调试，请仅安装远程调试组件，并在完成调试后卸载该组件。请在脱机状态下调试服务器。有关详细信息，请参阅 Introduction to Web Application Debugging（英文）。

部署   对于大多数应用程序，只需要在服务器上安装 .NET 框架就足够了。如果在部署计算机上安装了 Visual Studio .NET 或 Visual Studio .NET 服务器组件，则 VS Developers 组和 Debuggers 组都将出现在部署计算机上。您需要对 VS Developers 的成员和 Debugger 用户加以限制。此外，可能还需要禁用动态发现。

警告：强烈建议您不要在部署服务器上安装 Visual Studio。

Visual Studio .NET 的“复制项目”功能包括使用配置文件 (Web.config) 部署应用程序的选项，该配置文件不同于开发中所使用的配置文件。开发文件可能启用了调试，在部署后，将允许用户在引发异常时检查调用堆栈。建议您使用不允许调试的配置文件进行部署。

总结

保护资源的安全是一个涉及多种技术和整个开发周期的过程。通过对应用程序进行周密的设计、实现、测试和部署，您可以创建非常安全的应用程序。可以使用由 ASP.NET、操作系统和 Web 浏览器提供的安全技术来保护应用程序的安全。