领先技术: 子类化和重写ASP.NET页面 - 第II部分
最近一个很偶然的机会，我发现了一个大型网站，上面全是一些极其简单的 Web 用户控件，确切地说是一些 ASCX 文件。开发人员在发现所使用的服务器控件会出现异常行为后，往往认为这种方法是很有必要的。 因此，开发人员将站点内的这类服务器控件全部更换为包含原始控件修改版本的用户控件（同时由于无法确定更换服务器控件会导致何种后果，因此开发人员还替换了其他大量控件。）开发人员认为，将这样一种额外的抽象层置于页面和控件之间会更可靠。另外一个好处就是可以在 ASP.NET 应用程序中轻松替换用户控件（如果需要的话），而无需修改二进制文件和重新启动应用程序。（这种情况并非始终都会发生，但有些部署方案会要求执行该操作。） 曾经有公司请我来审阅应用程序，他们问我的第一个问题就是：“是否有更好的方法可以在不大量返工每个页面的情况下替换整个站点的服务器控件？” 我在自己主持的 2007 年 4 月专栏中，针对如何在不修改原始源代码的情况下对 ASP.NET 网站进行有限的（有时是临时的）修改给出了几种解决方案。本月我又发现几种技巧，无需修改源代码，通过声明的方式即可替换服务器控件和 URL。 当时我无法立即回答他们的问题，但却知道如何找到解决方法。我想如果是我开发了 ASP.NET 基础结构，我会在配置文件中放置某种设置，以便开发人员能够通过声明的方式将标记映射到控件。在 ASP.NET 中这并非是一个全新的理念。早在 ASP.NET 1.x 中，您就可以通过声明的方式更改一些与代码相关的内容，例如网页和用户控件的基类。（但是，这种方法只适用于未在 Page 指令中显式使用 Inherits 子句的页面和用户控件。）因此我产生了一个疑问，为什么服务器控件不可以采取这种方法呢。事实证明我当时的推断是正确的：ASP.NET 2.0 正是为此才提供了 <tagMapping> 节。 背景知识 我想还是先向大家介绍一些背景知识。此方案始于一次内部安全审查，当时客户发现应用程序内存在一个可能导致经典 SQL 注入式攻击的漏洞。公司对这一漏洞应用了快速修补程序，但却导致了另一个问题。 在客户的网站上，许多页面都允许查询字符串中包含固定的五字符代码。这种代码会随后用于构成 SQL 语句。该公司当时仍在运行类似以下内容的代码： Dim code As String = Request.QueryString(“Code”).ToString(); Dim command As String = _ “SELECT * FROM customers WHERE id=’” & code & “’” 说心里话，我真的希望您的网站已经不再运行类似代码！这种代码完全盲目地信任任何通过查询字符串传递的信息，并会将该信息附加到构成 SQL 命令的字符串。这样做会形成非常严重的安全隐患。手段高明的黑客能够轻而易举地发现那些看似正常、实则危险的文本，它们能够将原始的和为特定目的编写的 SQL 命令变成危险的攻击。如果您需要更多有关 SQL 注入的详细信息，建议您先阅读 Paul Litwin 撰写的文章“Stop SQL Injection Attacks Before They Stop You”。 从性能方面考虑，发送动态构建的命令是不明智的。这些命令不会从重用查询计划中获益，因为代码本身在每次提交时都可能发生变化。使用参数化查询或存储过程有两大优势：一是它能确保至少对发送的数据类型进行一次自动检查，二是它能够从 SQL Server™ 和其他数据库中的查询计划缓存中获得好处。 正如“领先技术”2007 年 3 月刊中所述，您应该像验证控制台实用程序的命令行那样静态地对查询字符串进行验证。这样可以避免数字、日期和布尔值的歧义，但如果是字符串，您就无可奈何了。在这里，问题的关键是字符串中到底包含哪些内容。您需要使用某种业务逻辑仔细地验证传递的字符串。但验证 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
