領先技術: 子類化和重寫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”。