ASP.NET2.0与IIS6.0Web应用中的安全设计和配置(1)
发表于:2007-06-11来源:作者:点击数:
标签:
Web应用是互联网最普遍的应用之一,因此也使你的 网络 极易遭遇入侵导致敏感资料被窃、数据被篡改、或者甚至威胁到系统的安危。确保Web应用安全是一个很迫切的任务,并且需要贯穿设计、 开发 、配置和实施阶段的考虑。不能只把它看作附加在现有应用上的一些
Web应用是互联网最普遍的应用之一,因此也使你的网络极易遭遇入侵导致敏感资料被窃、数据被篡改、或者甚至威胁到系统的安危。确保Web应用安全是一个很迫切的任务,并且需要贯穿设计、开发、配置和实施阶段的考虑。不能只把它看作附加在现有应用上的一些事物,或者认为应用现有平台的安全特征就很容易实现的。
即使依托相关安全平台发展,Web应用也必须追随最好的贯穿设计、开发、配置整个阶段的安全平台来最大程度的避免遭遇攻击。为了开发出安全的Web应用,这个详细而精确的平台设计需要结合安全设计实践、威胁模拟分析和安全渗透检验知识。
这篇文章论述了怎样采用ASP.NET 2.0 and IIS 6.0的安全机制去建立安全的Web应用的实践。
Web安全应用设计
安全设计原则通常可归结为几个关键原则:假设所有的系统输入都是恶意的,减少系统外露信息,采用默认值,使用深度防卫而不依靠系统其他部分来保护。按照这些普遍原则来进行设计是确保你的应用尽好的被保护的关键。
威胁模拟分析是用来制订系统数据溢出和检查可能的恶意入侵点。威胁模拟分析是从设计者的角色换为入侵者的角色去检查你的设计的关键必要的练习,可以帮助发现潜在的安全漏洞。要了解更多的关于威胁模拟的知识,请到威胁模拟分析。
安全渗透检验又一种攻击你的应用——在别人入侵之前去破坏你的应用以求发现问题的方法。你可以尝试发送无效或最坏数据使你的应用达到极限。你也可以利用你了解的它的内部只是来破坏你的应用程序——这样,你所来了解的内部知识赋予你相对于一般的入侵者无可比拟的优势,或许可以挖掘出深藏在你的代码内部的脆弱点。有各种各样的工具可以帮助你来做安全渗透检验。
资源保护
通常,配置Web应用的第一个任务是确保敏感信息不能被因特网上的匿名用户访问。如果是企业内部网,通常是通过鉴别是否为
Windows®系统的注册用户(并会有更多的权限控制)来实现这点的,并通过防火墙来限制外部访问。对于因特网,这种做法就是问题了,因为它至少要保证匿名用户也能访问。除了这点不同,下面的这种方案也不能同时保护Inte
.net 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访问的路径
原文转自:http://www.ltesting.net
- 评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)
-