.net入门常见问题有哪些？

使用 IIS 创建 ASP.NET Web 应用程序根目录

本演练步骤向您说明如何使用 Internet 信息服务 (IIS) 将某个目录标记为应用程序根目录。此演练说明如何创建虚拟目录并将 C:/Inetpub/Wwwroot 目录设置为应用程序的根目录。

准备此次演练

创建一个新目录。此演练使用 C:/myWebApp 目录。
接下来，为 IIS 打开 Microsoft 管理控制台 (MMC)，并使用下列过程之一创建一个虚拟目录。

使用 Windows Server 2003 系列产品创建虚拟目录

单击“开始”，指向“管理工具”，然后单击“Internet 信息服务”。
展开“本地计算机”节点（这可能由您的计算机名称表示），展开“网站”，然后单击“默认网站”。
在“操作”菜单上单击“新建”，然后单击“虚拟目录”。
在“虚拟目录创建向导”中，单击“下一步”。
在“别名”文本框中输入您的应用程序名称，然后单击“下一步”。
输入为准备此演练而创建的物理目录 C:/myWebApp，然后单击“下一步”。
在“访问权限”页中，选中您的应用程序所需的访问权限，然后单击“下一步”。
单击“完成”。
使用 Windows XP 创建虚拟目录

单击“开始”，然后单击“控制面板”。
如果尚未完成以上操作，单击“切换到传统型视图”。
双击“管理工具”，然后单击“Internet 信息服务”。
展开“本地计算机”节点（这可能由您的计算机名称表示），展开“Web 站点”，然后单击“默认 Web 站点”。
在“操作”菜单上单击“新建”，然后单击“虚拟目录”。
在“虚拟目录创建向导”中，单击“下一步”。
在“别名”文本框中输入您的应用程序名称，然后单击“下一步”。
输入为准备此演练而创建的物理目录 C:/myWebApp，然后单击“下一步”。
在“访问权限”页中，选中您的应用程序所需的访问权限，然后单击“下一步”。
单击“完成”。
使用 Windows 2000 创建虚拟目录

单击“开始”，指向“程序”，指向“管理工具”，然后单击“Internet 服务管理器”。
展开“本地计算机”节点（这可能由您的计算机名称表示），展开“Web 站点”，然后单击“默认 Web 站点”。
在“操作”菜单上单击“新建”，然后单击“虚拟目录”。
在“虚拟目录创建向导”中，单击“下一步”。
在“别名”文本框中输入您的应用程序名称，然后单击“下一步”。
输入为准备此演练而创建的物理目录 C:/myWebApp，然后单击“下一步”。
在“访问权限”页中，选中您的应用程序所需的访问权限，然后单击“下一步”。
单击“完成”。
也可以在 Inetpub/Wwwroot 中的现有目录下创建应用程序根目录。为准备此演练，请在目录 C:/Inetpub/Wwwroot 下创建一个目录。如前所述，将其命名为 myWebApp。

使用 IIS 将 Inetpub/Wwwroot 中的现有目录标记为 Web 应用程序

将 MMC 打开到“默认 Web 站点”，过程同前。
在“默认 Web 站点”中，单击要指定为应用程序根目录的子目录。在本例中，为 myWebApp。
右击要作为应用程序根目录的目录，然后单击“属性”。
在“虚拟目录”选项卡的“应用程序设置”节中，单击“创建”。
在“应用程序名”文本框中，输入应用程序的名称，然后单击“确定”。

ASP.NET 配置文件相关

可扩展的基础结构是 ASP.NET 配置系统的一大特色，该基础结构使您可以在最初部署 ASP.NET 应用程序时定义配置设置，以便可以随时添加或修改这些配置设置，同时对运作着的 Web 应用程序和服务器产生的影响也将被减至最校

ASP.NET 配置系统提供以下好处：

配置信息存储在基于 XML 的文本文件中。您可以使用任何标准的文本编辑器或 XML 分析器来创建和编辑 ASP.NET 配置文件。
多个配置文件（名称都是 Web.config）可以出现在 ASP.NET Web 应用程序服务器上的多个目录中。每个 Web.config 文件都将配置设置应用于它自己的目录和它下面的所有子目录。子目录中的配置文件可以提供除从父目录继承的配置信息以外的配置信息，子目录配置设置可以重写或修改父目录中定义的设置。名为 systemroot/Microsoft.NET/Framework/versionNumber/CONFIG/Machine.config 的根配置文件提供整个 Web 服务器的 ASP.NET 配置设置。
在运行时，ASP.NET 使用分层虚拟目录结构中 Web.config 文件提供的配置信息为每个唯一的 URL 资源计算一组配置设置。然后缓存结果配置设置，以供所有后面的对资源的请求使用。请注意，继承是由传入请求路径 (URL) 定义的，而不是到磁盘上资源的文件系统路径（物理路径）定义的。
ASP.NET 检测对配置文件的更改并自动将新配置设置应用于受该更改影响的 Web 资源。不需要重新启动服务器让更改生效。只要层次结构中的配置文件被更改，就将自动重新计算并重新缓存分层配置设置。 节例外。
ASP.NET 配置系统是可以扩展的。您可以定义新配置参数并编写配置节处理程序以对它们进行处理。
ASP.NET 通过配置 Internet 信息服务 (IIS) 防止对配置文件的直接浏览器访问来保护配置文件不受外部访问。向任何试图直接请求配置文件的浏览器返回 HTTP 访问错误 403（禁止）。

ASP.NET 资源的配置信息包含在一组配置文件中，每个文件都名为 Web.config。每个配置文件都包含 XML 标记和子标记的嵌套层次结构，这些标记带有指定配置设置的属性。因为这些标记必须是格式正确的 XML，所以标记、子标记和属性是区分大小写的。标记名和属性名是 Camel 大小写形式的，这意味着标记名的第一个字符是小写的，任何后面连接单词的第一个字母是大写的。属性值是 Pascal 大小写形式的，这意味着第一个字符是大写的，任何后面连接单词的第一个字母也是大写的。true 和 false 例外，它们总是小写的。

所有配置信息都驻留在 和 根 XML 标记之间。标记间的配置信息分为两个主区域：配置节处理程序声明区域和配置节设置区域。

配置节处理程序声明出现在配置文件顶部 和 标记之间。包含在

安装有公共语言运行库的每台计算机都具有称为全局程序集缓存的计算机范围内的代码缓存。全局程序集缓存中存储了专门指定给由计算机中若干应用程序共享的程序集。

应当仅在需要时才将程序集安装到全局程序集缓存中以进行共享。一般原则是：程序集依赖项保持专用，并在应用程序目录中定位程序集，除非明确要求共享程序集。另外，不必为了使 COM interop 或非托管代码可以访问程序集而将程序集安装到全局程序集缓存。

注意  在有些情况下，您显然不希望将程序集安装到全局程序集缓存中。如果您将组成应用程序的某个程序集置于全局程序集缓存中，则将不再能够通过使用 xcopy 命令复制应用程序目录来复制或安装该应用程序。您还必须在全局程序集缓存中移动该程序集。
有若干方法可以将程序集部署到全局程序集缓存中： 

使用专用于全局程序集缓存的安装程序。该方法是将程序集安装到全局程序集缓存的首选方法。 
使用 .NET Framework SDK 所提供的名为全局程序集缓存工具 (Gacutil.exe) 全局程序集缓存工具使您可以查看和操作全局程序集缓存和下载缓存的内容。gacutil [options] [assemblyName | assemblyPath | assemblyListFile]的开发人员工具。 
使用 Windows 资源管理器将程序集拖到缓存中。 

从命令行部署 ASP.NET 应用程序

单击“开始”，然后单击“运行”。
在“运行”对话框的“打开”文本框中，输入“cmd”，然后单击“确定”。
在命令提示处，键入下列命令：
xcopy <源路径> <目标路径>

在此命令中，<源路径> 是需要复制的源文件的完整路径，包括驱动器、目录和要复制的文件名。如果目录下的全部文件都需要复制，可以省略文件名。<目标路径> 是文件应该复制到的目录的完整路径。

以下的命令示例将 c:/myWebApp 目录下的所有文件复制到 d:/liveapp 目录下。

xcopy c:/devapp d:/liveapp
回答所有关于所复制的文件或目录的问题。
当需要更新应用程序的 /Bin 目录下存储的 DLL 或更新任何其他应用程序文件时，都可以使用此过程。下面的示例将一个驱动器的 /bin 目录中的一个 DLL 复制到另一个驱动器的 /bin 目录下。

xcopy c:/devapp/bin/myAssembly.dll d:/liveapp/bin/
同样，一旦部署了应用程序，就可以使用此命令更新应用程序中的文件。虽然可以复制整个目录，但是在复制个别文件时，在两个目录之间一次只能复制一个文件。可以使用 XCOPY /exclude 选项，从复制中排除子目录、带指定文件扩展名的文件或具体的文件名。有关如何使用 XCOPY 工具的更多信息，请打开操作系统的文档并搜索 XCOPY。

注意 对于 XCOPY 工具必须使用物理目录名。不能使用虚拟目录名。

Visual Studio 中设计时的 Web 应用程序安全性

当您在 Visual Studio 中工作以创建 Web 应用程序时，将需要在开发过程中访问一些资源，与这种访问相关的安全性存在一些特定的要求。这些要求不同于那些适用于应用程序用户的要求。设计时的安全性要求包括：

访问您的工作服务器、数据库服务器以及其他属于应用程序一部分的资源。
您选择了哪种 Web 访问方法（您如何向 Web 服务器传输数据）。
以完全受信任模式运行代码。
调试。
部署您的应用程序。
访问开发资源
为了在 Visual Studio 中创建和测试 Web 应用程序，您必须能够访问运行 Internet 信息服务 (IIS) 的计算机。在此服务器（即开发服务器，它不同于您在其中部署应用程序的生产服务器）上，必须具有某些最低程度的特权，其中包括能够将文件写入服务器并运行这些文件。

Web 服务器不必位于用于开发的同一台计算机上。但是，您必须至少在 Web 服务器上安装 Visual Studio 的服务器组件，以使其支持应用程序的调试和部署。

对资源的设计时访问通常使用 Windows NT 身份验证来处理，也就是说，作为开发人员，您使用自己的网络登录凭据来获取对所需资源的访问权。当 Visual Studio 安装完毕后，它会在服务器上创建一个名为“VS Developers”（VS 开发人员）的组。该组具有在此计算机上开发 Web 项目所必需的全部文件、共享和 IIS 权限。（计算机管理员可以进一步为该组配置自定义权限，但这并不是必需的。）作为开发人员，您必须作为个人或您所属的另一个组的成员成为该组的成员。授予“VS Developers”（VS 开发人员）组的特定权限有：

访问 Web 服务器计算机的 wwwroot 目录的权限。
创建、修改和执行 Web 目录中文件的权限。
调试远程 Web 应用程序的权限。
安全说明 开发人员并不需要为使用某服务器进行开发而具有该服务器的管理员权限。（但是，所有开发人员都必须是“VS Developers”（VS 开发人员）组的成员。）如果向开发人员授予不必要的管理员权限，则可能会给网络造成安全性风险。
如果您的应用程序需要访问进一步的资源，您必须同样地作为个人或作为组的成员建立对这些资源的访问权限。一个典型的示例就是 SQL Server。作为 Web 应用程序开发人员，您将需要能够读取（并在可能时更新）应用程序所需的数据库表。对于某些方案，您还需要具有将存储过程写入服务器的权限；在其他方案中，则可能需要具有添加、改变或删除表的权限。

Web 访问方法
Visual Studio 允许您以两种方式访问 Web 应用程序项目：

使用文件共享访问（UNC 访问）。在这种方式中，Visual Studio 使用基于 Windows 的文件管理命令将文件复制到服务器上。
使用 FrontPage 服务器扩展访问。在这种方式中，将使用 HTTP 来传输文件。
文件共享访问要求您与 Web 服务器位于同一域中。实际上，这意味着您只能在自己的网络上使用文件共享访问。

对比之下，FrontPage 访问允许跨越防火墙创建和管理应用程序（只要防火墙传递 HTTP 请求）。这样，就可以通过 Internet 执行操作（当然也可以在您首选 HTTP 访问的本地设置中执行操作）。

这两种访问方法仍然要求使用 Visual Studio 服务器组件、“VS Developers”（VS 开发人员）组等正确配置服务器。同样，您仍然需要在服务器上具有足够的特权才能创建、编写和运行文件。


以完全受信任模式运行代码
当 Visual Studio 运行时，设计器在设计时运行的用户代码将始终以完全受信任模式运行。即使该代码最终部署到的环境将以限制较大的安全性来运行，情况也是如此。这包括两层含义：

可能会因为将不安全代码导入项目而给本地计算机带来安全性风险。由于 Visual Studio 以完全受信任模式运行，导入的代码会从 Visual Studio 继承其权限，而不安全的代码将作为安全代码来运行。只有在恶意用户创建具有破坏性的代码段（例如自定义控件），而您随后因疏忽导入并运行该代码段的情况下，才需要注意这一问题。因此，在将代码导入项目时，务必要加倍小心。
您在 Visual Studio 中创建的应用程序可能会在部署后无法正确运行，因为该代码是在不同的安全性上下文中运行。

调试
调试要求您能够附加到在本地计算机（如果 Web 服务器位于另一台计算机上，则为远程计算机）上运行的进程。调试要求您使用“管理员”特权运行。如果您是在远程计算机上进行调试，则必须在本地计算机上和远程计算机上都具有相应的权限。

当 Visual Studio 安装完毕后，它将创建一个名为“Debugger Users”（调试器用户）的组，该组具有进行调试所必需的权限。通过将开发人员和调试用户划分到不同的组，服务器管理员可以向一个经过精选的组授予调试所必需的特权，而不是向所有使用 Visual Studio 的用户授予这些特权。

安全说明 “Debugger Users”组中的成员可有效地授予用户管理级别特权。不要使不应具有这种级别特权的任何人成为此组的成员。

部署应用程序
当完成应用程序后，您必须能够将它部署到生产服务器。如果生产服务器不属于您，则对该服务器的访问可能会受到很多在您的开发服务器上没有的限制。

部署 Web 应用程序的一种方法是使用 Visual Studio 部署工具。这种部署允许您执行应用程序的完全安装（包括注册和配置）。但是，它要求您对承载 Web 服务器的计算机具有管理员权限。

此外，如果生产服务器上安装有 FrontPage 服务器扩展，您也可以选择通过 HTTP 使用 Copy Project 命令来进行部署。这种部署为您提供的部署功能较少，但却允许您跨越防火墙进行部署。为了将文件写入目标服务器，您仍然必须在该服务器上具有足够的特权。
运行时的 Web 应用程序安全性

身份验证


ASP.NET 支持通过以下方法对用户进行身份验证。其中几种方法与 IIS 身份验证相重叠。有关详细信息，请参见介绍 Web 应用程序安全性。

身份验证类型 说明
匿名访问 用于未知用户将在其中发出请求的应用程序（通常是公共 Web 应用程序）。与 IIS 重叠。
基本和简要身份验证 （与 IIS 重叠）在此方案中，将提示无凭据的用户提供用户名和密码。
Windows 集成安全性 (NTLM) （与 IIS 重叠）如果发出请求的用户已经在基于 Windows 的网络中进行了身份验证，则在请求对资源的访问时，IIS 就可以通过该用户的凭据。
证书身份验证 （与 IIS 重叠）在此方案中，客户端具有已从第三方来源获取的证书（数字标识）。该证书通过请求传递到您的应用程序。
Kerberos （与 IIS 重叠）Kerberos 身份验证协议定义客户端与称作密钥分发中心 (Key Distribution Center, KDC) 的网络身份验证服务之间的交互。Windows 2000 在每个域控制器上以身份验证服务的形式来实现一个 KDC。有关详细信息，请参见 Kerberos 协议的基本概念。
Forms 身份验证 如果需要对某用户进行身份验证，ASP.NET 则会将请求重定向到您指定的页。该页通常包含一个您要在其中获取用户名信息的窗体。（如需额外的安全性，可以使用 HTTPS 协议交换该窗体。）当应用程序获取窗体信息时，它可以对用户的凭据执行应用程序特定的检查。值得注意的是，身份验证进程在您的控制之下（与 IIS 不同），这使您能够指定窗体的外观并选择存储用户信息的方式。
如果某用户成功通过身份验证，ASP.NET 将颁发一个包含特定标记的加密 Cookie，该标记将为后继的访问标识该用户。

Passport 身份验证 利用 ASP.NET，您可以检查那些具有从符合 Microsoft Passport 的应用程序中获取的凭据的用户。
如果某用户成功通过身份验证，ASP.NET 将颁发一个包含特定标记的加密 Cookie，该标记将为后继的访问标识该用户。


在 ASP.NET 应用程序中，Forms 身份验证通常是最佳的选择，因此它使您能够在很大程度上控制如何对用户进行身份验证并允许您将身份验证存储在一个标记中。

XML Web services 安全性
XML Web services 使用 ASP.NET 并作为 Web 应用程序来运行，因此它们所参与的安全性模型与任何 ASP.NET 应用程序所参与的安全性模型都相同。例如，XML Web services 可能配置为使用基本身份验证或 Windows 集成安全性。

在设计时，当您尝试向 XML Web services 添加引用（即请求 XML Web services 的发现文档）时，该 XML Web services 将按照它的配置来执行标准的 Web 应用程序身份验证。例如，如果 XML Web services 配置为使用基本身份验证，该服务将需要从发出请求的客户端获取用户名和密码。在 Visual Studio 中，通常使用添加 Web 引用对话框来发现 XML Web services。例如，如果 XML Web services 使用的是基本身份验证，“添加 Web 引用”对话框将提示您提供凭据。

如果您正在生成的应用程序包含对 XML Web services 的调用，则需要确保在进行调用之前具有正确的凭据，否则该调用将会失败。在运行时，可以通过在调用 XML Web services 的方法之前设置表示 XML Web services 的客户端对象的 Credentials 属性来向 XML Web services 传递凭据。

由于其他 ASP.NET 安全性选项可能不够灵活，XML Web services 可以实现一种凭据信息在 SOAP 标头中进行传递的自定义身份验证解决方案。在该解决方案中，凭据在客户端和服务器之间交换的消息的可选部分进行传递。然后可以编写一个自定义的 HttpModule（实现 IHttpModule 接口），它可以侦听标头中的信息并调用您的身份验证代码。

与其他 ASP.NET 应用程序相同，XML Web services 可能会实现基于特定角色的授权，以限制对应用程序特定部分的访问。

建立 SSL 和加密
若要使用 SSL 和加密，必须获取您所在公司或标识的服务器证书。证书是一种数字签名，它标识您的站点，使其无法被模拟。对于 Internet（公共）应用程序，可以从公认的第三方证书颁发机构获取服务器证书。对于私有 (Intranet) 应用程序，您自己就可以颁发服务器证书。您这样做的目的可能是为了确保内部应用程序（如个人站点）的安全。

服务器证书还使您能够使用加密。SSL 使用一种称作“公钥加密”(public key encryption) 的加密方法。这种形式的加密机制中有两个密钥：公钥用于对数据进行加密；私钥由您密存，用于对用公钥加密的信息进行解密。您所获取的服务器证书包含一个公钥。当用户需要使用 SSL 时，您的应用程序将向浏览器发送证书和公钥。然后，浏览器和服务器使用公钥来建立一种对它们的信息交换进行加密的方式。

注意 若要使用 SSL，浏览器必须支持长度至少为 40 位的加密。大多数浏览器都提供这种级别的加密。
当获取服务器证书后，可以指示用户将 https:// 用作前缀来获取和发送 Web 页，以使用 SSL。IIS 和浏览器将自动使用加密信道来交换信息。

Web 应用程序的基本安全实施策略


常规 Web 应用程序安全性建议


有些最基本的安全性建议也是最显然易见的。但是，如果恶意用户可以使用简单方法进入您的计算机，即使是最精心设计的应用程序安全性也会失败。

经常进行备份，并将备份存放在安全的场所。
将您的 Web 服务器计算机放置在安全的场所，这样，未经授权的用户就无法使用它、关闭它、带走它，等等。
使用 Windows NTFS 文件系统，不使用 FAT32。NTFS 的安全性比 FAT32 高得多。有关详细信息，请参见 Windows 文档。
使用不易破解的密码，确保 Web 服务器计算机和同一网络上的所有计算机的安全。
确保 IIS 的安全。有关详细信息，请参见 Microsoft 安全性 Web 站点 (http://microsoft.com/technet/treeview/default.asp?url=/technet/security/bestprac/mcswebbp.asp) 上的文章“管理 Windows IIS Web 服务的安全性”。

关闭不使用的端口并关闭不使用的服务。
运行监视通信量的病毒检查程序。
建立并实施以下策略：禁止用户将其密码记在容易找到的位置。
使用防火墙。有关建议，请参见 Microsoft 安全性站点上的“核对清单：安装防火墙”。(http://microsoft.com/security/articles/firewall.asp)
了解和安装来自 Microsoft 和其他供应商的最新安全修补程序。例如，Microsoft 安全站点 (www.microsoft.com/security) 中有所有 Microsoft 产品的最新安全公告的列表。其他供应商也有类似站点。
使用 Windows 事件日志记录，并且经常检查这些日志，以查找可疑活动。这样的活动包括：反复尝试登录您的系统，以及向您的 Web 服务器发出数量巨大的请求。


使用最少特权运行应用程序



当您的应用程序运行时，它运行在一个具有本地计算机（还可能是远程计算机）的特定特权的上下文中。请遵循这些指导：

在具有最少实用特权的上下文中运行应用程序。默认情况下，在 IIS 5 版中，ASP.NET 应用程序运行在名为 ASPNET 的本地用户的上下文中。在 Windows Server 2003 上的 IIS 6 上，此帐户称为 NETWORK SERVICE。有关详细信息，请参见 ASP.NET 进程标识和配置 ASP.NET 进程标识。
不要在系统用户（管理员）的上下文中运行应用程序。
设置应用程序所需的所有资源上的权限（ACL 或访问控制列表）。使用最少的容许设置。例如，如果在您的应用程序中是可行的，则将文件设置为只读。有关详细信息，请参见 Windows 文档。
将您的 Web 应用程序的文件保存在应用程序根目录下的一个文件夹中。不要让用户指定在应用程序中进行文件访问的路径。这样有助于防止用户访问服务器的根目录。
不要使不需要调试 Visual Studio 应用程序的任何人成为“Debugger Users”（调试器用户）组的成员。此组具有比“VS Developers”（VS 开发人员）组更高的特权。有关详细信息，请参见添加调试器用户和配置 DCOM。


了解您的用户



在许多应用程序中，用户有可能不必提供凭据即可访问站点。如果是这样，则您的应用程序通过在预定义用户的上下文中运行即可访问资源。默认情况下，此上下文是 Web 服务器计算机上的本地 ASPNET 用户（Windows 2000 或 Windows XP）或 NETWORK SERVICE 用户 (Windows Server 2003)。

若要仅允许已授权用户进行访问，请遵循以下准则：

如果您的应用程序是 Intranet 应用程序，则将其配置为使用 Windows 集成安全性。这样，用户的登录凭据就可以用于访问资源。
如果您需要从用户收集凭据，则使用其中的一种 ASP.NET 身份验证策略。有关更多信息，请参见 ASP.NET 身份验证。有关示例，请参见简单 Forms 身份验证。


防止恶意用户的输入



通常，决不假定从用户获得的输入是安全的。对恶意用户来说，从客户端向您的应用程序发送潜在危险的信息是很容易的。若要防止恶意输入，请遵循以下准则：

在窗体中，筛选用户输入以查找 HTML 标记，其中可能包含脚本。有关详细信息，请参见在 Web 应用程序中防止脚本利用。
决不回显（显示）未经筛选的用户输入。在显示不受信任的信息之前，对 HTML 进行编码以将潜在有害的脚本转换为显示字符串。
类似地，决不将未经筛选的用户输入存储在数据库中。
如果要接受来自用户的一些 HTML，则手动筛选它。在您的筛选器中，显式定义将要接受的内容。不要创建一个试图筛选出恶意输入的筛选器；因为预料到所有可能的恶意输入是非常困难的。
不要假定您从标头（通常通过 Request 对象）获得的信息是安全的。对查询字符串、Cookie 等采取安全措施。注意浏览器向服务器报告的信息（用户代理信息）可以假冒，假如它在您的应用程序中是重要的。
如有可能，不要将敏感信息（如隐藏域或 Cookie）存储在可从浏览器访问的位置。例如，不要将用户名或密码存储在 Cookie 中。
注意 视图状态是以编码格式存储在隐藏域中的。默认情况下，它包含消息身份验证代码 (MAC)，以便页可以确定视图状态是否已被篡改。



创建安全的错误信息



如果您不小心，恶意用户就可以从应用程序显示的错误信息推断出有关您的应用程序的重要信息。请遵循这些指导：

不要编写会回显可能对恶意用户有用的信息（例如用户名）的错误信息。
将应用程序配置为不向用户显示详细错误。如果为进行调试而要显示详细错误信息，请先检查该用户是否为 Web 服务器的本地用户。有关详细信息，请参见显示安全的错误信息。
对于容易发生错误的情况（如数据库访问）创建自定义错误处理方式。


安全地保守秘密



“秘密”是指您不希望某人知道的信息。一个典型的秘密是密码或加密密钥。当然，如果恶意用户能够获得秘密，则由该秘密保护的数据会受到危害。请遵循这些指导：

如果您的应用程序在浏览器和服务器之间传输敏感信息，请考虑使用安全套接字层 (SSL)。有关如何实现 SSL 的详细信息，请参见 Microsoft 知识库文章 Q307267“HOW TO：在 Windows 2000 中使用安全套接字层来保障 XML Web services 的安全”(HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000)。
如果您必须存储秘密，即使是以您认为人们将无法看到它的形式（如在服务器代码中）进行保存，也不要将它保存在 Web 页中。
如果您对信息加密，请不要创建您自己的加密算法。请使用 Windows 数据保护 API (DPAPI)。


安全地使用 Cookie



为了让用户特定的信息保持可用，Cookie 是一种容易而有用的方法。但是，由于 Cookie 会被发送到浏览器所在的计算机，因此它们容易被假冒或用于其他恶意用途。请遵循这些指导：

不要将任何关键信息存储在 Cookie 中。例如，不要将用户的密码存储在 Cookie 中，即使是暂时存储也不要这样做。通常，不要将任何信息保存在 Cookie 中（一旦它被假冒，就会给您带来麻烦），而是在 Cookie 中保存对信息在服务器上的位置的引用。
设置 Cookie 的到期日期，使其有效期尽可能最短。如有可能，避免设置永久性 Cookie。
考虑对 Cookie 中的信息加密。


防止拒绝服务威胁



恶意用户危害您的应用程序的一种间接方式是使其不可用。恶意用户可以使应用程序太忙而无法为其他用户提供服务，或者仅仅使应用程序出现故障。请遵循这些指导：

关闭或释放您使用的任何资源。例如，在使用完毕后，始终关闭数据连接和数据读取器，而且始终关闭文件。
使用错误处理（例如，try-catch）。包含 finally 块，以便万一失败就可以在其中释放资源。
将 IIS 配置为使用进程调节，这样可以防止应用程序消耗过多的 CPU 时间。有关详细信息，请参见技术文章“使用 Internet Information Server 5.0 的新功能：第 1 部分”。
在使用或存储用户输入之前，测试它的大小限制。
对数据库查询的大小加以限制以确保安全。例如，在 Web 窗体页中显示查询结果之前，检查包含的记录数是否不合理。
如果文件上载是您的应用程序的一部分，则对它们的大小加以限制。您可以使用类似如下的语法在 Web.config 文件中设置限制（其中 maxRequestLength 值以千字节为单位）：





脚本利用

从浏览器的角度来看，Web 页只是一个长字符串。浏览器会顺序处理这个字符串，在此过程中，会显示某些字符，同时按特殊规则解释其他字符（如 和 [C#] if ((UserEmail.Value == "jchen@contoso.com") && (UserPass.Value == "password")) { FormsAuthentication.RedirectFromLoginPage (UserEmail.Value, Persist.Checked); } else { Msg.Text = "Invalid Credentials: Please try again."; } } 显示窗体以收集登录信息。

Logon Page

Using Forms Authentication

使用业务对象

在业务组件中封装逻辑是实际应用程序的基本组成部分，不论是基于 Web 的应用程序还是任何其他应用程序。在 ASP.NET 中，业务对象是多层 Web 应用程序（如包含数据访问层或通用应用程序规则层的应用程序）的生成块。本节说明如何编写一些简单的组件并将它们包括在应用程序的 Web 窗体页中。 

应用程序 /Bin 目录 

使用 Web 应用程序组件的 COM 模型时遇到的问题是，这些组件必须注册（通常是使用 regsvr32 工具）后才能在传统的 ASP 应用程序中使用。对这些类型的应用程序进行远程管理通常是不可能的，因为注册工具必须在服务器上以本地方式运行。更为棘手的是，这些组件经应用程序加载后便在磁盘上保持锁定状态，必须