威胁来自何方
下表列出了最常见的几种Web攻击：
从根本上讲，不论用户向浏览器的标记中插入何种数据，都有可能遭受代码注入攻击（即，SQL注入和XSS的各种变体）。此外，敏感数据不应被传输，而必须安全地保存在服务器上。
ASP.NET安全性上下文
从应用程序的角度来看，安全性主要是对用户进行身份验证，以及授予其对系统资源的操作权限。ASP.NET结合了IIS、.NET Framework和操作系统的底层安全服务，提供了身份验证和授权机制。ASP.NET应用程序整体的安全性上下文由以下3个级别构成：
1. IIS级将有效的安全令牌与请求的发送者关联（该安全令牌取决于当前IIS身份验证机制）。
2. ASP.NET工作进程级会确定处理该请求的ASP.NET工作进程中线程的标识。如果启用了模拟（impersonation），那么它会更改与该线程关联的安全令牌。根据当前使用的进程模型，该进程模型的标识会由配置文件或IIS元库中的设置确定。
3. ASP.NET管道级会获取当前应用程序特定用户的凭据。这项工作完成的方式取决于配置文件中有关身份验证和授权的设置。ASP.NET应用程序最常选择的是Forms身份验证。
ASP.NET应用程序涉及的安全性上下文
当ASP.NET请求到达Web服务后，IIS会获取该请求，并将其分配给池中的一个线程。IIS运行在SYSTEM帐户下（Windows中权限最高的帐户）。在处理该请求的过程中，会依次执行3个ASP.NET应用程序安全性上下文。
IIS线程安全性上下文
在物理上处理请求的线程会根据当前IIS身份验证设置（基本身份验证、摘要式身份验证、集成Windows身份验证或匿名身份验证）模拟出一个标识。如果当前网站的访问配置为匿名身份验证，默认情况下，它的用户名为IUSR_XXX（其中XXX代表计算机名称）。
“基本身份验证”是HTTP标准，几乎所有浏览器都支持。如果选择这种身份验证方法，请求会返回一个特殊的HTTP状态码，提示浏览器显示一个标准的对话框，该对话框用于输入用户的凭据。用户输入的凭据信息会被发送到IIS，IIS会尝试将其与Web服务器中的帐户进行比对。由于凭据是以Base64方式编码的文本（基本上是明文），因而只推荐通过HTTPS安全信道进行基本身份验证。
“摘要式身份验证”与基本身份验证不同之处在于，摘要式身份验证会在发送前对凭据进行散列处理。摘要式身份验证是HTTP 1.1的功能，有些低版本的浏览器可能不支持。此外，Windows2000要求将密码以可逆的加密方式存储服务器上，而Windows Server 2003没有这样的要求。基本身份验证和摘要式身份验证即使通过防火墙和代理服务器也能正常工作。
“集成Windows身份验证”需要建立浏览器与Web服务器间的对话。浏览器会发送当前登录的Windows用户的凭据，而不需要手动输入。用户需要有Web服务器的有效帐户，或位于一个能够成功被身份验证的受信任的域中。这种身份验证可以通过NTLM的质询/响应方法或由Kerberos来执行。支持该项技术部的浏览器很有限，如果有防火墙，则不适合使用这种身份验证，它针对的是Intranet。
“基于证书的身份验证”是基本证书的一种验证形式。当用户请求Web站点的信息时，我们可使用IIS安全套接字层（SSL）的安全功能和客户端证书来对该用户进行身份验证。在用户登录的过程中，SSL会检查浏览器提交的证书的内容。用户要通过受信任的第三方组织获取客户端证书。
经过身份验证后，该线程会将请求派发给相应的外部模块。对于ASP.NET请求来说，随后发生的取决于当前应用程序的进程模型。
工作进程的安全性上下文
在IIS 5.0的进程模型中，IIS线程会将请求交给ASP.NET ISAPI扩展（aspnet_isapi.dll），再由该扩展启动aspnet_wp.exe工作进程。在IIS 6.0进程模型中，请求会在ASP.NET应用程序的应用程序池中排队，并由服务于该应用程序池的w3wp.exe IIS工作进程的副本获取。那么该工作进程的标识是什么呢？
如果使用的是IIS 5.0进程模型，那么该工作进程会运行于ASPNET帐户下。ASPNET是一个本地帐户，在.NET Framework安装时创建。该帐户的权限很低，远不如SYSTEM帐户。我们可以在machine.config文件的修改现有帐户的标识：
<processModel userName="..." password="..." />
如果使用IIS 6.0进程模型，那么该工作进程的标识为NETWORK SERVICE。该帐户与ASPNET的权限相同，是Windows Server 2003和Windowx XP内建的帐户。
在该工作进程中，入池线程会获取请求，并为其服务。该线程的标识是什么呢？在默认情况下，如果禁用ASP.NET应用程序的模拟，那么该线程的标识与其工作进程的标识相同。如果启用模拟，那么该工作线程会采用IIS传给它的安全令牌。我们可以在web.config文件中启用模拟：
<impersonation enabled="true" />
若启用模拟，工作进程的帐户不会更改，它仍会使用原帐户来编译页面并读取配置文件。模拟只能由页面中执行的代码使用，将请求交给页面处理程序前的所有步骤是不能使用模拟的。
ASP.NET管道的安全性上下文
第三个安全性上下文是发出请求的用户的标识。这一层的关键在于用户的身份验证，及对页面、内嵌资源访问的授权。显然，如果被请求的页面完全公开，则不需要执行验证过程，生成页面输出并返回给用户即可。
为保护页面不受未授权的访问，ASP.NET应用程序域要选择一种身份验证策略--Windows、Passport或Forms。对于受保护的页面，身份验证模块会拦截请求，并设法获取用户的凭据。仅当该用户的凭据被认为是有效的，且证明其拥有被请求资源的访问权限时，才会被转到目标页面。
ASP.NET进程标识的更改
如果需要更改ASP.NET的帐户，为其授予更多的权限，我们应该怎么做呢？是为相应的工作进程创建一个自定义的帐户，还是让工作进程模拟一个固定的标识呢？
ASP.NET进程帐户的设置
<processModel>区段或下图所示的对话框，分别是IIS 5.0进程模型和IIS 6.0进程模型更改ASP.NET进程标识的唯一途径。如果更改该进程的标识，其中的所有线程会将其用途基本标识，在进程切换时，不需要额外工作。另外，我们至少应确保新的帐户对Temporary ASP NET Files文件夹有完整的权限。
固定标识的模拟
此外，我们还可以让工作进程通过web.config文件的<identity>区段模拟一个固定的标识。应注意，若使用固定的模拟标识，每个处理请求的工作线程都需要模拟指定的帐户。由于线程切换事件会将线程标识转换为进程的标识，因而每次线程切换都要进行模拟。
为模拟固定的标识，我们首先要定义该用户帐户，并向web.config文件添加一个设置，如下所示：
<identity impersonate="true" userName="MyAspNetAccnt" password="ILoveASP" />
ASP.NET默认帐户的权限
在所有用户权限中，ASPNET和NETWORK SERVICE只被授予以下5个权限：
1. 从网络访问此计算机。
2. 拒绝本地登录。
3. 拒绝通过终端服务登录。
4. 作为批处理作业登录。
5. 作为服务登录。
此外，还需为该帐户授予某些文件夹的NTFS权限，使其能对特定文件夹进行操作。这些文件夹包括：
1. .NETFramework要目录：该文件夹包含某些ASP.NET必须要访问的.NET Framework系统程序集。物理文件夹一般位于Windows文件夹\Microsoft.NET\Framework\[version]下。ASP.NET进程对该文件夹只有读取和列表权限。
2. Temporary ASP.NET Files：该文件夹包含所有ASP.NET生成的临时文件的文件系统子树。ASP.NET进程应有整个子树的“完全控制”权限。
3. 全书程序集缓存：位于Windows\Assembly\GAC文件夹下。ASP.NET进程对该文件夹只有读取权限。
4. Windows系统文件夹：ASP.NET进程需要访问和读取Windows的System 32文件夹，以加载必要的Win32动态链接库。
5. 应用程序根目录：该文件夹一般位于Inetpub\wwwroot下。ASP.NET进程对该文件夹有访问和读取权限。
6. Web站点根目录：ASP.NET可能需要扫描Web服务器的根目录（一般为Inetpub\wwwroot）来查找要读取的配置文件。
如果ASP.NET应用程序使用的帐户缺少以上某个权限，那么它可能不能正常运行。
ASP.NET应用程序的信任级别
ASP.NET应用程序由托管代码组成，运行在公共语言运行库（CLR）中。在CLR中，基于代码提供有关来源的证据（如源URL），运行的代码会获得一块安全区域。每块安全区域对应于一组权限，而每组权限对应一个信任级别。默认环境下，ASP.NET应用程序在MyComputer区域中运行，完全受到信任。那么这个默认设置有危险吗？
ASP.NET应用程序运行在Web服务器上，不会受到通过浏览器连接的用户的威胁。除浏览器外，不能通过其他形式使用ASP.NET应用程序。
问题不在ASP.NET应用程序本身，而在于它通过Internet暴露给外界。完全受到信任的ASP.NET帐户如果被黑客劫持，黑客可能通过ASP.NET工作进程执行某些受限制的操作。也就是说，公开暴露完全受信任的应用程序是黑客发起攻击的潜在平台。应用程序受信任的级别越低，应用程序的安全性就越高。
<trust>区段
默认情况下，ASP.NET应用程序的运行不受限制，能执行它的帐户所允许的所有操作。
通过修改web.config文件的根节点下的<trust>区段，我们可以配置Web应用程序代码访问安全的权限，确定它的运行时受到完全信任还是部分信任。
<trust level="Medium" originUrl="" />
下表对各种信任级别做了简要说明：
如果设置originUrl属性，指定的URL会被授予通过Socket或WebRequest类访问HTTP资源的权限。这里要用到的权限类是WebPermission。不过，仅能授予<trust>中中级和更高信任级别支持的Web权限。
ASP.NET权限
下表概括了ASP.NET中每种级别的主要权限：
有关实际赋予默认信任级别权限的详细信息，可以在每个级别的安全性配置文件中找到。对应每个级别的文件的名称，存储在<trustLevel>区段中。
根据经验，如果不需使用过去的组件对象模型（COM）对象，也不需使用OLE DB提供程序，那么大多数ASP.NET应用程序都可以使用中级信任级别。
为信任级别授予额外的权限
如果指定的信任级别没有提供执行某项操作所需的权限，该怎么办？主要有两个方法：
1. 最简单的是对该信任级别的策略文件进行修改，添加所需的权限。这种方案易于实现，不需修改代码，但编辑策略文件需要管理员权限。从安全角度来看，为某个页面或程序集的某个方法添加的权限，会影响到整个应用程序。
2. 对代码做重构，使服务器代码利用sandbox，使其通过外部组件（如，服务组件或命令行程序）来执行超载应用程序权限的所有任务。如果受部分信任的ASP.NET应用程序要调用不带AllowPartiallyTrustedCallers特性的程序集，利用sandbox是唯一的方案。有关中级信任级别的编程技术，可访问http://msdn.microsoft.com/en-us/library/ms998341.aspx。