最近一個(gè)很偶然的機會(huì )，我發(fā)現了一個(gè)大型網(wǎng)站，上面全是一些極其簡(jiǎn)單的 Web 用戶(hù)控件，確切地說(shuō)是一些 ASCX 文件。開(kāi)發(fā)人員在發(fā)現所使用的服務(wù)器控件會(huì )出現異常行為后，往往認為這種方法是很有必要的。
因此，開(kāi)發(fā)人員將站點(diǎn)內的這類(lèi)服務(wù)器控件全部更換為包含原始控件修改版本的用戶(hù)控件（同時(shí)由于無(wú)法確定更換服務(wù)器控件會(huì )導致何種后果，因此開(kāi)發(fā)人員還替換了其他大量控件。）開(kāi)發(fā)人員認為，將這樣一種額外的抽象層置于頁(yè)面和控件之間會(huì )更可靠。另外一個(gè)好處就是可以在 ASP.NET 應用程序中輕松替換用戶(hù)控件（如果需要的話(huà)），而無(wú)需修改二進(jìn)制文件和重新啟動(dòng)應用程序。（這種情況并非始終都會(huì )發(fā)生，但有些部署方案會(huì )要求執行該操作。）
曾經(jīng)有公司請我來(lái)審閱應用程序，他們問(wèn)我的第一個(gè)問(wèn)題就是：“是否有更好的方法可以在不大量返工每個(gè)頁(yè)面的情況下替換整個(gè)站點(diǎn)的服務(wù)器控件？”
我在自己主持的
2007 年 4 月專(zhuān)欄中，針對如何在不修改原始源代碼的情況下對 ASP.NET 網(wǎng)站進(jìn)行有限的（有時(shí)是臨時(shí)的）修改給出了幾種解決方案。本月我又發(fā)現幾種技巧，無(wú)需修改源代碼，通過(guò)聲明的方式即可替換服務(wù)器控件和 URL。
當時(shí)我無(wú)法立即回答他們的問(wèn)題，但卻知道如何找到解決方法。我想如果是我開(kāi)發(fā)了 ASP.NET 基礎結構，我會(huì )在配置文件中放置某種設置，以便開(kāi)發(fā)人員能夠通過(guò)聲明的方式將標記映射到控件。在 ASP.NET 中這并非是一個(gè)全新的理念。早在 ASP.NET 1.x 中，您就可以通過(guò)聲明的方式更改一些與代碼相關(guān)的內容，例如網(wǎng)頁(yè)和用戶(hù)控件的基類(lèi)。（但是，這種方法只適用于未在 Page 指令中顯式使用 Inherits 子句的頁(yè)面和用戶(hù)控件。）因此我產(chǎn)生了一個(gè)疑問(wèn)，為什么服務(wù)器控件不可以采取這種方法呢。事實(shí)證明我當時(shí)的推斷是正確的：ASP.NET 2.0 正是為此才提供了 <tagMapping> 節。
背景知識
我想還是先向大家介紹一些背景知識。此方案始于一次內部安全審查，當時(shí)客戶(hù)發(fā)現應用程序內存在一個(gè)可能導致經(jīng)典 SQL 注入式攻擊的漏洞。公司對這一漏洞應用了快速修補程序，但卻導致了另一個(gè)問(wèn)題。
在客戶(hù)的網(wǎng)站上，許多頁(yè)面都允許查詢(xún)字符串中包含固定的五字符代碼。這種代碼會(huì )隨后用于構成 SQL 語(yǔ)句。該公司當時(shí)仍在運行類(lèi)似以下內容的代碼：
Dim code As String = Request.QueryString(“Code”).ToString();Dim command As String = _“SELECT * FROM customers WHERE id=’” & code & “’”說(shuō)心里話(huà)，我真的希望您的網(wǎng)站已經(jīng)不再運行類(lèi)似代碼！這種代碼完全盲目地信任任何通過(guò)查詢(xún)字符串傳遞的信息，并會(huì )將該信息附加到構成 SQL 命令的字符串。這樣做會(huì )形成非常嚴重的安全隱患。手段高明的黑客能夠輕而易舉地發(fā)現那些看似正常、實(shí)則危險的文本，它們能夠將原始的和為特定目的編寫(xiě)的 SQL 命令變成危險的攻擊。如果您需要更多有關(guān) SQL 注入的詳細信息，建議您先閱讀 Paul Litwin 撰寫(xiě)的文章“
Stop SQL Injection Attacks Before They Stop You”。
從性能方面考慮，發(fā)送動(dòng)態(tài)構建的命令是不明智的。這些命令不會(huì )從重用查詢(xún)計劃中獲益，因為代碼本身在每次提交時(shí)都可能發(fā)生變化。使用參數化查詢(xún)或存儲過(guò)程有兩大優(yōu)勢：一是它能確保至少對發(fā)送的數據類(lèi)型進(jìn)行一次自動(dòng)檢查，二是它能夠從 SQL Server? 和其他數據庫中的查詢(xún)計劃緩存中獲得好處。
正如
“領(lǐng)先技術(shù)”2007 年 3 月刊中所述，您應該像驗證控制臺實(shí)用程序的命令行那樣靜態(tài)地對查詢(xún)字符串進(jìn)行驗證。這樣可以避免數字、日期和布爾值的歧義，但如果是字符串，您就無(wú)可奈何了。在這里，問(wèn)題的關(guān)鍵是字符串中到底包含哪些內容。您需要使用某種業(yè)務(wù)邏輯仔細地驗證傳遞的字符串。但驗證字符串長(cháng)度并不難，不管是通過(guò) HTTP 模塊還是通過(guò)有限地修改代碼，都是可以實(shí)現的。
原始解決方案
發(fā)現 SQL 注入漏洞后，客戶(hù)認為將可接受參數的大小限制為五個(gè)字符（即代碼的實(shí)際大?。┚湍芸旖萦行У亟鉀Q問(wèn)題。僅有五個(gè)可用的字符，黑客是奈何不了您的數據庫– 至少希望是這樣的。因此，客戶(hù)安裝了“領(lǐng)先技術(shù)”2007 年 3 月刊中演示的 HTTP 模塊，并檢查了受影響頁(yè)面的查詢(xún)字符串大小。結果發(fā)現實(shí)際發(fā)送到頁(yè)面的字符未超過(guò)五個(gè)。
但是，該應用程序組合了新的 ASP.NET 頁(yè)面和經(jīng)過(guò)修改的經(jīng)典 ASP 頁(yè)面，其中某些頁(yè)面能夠允許用戶(hù)在文本框內鍵入并提交相同的代碼。而在服務(wù)器上，指定的代碼會(huì )在回發(fā)過(guò)程中通過(guò)前述的相同方法附加到 SQL 語(yǔ)句中。因此，通過(guò)文本框提交的文本長(cháng)度也需要進(jìn)行同樣的限制。開(kāi)發(fā)人員原以為這是個(gè)簡(jiǎn)單的問(wèn)題，因此將文本框的 MaxLength 屬性設置為所需的值：
<asp:textbox runat=”server” id=”TextBox1” MaxLength=”5” />
修復過(guò)的問(wèn)題看上去萬(wàn)無(wú)一失。長(cháng)度超過(guò)五個(gè)字符的代碼無(wú)法進(jìn)入站點(diǎn)的中間層。但這并不一定意味著(zhù)站點(diǎn)處于可避免注入的安全狀態(tài)，但這種做法確實(shí)限制了遭受攻擊的可能性?；蛘哒f(shuō)他們是這么認為的。
模擬一次很簡(jiǎn)單的攻擊
假設有一個(gè)類(lèi)似于圖 1 所示的 ASP.NET 示例頁(yè)面。頁(yè)面的源代碼如
圖 2 所示。該頁(yè)面具有一個(gè) MaxLength 屬性為 5 的文本框和一個(gè)提交按鈕。單擊按鈕后，會(huì )執行回發(fā)操作并對文本框的內容進(jìn)行處理。正常情況下，在瀏覽器中顯示頁(yè)面的位置是無(wú)法鍵入五個(gè)以上的字符的。如果您嘗試粘貼更長(cháng)的文本字符串，字符串將被相應地截斷為指定長(cháng)度。
圖 1 ASP.NET 示例頁(yè)面 (單擊該圖像獲得較大視圖)
現在我們從攻擊者的角度考慮這個(gè)問(wèn)題。對網(wǎng)頁(yè)進(jìn)行攻擊通常需要先創(chuàng )建格式為 Plain HTML 的頁(yè)面副本，然后改變某些值并發(fā)布“破壞”版的頁(yè)面。要獲得頁(yè)面的 HTML，惡意用戶(hù)只需向普通用戶(hù)那樣顯示頁(yè)面：選擇“查看源代碼”，然后將內容保存為本地 HTML 文件。但這種方法只有在攻擊者可以實(shí)際訪(fǎng)問(wèn)頁(yè)面時(shí)才可能奏效。例如，如果頁(yè)面受到保護，攻擊者就必須出示有效憑據才能查看頁(yè)面。但是，被盜用的身份驗證 Cookie、網(wǎng)絡(luò )釣魚(yú)詐騙及其他社交詐騙術(shù)都可以使有用的信息流入不正當人的手中。
將 ASP.NET 頁(yè)的標記保存到本地機器后，攻擊者需要對其進(jìn)行一些更改。首先，攻擊者必須更改表單的 action 屬性，使其指向同一 ASP.NET 頁(yè)面的絕對 URL。以下是 ASP.NET 的 default.aspx 頁(yè)面的服務(wù)器表單的典型標記：
<form name=”form1” method=”post” action=”Default.aspx” id=”form1”>攻擊者會(huì )將其更改為以下內容：
<form name=”form1” method=”post”action=”http://targetserver/Source/Default.aspx” id=”form1”>
ASP.NET HtmlForm 控件上沒(méi)有 action 屬性，但當您使用 Plain HTML 時(shí)，仍可以將表單內容發(fā)布到任何需要的 URL。第二項需要更改的是將要發(fā)布的“破壞”數據。我要為 ASP.NET TextBox 服務(wù)器控件發(fā)出的標記設置一個(gè) value 屬性，將其設為遠大于規定五個(gè)字符的字符串：
<input name=”TextBox1” type=”text”maxlength=”5” id=”TextBox1”value=”This is a far looooonger text” />
當攻擊者在自己的計算機上顯示該 HTML 頁(yè)面并單擊按鈕時(shí)，您認為會(huì )發(fā)生什么？結果如圖 3 所示。左側瀏覽器窗口的地址欄指明所顯示的頁(yè)面為本地 HTML 頁(yè)。但在右側的瀏覽器窗口中，您會(huì )發(fā)現經(jīng)過(guò)修改的表單內容已發(fā)布到遠程 ASP.NET 應用程序。攻擊者避開(kāi)了五個(gè)字符的限制。這表明惡意用戶(hù)是有辦法發(fā)送文本框上任意大小的頁(yè)面文本的，無(wú)論 MaxLength 為何種設置。
圖 3 可發(fā)布任意長(cháng)度字符串的本地 HTML 頁(yè) (單擊該圖像獲得較大視圖)
其中的原理是什么呢？
您可能想知道問(wèn)題出在何處。是在瀏覽器中？還是在 ASP.NET 運行庫中？或者可能是 TextBox 控件中？沒(méi)錯，真正的問(wèn)題就出現在 TextBox 控件中。
如果含有 TextBox 服務(wù)器控件的頁(yè)面在回發(fā)后被重新創(chuàng )建在服務(wù)器上，則 TextBox 服務(wù)器控件將不會(huì )對 MaxLength 進(jìn)行檢查。很顯然，為了安全起見(jiàn)，在指定 Text 屬性之前，TextBox 應該檢查 MaxLength 的值，并將其與已發(fā)布文本的長(cháng)度進(jìn)行比較。
改進(jìn)后的 TextBox 控件
TextBox 位于服務(wù)器端，與 <input type=text> HTML 標記相對應，它可以接收用戶(hù)鍵入到輸入緩沖區內的文本。TextBox 需要對該文本進(jìn)行處理，以激活 TextChanged 服務(wù)器事件，并使頁(yè)面內的其他控件可以使用數據。處理已發(fā)布數據的 ASP.NET 控件可以實(shí)現 IPostBackDataHandler 接口，方法如下：
Public Interface IPostBackDataHandlerFunction LoadPostData(ByVal postDataKey As String, _ByVal postCollection As NameValueCollection) As BooleanSub RaisePostDataChangedEvent()End InterfaceLoadPostData 方法會(huì )檢查 TextBox 控件的回發(fā)數據是否與其前一個(gè)值不同，如果是，則加載該內容并返回 true。否則即返回 false。
還原每個(gè)控件視圖狀態(tài)的內容后，會(huì )立即在頁(yè)面的 Init 和 Load 事件之間調用 LoadPostData 方法。postDataKey 參數指示了已發(fā)布集合內的名稱(chēng)，該集合引用了要加載的內容。postCollection 參數引入了所有已發(fā)布值的集合 – 查詢(xún)字符串或表單集合，具體取決于所選的 HTTP 謂詞。
在生命周期中稍后會(huì )調用 RaisePostDataChangedEvent 方法，以觸發(fā)一項與控件相關(guān)的可選事件，該事件能夠指示控件的狀態(tài)在回發(fā)后是否被更改。在實(shí)踐中，只有在 LoadPostData 返回 true 時(shí)才會(huì )調用 RaisePostDataChangedEvent 方法。
圖 4 顯示的偽代碼顯示了為 System.Web.UI.WebControls.TextBox 控件實(shí)現 LoadPostData 方法?；旧?，該方法可將讀取自視圖狀態(tài)的 Text 屬性的值與已發(fā)布值進(jìn)行比較。如果兩個(gè)值不同，則已發(fā)布值將替換當前值，并成為控件 Text 屬性的新值。
如您所見(jiàn)，已發(fā)布的值被盲目地分配給 Text 屬性，而并未充分考慮字符串的長(cháng)度。通過(guò) LoadPostData 方法，每個(gè)控件都可以更新所需數量的屬性，并且可以交叉檢查對測試有意義的所有屬性。如
圖 4 所示，TextBox 實(shí)現 LoadPostData 方法，限制了驗證，使其只能確?？丶榉侵蛔x，進(jìn)而對新舊文本進(jìn)行比較。
圖 5 所示為一個(gè)全新的 TextBox 控件，其 LoadPostData 方法的實(shí)現稍有不同。重寫(xiě)的方法只是先將已發(fā)布文本截斷至允許的最大長(cháng)度，然后再進(jìn)行文本比較。如圖 6 所示，任何超過(guò)最大長(cháng)度的文本都會(huì )被自動(dòng)截斷，因此在回發(fā)過(guò)程中不會(huì )再用于生成更長(cháng)的結果。無(wú)論客戶(hù)端瀏覽器的功能如何，都會(huì )出現這種情況。
圖 6 超過(guò)最大長(cháng)度的文本會(huì )被“截斷” (單擊該圖像獲得較大視圖)
仔細比較
圖 4 和
圖 5 中 LoadPostData 方法的源代碼，您就會(huì )發(fā)現一個(gè)細微的差別。在
圖 4 中，方法在其基類(lèi)（System.Web.UI.Control 類(lèi)）上調用至 ValidateEvent。在
圖 5 中，同一代碼是通過(guò)調用 ClientScriptManager 對象上的 ValidateEvent 而被替換的：
Page.ClientScript.ValidateEvent(Me.UniqueID, String.Empty)
由于 Control 基類(lèi)上的 ValidateEvent 方法是聲明為 Friend（在 C# 內部），因此從 System.Web.dll 程序集之外定義的任何類(lèi)是無(wú)法調用它的。Control 基類(lèi)上的 ValidateEvent 方法的調用堆棧最終會(huì )調用 ClientScriptManager 對象上的 ValidateEvent 方法；ClientScriptManager 對象的實(shí)例則通過(guò) Page 類(lèi)的 ClientScript 屬性得以公開(kāi)。
ValidateEvent 是 ASP.NET 2.0 中可用于實(shí)現事件驗證的一個(gè)工具。事件驗證是一項內置功能，旨在避免頁(yè)面處理那些不是由頁(yè)面和已注冊控件專(zhuān)門(mén)生成的事件（和事件參數）。
替換 TextBox 控件
經(jīng)過(guò)一些列操作，現在您獲得了一個(gè)全新的 TextBox 控件。這個(gè)全新的控件可確保任何分配給 Text 屬性的超過(guò)最大長(cháng)度的文本都能被檢測到并得以刪除。您會(huì )在 ASP.NET 頁(yè)中使用此控件嗎？只需向每個(gè)頁(yè)面注冊該控件并替換出現的所有原始文本框即可。
在 ASP.NET 2.0 中，將以下配置腳本添加到 <pages> 塊的 <controls> 節下的 web.config 文件中，這樣您可以節省不少時(shí)間。
<add tagPrefix=”x” namespace=”Samples” assembly=”TextBox” />這段腳本保證 web.config 文件控制的所有頁(yè)面均可自動(dòng)注冊指定的標記和控件。
但目前仍存在一個(gè)問(wèn)題，而且是個(gè)很大的問(wèn)題。那就是如何在新舊文本框之間切換？幸運的是，ASP.NET 2.0 中的配置文件內提供了一個(gè) <tagMapping> 節：
<pages><tagMapping><add tagType=”System.Web.UI.WebControls.TextBox”mappedTagType=”Dino.Samples.TextBox” /></tagMapping></pages>
<tagMapping> 節允許您在編譯時(shí)將一種控件類(lèi)型重新映射到另一種控件類(lèi)型。通過(guò)這種重新映射，我們使用被映射的類(lèi)型替代了受配置文件控制的全部頁(yè)面和用戶(hù)控件的原始類(lèi)型根據前面給出的代碼，任何引用了系統 TextBox 的地方均將使用 Dino.Samples.TextBox。您要做的只是編寫(xiě)新控件并編輯 web.config 文件。這種簡(jiǎn)單的做法是不是有些不可思議？但確實(shí)是非常有效的。
毫無(wú)疑問(wèn)，重新映射的類(lèi)型必須為繼承自原始類(lèi)型的類(lèi)。還要指出的是，ASP.NET 團隊在 ASP.NET AJAX Extensions 1.0 的 pre-RTM build 中使用了此功能，以便使用可與 UpdatePanel 控件很好兼容的新驗證程序控件來(lái)替換原始控件。
最終的解決方案
客戶(hù)最終正確地診斷出 ASP.NET TextBox 控件及其處理已發(fā)布數據的方式存在問(wèn)題。他們通過(guò)創(chuàng )建新的 TextBox 控件令人滿(mǎn)意地修復了問(wèn)題。由于開(kāi)發(fā)人員之前并不了解有更好的方法或通過(guò)聲明的方式來(lái)替換整個(gè)站點(diǎn)的控件，因此他們手動(dòng)替換了所有出現的控件，并將其打包放入一個(gè)用戶(hù)控件中。這樣做是為了盡量降低將來(lái)的更改可能造成的影響。
有了 tagMapping 功能，找到解決方案簡(jiǎn)直易如反掌。使用 tagMapping 這一技巧比較靈活，可以用來(lái)替換錯誤的控件或者為現有控件添加新功能。但是請注意，如果重新映射的控件具有了新的屬性或方法，您需要修改源代碼才能使用這些新屬性和方法。
（提到以聲明的方式進(jìn)行映射，ASP.NET 2.0 還具有一個(gè)特性，即包含 <urlMappings> 節。它是 <configuration> 的直接子級。<urlMappings> 節在 ASP.NET 2.0 中是聲明性的，它對應的是 HttpContext 對象上的 RewritePath 方法。）
總之，您要注意，在設置了 MaxLength 之后，原始 ASP.NET TextBox 控件將無(wú)法對 Text 屬性的任何發(fā)布值進(jìn)行裁剪。但本專(zhuān)欄通過(guò)修改控件解決了這一限制，應該對您解決這一問(wèn)題有所幫助。您可以在 web.config 文件中新加一行簡(jiǎn)單的代碼，通過(guò)聲明的方式將其插入應用程序。
