淺談ASP的安全問題
先說句牢騷話，我經(jīng)常看到有人說ASP不安全，比如容易被注入，這種說法我一直感到無法理解。如果你水平不高，那么你用php用ASP.net用JSP都有被注入的可能，這關(guān)ASP什么事？ASP只是一種技術(shù)，用它開發(fā)的網(wǎng)站是否安全，只跟程序員和服務(wù)器管理員的水平有關(guān)系，任何技術(shù)開發(fā)的網(wǎng)站都一樣。只要你的程序有漏洞，而且你用的數(shù)據(jù)庫支持標準SQL語法，或者注入者會這種語法，那么就存在被注入的可能。
閑話少說，我今天結(jié)合我個人的經(jīng)驗來簡單說說ASP中常見的安全問題。

一，注入。無論什么時候講到網(wǎng)站的安全問題，SQL注入都是首當(dāng)其沖的。我們先來看看SQL注入是怎么回事。簡單的說，SQL注入就是通過各種方式傳遞非法的參數(shù)，其方式和目的無法是以下幾種：
?期望程序出錯，從而從服務(wù)器返回的錯誤信息中獲得一些注入者想要的東西，這種方法常用來判斷數(shù)據(jù)庫的類型。
?執(zhí)行特殊語句，用來猜解表名等。
?構(gòu)造特殊語句，這個常常就是用來繞過登錄檢測取得管理權(quán)限的。
針對以上問題，我一般采用以下的應(yīng)對方法：
?前面兩種情況應(yīng)該一起考慮。無論是哪種注入方式，其實都是通過構(gòu)造非法的參數(shù)來實現(xiàn)的，那么我們就通過程序來限制參數(shù)，給合法的參數(shù)制定一個規(guī)則，不符合這個規(guī)則的就是非法的。但在檢測時經(jīng)常見出現(xiàn)下面的錯誤：
1，用isnumeric函數(shù)來檢測id。這個函數(shù)僅僅是判斷是否是數(shù)字，僅此而已，那么如果我這樣輸入一個url：shownews.asp?id=1.1，那么也會通過檢測，因為1.1也是數(shù)字，或者id=0也行。有這樣的id嗎？沒有，任何數(shù)據(jù)庫表中的id都是從1開始的正整數(shù)。所以請大家不要這樣再使用它來檢測id的合法性。那用什么呢？這里就要用到正則表達式了。
可以通過id=cint(request("id"))或clng，或者就是用正則表達式替換所有的非數(shù)字字符，這樣就只有數(shù)字了。（asp下替換非數(shù)字為空的正則）

2，缺少錯誤處理，或錯誤處理不完善。比如rs.eof的情況，不加處理的話，我寫個id=999999999999999，那么程序就會出錯，我相信絕少有哪個網(wǎng)站有如此大的id，即使有我還可以換個更大的。我曾經(jīng)就遇到過有人用工具連續(xù)試探我的id，從8000測試到10000多。還有就是type參數(shù)，一般網(wǎng)站的新聞都會分好幾個欄目，這時都依靠type來確定每個列表頁面該顯示哪個欄目的內(nèi)容，如果有人提交一個不存在的type值呢？這也需要處理，select case中的case else子句就是為這種意外情況準備的，別為了省事不去用它。
?繞過登錄檢測的問題大多數(shù)是因為程序員把登錄檢測語句寫成這樣：