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

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

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