【IT168技术文档】

  Web应用是互联网最普遍的应用之一，因此也使你的网络极易遭遇入侵导致敏感资料被窃、数据被篡改、或者甚至威胁到系统的安危。确保Web应用安全是一个很迫切的任务，并且需要贯穿设计、开发、配置和实施阶段的考虑。不能只把它看作附加在现有应用上的一些事物，或者认为应用现有平台的安全特征就很容易实现的。

  即使依托相关安全平台发展，Web应用也必须追随最好的贯穿设计、开发、配置整个阶段的安全平台来最大程度的避免遭遇攻击。为了开发出安全的Web应用，这个详细而精确的平台设计需要结合安全设计实践、威胁模拟分析和安全渗透检验知识。
这篇文章论述了怎样采用ASP.NET 2.0 and IIS 6.0的安全机制去建立安全的Web应用的实践。

  Web 安全应用设计

  安全设计原则通常可归结为几个关键原则：假设所有的系统输入都是恶意的，减少系统外露信息，采用默认值，使用深度防卫而不依靠系统其他部分来保护。按照这些普遍原则来进行设计是确保你的应用尽好的被保护的关键。

  威胁模拟分析是用来制订系统数据溢出和检查可能的恶意入侵点。威胁模拟分析是从设计者的角色换为入侵者的角色去检查你的设计的关键必要的练习，可以帮助发现潜在的安全漏洞。要了解更多的关于威胁模拟的知识，请到威胁模拟分析。

  安全渗透检验又一种攻击你的应用——在别人入侵之前去破坏你的应用以求发现问题的方法。你可以尝试发送无效或最坏数据使你的应用达到极限。你也可以利用你了解的它的内部只是来破坏你的应用程序——这样，你所来了解的内部知识赋予你相对于一般的入侵者无可比拟的优势，或许可以挖掘出深藏在你的代码内部的脆弱点。有各种各样的工具可以帮助你来做安全渗透检验。

资源保护

    通常，配置Web应用的第一个任务是确保敏感信息不能被因特网上的匿名用户访问。如果是企业内部网，通常是通过鉴别是否为Windows®系统的注册用户（并会有更多的权限控制）来实现这点的，并通过防火墙来限制外部访问。对于因特网，这种做法就是问题了，因为它至少要保证匿名用户也能访问。除了这点不同，下面的这种方案也不能同时保护Internet and Intranet的资源。

    理想化地，最好是确保你的Web应用的命名空间不包括那些你不准备提供给客户端的文件。意思是说把这些文件从标志为Web应用的从顶端目录开始的物理目录结构中或IIS配置中的虚拟目录中移除。如果这些文件不在Web的命名空间里，当请求访问那个命名空间时这些文件是不能被接触到的，除非你的代码能够直接打开那些文件并提供其内容。如果你的应用程序是编码访问数据或在执行时提供文件，你应该把这些文件放在命名空间之外。 

    如果你不能够移动所有这些文件，就得确保ＩＩＳ配置不向客户端提供这些文件。这可以通过在IIS脚本映射处理器中为这些受ASP.NET保护的文件配置映射扩展（见图1），然后把映射到ASP.NET <httpHandlers> 中的HttpForbiddenHandler配置映射或目录。默认情况下，ASP.NET成组存取Web应用中普遍应用的一些扩展，包括.cs, .java, .mdb, .mdf, .vb等文件。
 
图1映射 XML 文件 到 ASP.NET ISAPI 扩展

像如下这样配置 Web.config 文件来 阻止 .xml 扩展 被应用如果这个扩展被映射到了ASP.NET:

<configuration>
    <system.web>
        <httpHandlers>
            <add path="*.xml" verb="*"
             type="System.Web.HttpForbiddenHandler" />
        </httpHandlers>
    </system.web>
</configuration>

    注意这个配置产生一个ASP.NET分发给这个扩展文件的错误信息"403 Forbidden"。你也可以用System.Web.HttpNotFoundHandler来掩饰这个文件并返回一个普通的404响应。

    如果你卸载ASP.NET,IIS脚本处理器为.NET做的映射将会被移除，并且没有映射的扩展将会被IIS静态文件处理器处理。一般认为从IIS的多用途的网际邮件扩充协议映射配置移除一个相应的扩展条目将会阻止静态处理器提供那个扩展的文件。实际当中这并不总是对的，因为静态文件处理器会特殊处理已注册的映射配置，因而如果注册条目存在的话那些扩展名依旧可以提供。因此，你必须确保基于多用途的网际邮件扩充协议的映射配置的变化和HKEY_CLASSES_ROOT目录下的注册密钥不包括那些被禁止的扩展条目。鉴于管理的复杂性，一般不推荐用此方法建立安全目录。如果你坚持用此方法，你为安全着想应该把那些文件隐藏，因为IIS静态文件处理器对具有隐藏属性的文件不再进行处理。

       当然，这个关于IIS静态文件处理器的指导只适用于IIS脚本映射配置中不对ISAPI的映射。如果这个扩展被映射，相应的IIS脚本映射的ISAPI的扩展将会负责控制对那个扩展请求的访问。

       你也可以利用ASP.NET2.0的目录保护功能。默认情况下，ASP.NET2.0成组存取包含目录片段名为App_Data ,App_Code, App_Browsers, App_WebReferences, App_GlobalResources, App_LocalResources的网址。ASP.NET 1.1 and 2.0都将成组存取/Bin目录。这一支持的条件是具备aspnet_filter.dll 和IIS注册的ISAPI滤镜，这是在ASP.NET安装时默认的。在这些路径下放置你的目录，不论文件扩展是否被请求，你都可以阻止HTTP访问。图2描述了ASP.NET2.0下的目录保护。网址包括一些App_* 片段，包括App_Themes目录，并且没有被ASP.NET封闭。

路径	描述
/Bin	包含应用程序组件. 在 ASP.NET 1.1中也是封锁的.
/App_Code	包含可编译的应用程序代码.
/App_Data	包含应用程序数据文件.
/App_LocalResources	包含本地目录下的资源.
/App_GlobalResources	包含全球可应用的资源
/App_WebReferences	包含由可视化Web应用开发者开发的Web相关
/App_Browsers	包含浏览器定义.

                                                 图2 在ASP.NET2.0不能直接用HTTP访问的路径
访问控制

    大部分的Web应用提供对数据和资源的多层次访问，需要确保客户端依据他们的资格分配到适当的访问权限。Web应用中的访问控制典型地分为两个阶段：验证和授权。验证是指确认请求访问的用户的身份的处理过程。授权是确定是否给予客户访问某些特定资源的身份的处理过程。图3举例说明了IIS/ASP.NET平台下一个典型的处理HTTP请求的相关的安全步骤。
 
图3 处理HTTP请求

    有许多的非使用者访问控制机制可以帮你减少一些表面的简单攻击。在IIS6.0上的这种机制包括IP限制列表和Web服务扩展限制列表。

    IP限制列表允许你指定可以访问你的应用程序的IP地址。你也可以象子网一样配置IP地址和域。试想如果你的应用程序只限于企业内部网，或者你的客户端总是用一个特定的IP地址或域来访问你的应用程序。适当的时候，这种情况应该结合其他的访问控制手段来做深度防卫措施。

    扩展限制列表允许你全球范围内定义ISAPI扩展DLL文件和在服务器上执行的CGI.exe文件。默认情况下，所有的这些扩展都是禁止的，你必须更改使你需要的可用，其他的还要保持不可用状态。第三方产品的安装可能会启用一些附加的组件，所以如果你的Web服务内容用不着的话你需要关闭它们。

    IIS的早些版本也从UrlScan ISAPI滤镜获益，它提供附加的请求确认和危险输入的模块化。IIS6.0比早期版本提供了更强大的安全处理，不再暴露UrlScan的脆弱点。然而，你需要的安全级别IIS6.0默认没有提供，你或许继续要用UrlScan。你可以点击下面链接Determining Whether to Use UrlScan 2.5 with IIS 6.0来获得如何使用UrlScan的知识。

验证

    IIS和ASP.NET一起提供了访问控制机制的基础，ASP.NET2.0进一步扩充了这一机制提供了迅速的应用程序块使你可以快速的配置这一机制。

    IIS验证机制的产生的是请求用户的系统身份。IIS提供以下内置验证类型：匿名验证、完整Windows验证、基本验证、分类验证、证书映射验证和微软通行证验证。图4阐明了不同验证的应用情况。
                                                                                    图4  验证方法
    企业内部网络应用程序将使用完整的系统验证他们的域名。或者，他们会使用通行证验证尽管证书验证是因特网领域常用的验证方式。因特网应用程序应该使用加密套接字协议层上的基本验证或者分类验证，如果用户拥有系统帐户的话；或者如果用户没有系统帐户时使用带有详细应用程序验证计划的匿名验证。

    如果匿名验证不可以访问网址，IIS将会检查该请求是否被验证或者是它拒绝了该请求。这是深层防御安全的应用程序的另外的IIS验证机制,如果不准备给匿名者访问的话可以彻底的拒绝所有未验证用户。

    ASP.NET支持三种类型的验证：Windows验证、窗体验证和通行证。Windows验证只是接受IIS验证得到的系统身份。窗体验证在基于验证应用程序层验证方案下执行，它被那些跟系统验证的帐户毫无关系的用户的ASP.NET应用程序使用。（窗体验证应该与匿名验证选择结合使用）。通行证验证使用微软通行证验证方案。这种针对每一应用程序的验证方案在<system.web><authentication>配置元素里有详细阐述，例如：

<configuration>
    <system.web>
        <authentication mode="Forms" />
    </system.web>
</configuration>  

  使用窗体验证时，如果用户访问某个需要验证的资源被拒绝，程序将会跳转到登录页面。该页是应用程序开发者定制的ASP.NET页面，给用户提供了一个申请权限的通道。随后登录页面会使存储在自定义用户区的权限生效，比如存储在SQL数据库中的，并使用System.Web.FormsAuthentication类发布给客户端一个凭证。这个凭证可以是cookie变量是获得URL的特殊标志（这个开始于ASP.NET1.1的移动工具包和ASP.NET2.0）。

  在随后的请求中，客户端出示该凭证，窗体验证机制自动处理并为其生成一个用户身份。使用窗体验证，发布和管理验证凭证的复杂性由ASP.NET framework承担。然而你依然需要填写登录页面并和用户存储区执行关联。ASP.NET 2.0提供的两个附加组件简化了整个处理过程：成员服务和登录控制组。

  成员服务由System.Web.Security.Membership类来表现，它提供了很有用的生成、管理和确认用户权限的方法。同许多ASP.NET2.0特性一样，这种基于提取的设计使得服务能工作在多种后台数据存储的情况下，包括SQL Server和包括在ASP.NET framework下的ADO。安装你自己的数据库和利用aspnet_regsql.exe工具配置成员数据库到你的SQL Server或SQL Server Express一样容易,并配置SqlMembershipProvider-或者只是利用默认当你第一次访问时在你的应用程序的App_Data路径下自动创建SQL Server Express成员数据库。

  成员服务为普通用户管理功能提供支持，包括密码散列、帐户停用和登录跟踪。想得到更多关于成员服务可以到ASP.NET 2.0 (成员和角色管理 应用程序接口的使用 )，和MSDN®杂志中Dino Esposito 与Andrea Saltarello's的文章。

  ASP.NET2.0的登录控制使得登录页面的构造的核心变得十分简单，更进一步的，它提供了拖放控制，依靠成员和窗体验证的应用程序接口来验证用户权限的登录页面的工作会自动执行，并建立成功登录的凭证。登录控制提供灵活的功能，包括以普通成员提供者的身份工作、密码重置和确认普通用户权限。还有一系列控制支持，包括登录察看和新建用户控制，可以用来支持其他的用户管理接口（见登录控制的使用）。

  当使用窗体验证的自定义应用或者你自己的验证机制时，用安全套接层来保护你的登录页面和整个应用程序以防暴露登录权限和验证凭证（我将会在以后的文章中详细介绍验证凭证）。另外，你应该要求你的用户使用复杂的密码。成员服务允许利用正则表达式来加强密码的复杂性和格式。你要确保密码的杂乱无规律性（这是显而易见应该的），而且你也不要把权限资料保存在应用程序的<credentials>形式的片断文件中。

授权

  当用户的身份建立后，将作为系统安全的重要对象保存在请求的上下文中，可从HttpContext.Current.User中获得。这些对象可以用来做访问控制的依据。

  ASP.NET提供两种内置的授权机制来控制URL访问层：文件授权和URL授权。这两种都在验证之后ASP.NET管道权限请求阶段进行，并检验请求访问的身份有无权限访问请求的网址。如果没有，将会返回“401未授权”的错误报告。

  文件授权只在Windows验证已使用的情况下作用（当用户拥有系统身份时），它使用文件访问控制列表（ACLs）来决定请求的身份是否应该被授权。注意文件授权只在请求可以映射到文件且文件在本地计算机时才可用。如果实际文件处于共享状态，授权无效并且请求被允许。

  文件授权可以被已验证拥有系统帐号且利用文件访问控制列表来控制资源访问的应用程序的用户使用。在用此授权时务必限制不能访问给定文件的任意用户的阅读权限。

  URL授权使用基于配置的访问控制规则，参考用户名或角色来判断接受或拒绝访问。它是一般的首选授权机制因为它不依赖用户是否有系统帐号，可以配合任何验证机制来产生用户权限，并且提供了一种比文件访问控制列表更好的管理访问的策略。
URL授权访问控制规则详见<system.web><authorization>配置文件片断。授权机制严密管理这些规则并挑选最合适的规则来决定授予允许或拒绝的动作。以下配置为允许除匿名用户以外的所有已验证用户访问某一范围的URL：

<authorization>
     <allow users="*" />
     <deny users="?" />
</authorization>

  你也可以选择利用用户名或角色来限定这些规则。在ASP.NET1.1中，你需要在验证后手动关联用户权限和角色表。在ASP.NET2.0中，你可以用System.Web.Security.RoleManager类来创建和管理角色并自动关联。你也可以利用位置标签在同一配置文件中未具体的URLs指定访问控制规则。

  URL授权只对具体指定的用户授予允许权，而对其他的用户都授予否定权。最好的实施是对根目录给予更多的限制（拒绝每一用户或所有匿名用户），而对个别的URLs或较少访问的文件夹给予宽松限制。你需要在你的程序设计之前就考虑好授权请求并利用规则对相近权限分组来减少较多的个别配置，来降低出错的风险。