如果您希望看到關鍵字過濾算法的話那么可能就要失望了。博客園中已經有不少關于此類算法的文章（例如這里和這里），雖然可能無法直接滿足特定需求，但是已經足夠作為參考使用。而本文的目的，是給出一個較為完整的關鍵字過濾功能，也就是將用戶輸入中的敏感字符進行替換——這兩者有什么區別？那么就請繼續看下去吧。:)

有趣的需求

　　關鍵字過濾功能自然無比重要，但是如果要在代碼中對每個輸入進行檢查和替換則會是一件非常費神費事的事情。尤其是如果網站已經有了一定規模，用戶輸入功能已經遍及各處，而急需對所有輸入進行關鍵字過濾時，上述做法更可謂“遠水解不了近渴”。這時候，如果有一個通用的辦法，呼得一下為整站的輸入加上了一道屏障，那該是一件多么愜意的事情。這就是本文希望解決的問題。是不是很簡單？我一開始也這么認為，不過事實上并非那么一帆風順，而且在某些特定條件下似乎更是沒有太好的解決方法……

　　您慢坐，且聽我慢慢道來……

實現似乎很簡單

　　數據結構中的單向鏈表可謂無比經典。有人說：單向鏈表的題目好難啊，沒法逆序查找，很多東西都不容易做。有人卻說：單向鏈表既然只能向一個方向遍歷，那么變化就會很有限，所以題目不會過于復雜。老趙覺得后者的說法不無道理。例如在現在的問題上，我們如果要在一個ASP.NET應用程序中做一個統一的“整站方案”，HttpModule似乎是唯一的選擇。

　　思路如下：我們在Request Pipeline中最早的階段（BeginRequest）將請求的QueryString和Form集合中的值做過濾，則接下來的ASP.NET處理過程中一切都為“規范”的文字了。說干就干，不就是替換兩個NameValueCollection對象中的值嗎？這再簡單不過了：

public class FilterForbiddenWordModule : IHttpModule
{
    void IHttpModule.Dispose() { }

    void IHttpModule.Init(HttpApplication context)
    {
        context.BeginRequest += new EventHandler(OnBeginRequest);
    }

    private static void OnBeginRequest(object sender, EventArgs e)
    {
        var request = (sender as HttpApplication).Request;
        ProcessCollection(request.QueryString);
        ProcessCollection(request.Form);
    }

    private static void ProcessCollection(NameValueCollection collection)
    {
        var copy = new NameValueCollection();

        foreach (string key in collection.AllKeys)
        {
            Array.ForEach(
                collection.GetValues(key),
                v => copy.Add(key, ForbiddenWord.Filter(v)));
        }

        collection.Clear();
        collection.Add(copy);
    }
}

　　在BeginRequest階段，我們將調用ProcessCollection將QueryString和Form兩個NameValueCollection中的值使用ForbiddenWord.Filter方法進行處理。ForbiddenWord是一個靜態類，其中的Filter方法會將原始字符串中的敏感字符使用“**”進行替換。替換方法不在本文的討論范圍內，因此我們就以如下方式進行簡單替換：

public static class ForbiddenWord
{
    public static string Filter(string original)
    {
        return original.Replace("FORBIDDEN_WORD", "**");
    }
}

　　看似沒有問題，OK，隨便打開一張頁面看看……

Collection is read-only.

　　呀，只讀……這是怎么回事？不就是一個NameValueCollection嗎？在不得不請出.NET Reflector之后，老趙果然發現其中有貓膩……

public class HttpRequest
{ 
    ...

    public NameValueCollection Form
    {
        get
        {
            if (this._form == null)
            {
                this._form = new HttpValueCollection();
                if (this._wr != null)
                {
                    this.FillInFormCollection();
                }
                this._form.MakeReadOnly();
            }
            if (this._flags[2])
            {
                this._flags.Clear(2);
                ValidateNameValueCollection(this._form, "Request.Form");
            }
            return this._form;
        }
    }

    ...
}

　　雖然HttpRequest.Form屬性為NameValueCollection類型，但是其中的_form變量事實上是一個HttpValueCollection對象。而HttpValueCollection自然是NameValueCollection的子類，而造成其“只讀”的最大原因便是：

[Serializable]
internal class HttpValueCollection : NameValueCollection
{ 
    ...

    internal void MakeReadOnly()
    {
        base.IsReadOnly = true;
    } 

    ...
}

　　IsReadOnly是定義在NameValueCollection基類NameObjectCollectionBase上的protected屬性，這意味著如果我們只有編寫一個如同NameValueCollection或HttpValueCollection般的子類才能直接訪問它，而現在……反射吧，兄弟們。

public class FilterForbiddenWordModule : IHttpModule
{
    private static PropertyInfo s_isReadOnlyPropertyInfo;

    static FilterForbiddenWordModule()
    {
        Type type = typeof(NameObjectCollectionBase);
        s_isReadOnlyPropertyInfo = type.GetProperty(
            "IsReadOnly",
            BindingFlags.Instance | BindingFlags.NonPublic);
    }

    ...

    private static void ProcessCollection(NameValueCollection collection)
    {
        var copy = new NameValueCollection();

        foreach (string key in collection.AllKeys)
        {
            Array.ForEach(
                collection.GetValues(key),
                v => copy.Add(key, ForbiddenWord.Filter(v)));
        }

        // set readonly to false.
        s_isReadOnlyPropertyInfo.SetValue(collection, false, null);

        collection.Clear();
        collection.Add(copy);

        // set readonly to true.
        s_isReadOnlyPropertyInfo.SetValue(collection, true, null);
    }   
}

　　現在再打開個頁面看看，似乎沒事。那么就來體驗一下這個HttpModule的功效吧。我們先準備一個空的aspx頁面，加上以下代碼：

<form id="form1" runat="server">
    <asp:TextBox runat="server" TextMode="MultiLine" />
    <asp:Button runat="server" Text="Click" />
form>

　　打開頁面，在文本框內填寫一些敏感字符并點擊按鈕：

　　嗨，效果似乎還不錯！

問題來了

　　太簡單了，是不？

　　可惜問題才剛開始：如果業務中有些字段不應該被替換怎么辦？例如“密碼”。如果我們只做到現在這點，那么密碼“let-us-say-shit”和“let-us-say-fuck”則會被認為相同——服務器端邏輯接收到的都是“let-us-say-**”。也就是說，我們必須提供一個機制，讓上面的HttpModule可以“忽略”掉某些內容。

　　如果是其他一些解決方案，我們可以在客戶端進行一些特殊標記。例如在客戶端增加一個“-noffw-password”字段來表示忽略對“password”字段的過濾。不過根據著名的“Don't trust the client”原則，這種做法應該是第一個被否決掉的。試想，如果某些哥們發現了這一點（別說“不可能”），那么想要繞開這種過濾方式實在是一件非常容易的事情。不過我們應該可以把這種“約定”直接運用在字段名上。例如原本我們如果取名為“password”的字段，現在直接使用“-noffw-password”，而HttpModule發現了這種前綴就會放它一馬。由于字段的命名完全是由服務器端決定，因此采取這種方式之后客戶端的惡人們就無法繞開我們的過濾了。

　　還有一種情況就是我們要對某些特定的字段采取一些特殊的過濾方式。例如，之前相當長的一段時間內我認為在服務器端反序列化一段JSON字符串是非常不合理的，不過由于AJAX幾乎成了事實標準，亦或是現在的Web應用程序經常需要傳遞一些結構復雜的對象，JSON格式已經越來越多地被服務器端所接受。假如一個字段是表示一個JSON字符串，那么首先我們只應該對它的“值”進行過濾，而忽略其中的“鍵”。對于這種字段，我們依舊可以使用如上的命名約定來進行忽略。例如，我們可以使用-json-data的方法來告訴服務器端這個字段應該被當作JSON格式進行處理。

　　如何？

　　其實問題遠沒有解決——盡情期待《一個較完整的關鍵字過濾解決方案（下）》。