先來說URL編碼，%加兩位的16進制表示一個字符，比如’經過編碼之后就是%27，這是人人都知道的URL編碼規則，UrlUnescapeInPlace之類的API函數甚至于程序員自己寫的URL譯碼函數都是基于這一思想。

然而，我們何必如此聽話，試想一下要是%后跟的不是16進制數字而是像abc%hh會發生什么事呢。先看UrlUnescapeInPlace，

寫個小程序試一下，abc%hh經過譯碼還是abc%hh；再看asp.dll是怎么譯碼的，在asp頁面中寫入 response.Write(request.QueryString("str"))，然后用?str=abc%hh訪問它，頁面顯示abchh，它直接把%給去掉了。

現在來思考要是我們提交sele%ct，信息監控系統得到的字符串還是sele%ct，當然它不是危險字符，它就不會攔截，但對于ASP，它得到的可就是select了，其它的同理，’可用%’表示，比如and exists(select * from admin)可轉化為以下字符串a%nd ex%ists(%select * %from ad%min)。此方法可舉一反三，比如用%%代替%都可以，還可以是其它的，具體的可以去看RFC2396。

以上僅是對于GET方式的分析，POST沒試過，不過猜想也是可以的。并且經測試以上方法對目前的所有IIS防火墻都有效，包括VIF。

補充：其實發現這個漏洞已經有好些日子了，本來我是不想公開的，前些天兩次給一流信息監控的人發郵件提醒他們，但他們就是沒認真考慮我說的問題，還說一流信息系統可以把經過編碼的注入字符也加到過濾清單中，不知道他們是怎么想的，他是覺得再加一條sele%ect過濾規則就可以了？那sele%%ct呢，也加上？那sele%%%ct呢？？鑒于一流這種無所謂的態度我就公開此漏洞，希望他們能以此為鑒。

責任編輯 趙毅 zhaoyi#51cto.com TEL:（010）68476636-8001