即使依托相关安全平台发展,Web应用也必须追随最好的贯穿设计、开发、配置整个阶段的安全平台来最大程度的避免遭遇攻击。为了开发出安全的Web应用,这个详细而精确的平台设计需要结合安全设计实践、威胁模拟分析和安全渗透检验知识。
这篇文章论述了怎样采用ASP.NET 2.0 and IIS 6.0的安全机制去建立安全的Web应用的实践。
Web 安全应用设计
安全设计原则通常可归结为几个关键原则:假设所有的系统输入都是恶意的,减少系统外露信息,采用默认值,使用深度防卫而不依靠系统其他部分来保护。按照这些普遍原则来进行设计是确保你的应用尽好的被保护的关键。
威胁模拟分析是用来制订系统数据溢出和检查可能的恶意入侵点。威胁模拟分析是从设计者的角色换为入侵者的角色去检查你的设计的关键必要的练习,可以帮助发现潜在的安全漏洞。要了解更多的关于威胁模拟的知识,请到威胁模拟分析。
安全渗透检验又一种攻击你的应用——在别人入侵之前去破坏你的应用以求发现问题的方法。你可以尝试发送无效或最坏数据使你的应用达到极限。你也可以利用你了解的它的内部只是来破坏你的应用程序——这样,你所来了解的内部知识赋予你相对于一般的入侵者无可比拟的优势,或许可以挖掘出深藏在你的代码内部的脆弱点。有各种各样的工具可以帮助你来做安全渗透检验。
资源保护
通常,配置Web应用的第一个任务是确保敏感信息不能被因特网上的匿名用户访问。如果是企业内部网,通常是通过鉴别是否为Windows®系统的注册用户(并会有更多的权限控制)来实现这点的,并通过防火墙来限制外部访问。对于因特网,这种做法就是问题了,因为它至少要保证匿名用户也能访问。除了这点不同,下面的这种方案也不能同时保护Internet and Intranet的资源。
理想化地,最好是确保你的Web应用的命名空间不包括那些你不准备提供给客户端的文件。意思是说把这些文件从标志为Web应用的从顶端目录开始的物理目录结构中或IIS配置中的虚拟目录中移除。如果这些文件不在Web的命名空间里,当请求访问那个命名空间时这些文件是不能被接触到的,除非你的代码能够直接打开那些文件并提供其内容。如果你的应用程序是编码访问数据或在执行时提供文件,你应该把这些文件放在命名空间之外。
如果你不能够移动所有这些文件,就得确保IIS配置不向客户端提供这些文件。这可以通过在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的知识。

