淺談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子句就是為這種意外情況准備的，別為了省事不去用它。
·繞過登錄檢測的問題大多數是因為程序員把登錄檢測語句寫成這樣：
復制代碼 代碼如下:
Sql="Select count(*) from Admin Where UserName='"&UserName&"' and Pwd='"&Pwd&"'"
if rs(0) > 0 then....
這個時候的注入就是用or注入，構造出一個特殊的sql語句：
Sql="Select count(*) from Admin Where UserName='' or ''='' and Pwd='' or ''='' "
這就是在用戶名和密碼的文本框都輸入 ' or ''='' 構造出來的，這個時候count(*)的結果必然大於0，它等於你的admin表的記錄數，因為每條記錄都符合select語句的要求。當然我們可以通過制定相應的規則來過濾這種注入信息，同時輔助其他方法，比如我是這樣寫的：
復制代碼 代碼如下:
"select password from Admin where username='"&UserName&"'"
if rs.eof then
...
else
if rs("password")=request.form("pass") then
...
end if
end if
這樣的寫法，即使你沒有制定任何規則，那麼上述方式也基本無法注入，因為它只能通過第一步檢測，在後面的if rs("password")=request.form("pass") then 這裡它就沒有辦法了，因為不會有人給管理員設置' or ''='' 這樣的密碼。這就沒法相等，登錄必然被拒絕。當然，為了穩妥起見，最好兩種辦法同時使用，確保萬無一失。
注入還有一種經常被人忽略的情況，就是cookie注入。在一個參數既可能通過url傳遞，又可能通過表單傳遞的時候，大多數人都會簡寫為request("page")這樣的方式。你輕松了，注入者也輕松了，因為request在不制定具體方法的時候，它嘗試接收參數的順序是QueryString/Form/Cookie，如果注入者偽造一個cookie，然後在浏覽器中輸入www.sitename.com/shownews.asp，如果shownews.asp裡面寫的是request，它就不會報錯，因為程序從cookie中找到了id，如果沒有對這個參數進行檢測，那麼注入就可能發生了。這裡建議大家用select case或者if來判斷，麻煩了一點，但安全第一呀。
二，ASP上傳漏洞。用過幾種無組件上傳類，大同小異，都缺乏對上傳文件類型的有效檢測，這個問題比較郁悶，現在只能依靠其他手段來手動檢測，而且都是在服務器端的。如果說ASP本身有什麼問題的話，就在這裡了。
三，後台權限判斷。看過幾個後台，權限判斷都是只在登錄的第一個頁面判斷權限，後台的每個頁面都沒有判斷了。後台所有頁面都是需要判斷權限的，否則我在浏覽器裡直接輸入某個功能頁面的地址就可以暢通無阻了，你那個後台登錄還做它干什麼呢？
四、忽略服務器端驗證。javascript是個強大的東西，它最常用的功能就是客戶端的檢測，比如不許輸入空字符，或者定義正則表達式完成更高級的檢測，有的程序員覺得這很好，浏覽器幫助驗證了，客戶端就減少了很多工作量，服務器負擔也小了，性能也優化了。但現在的浏覽器幾乎都提供了取消javascript支持的選項，也就是說，客戶端提交的信息可能根本就沒有經過檢測就被提交給服務器了。這個時候你那節省下來的服務器資源在安全性面前就顯得微不足道了，所以說客戶端和服務器端的驗證都需要，甚至你在客戶端可以沒有任何驗證，服務器端都必須有驗證。
這同樣適合於處理站外提交的信息。站外提交也可以跳過客戶端驗證的，最簡單的做法就是右鍵查看你的表單源碼，復制到本地，把action的值改成網絡地址，然後去掉客戶端驗證的內容。即使他能夠躲過你的站外提交檢測代碼，也無法跳過服務器端的驗證。當然，如果他提交的內容沒問題，很正常，那站外提交的東西保存也就保存了——可是，如果是這樣，他還搞這麼復雜干什麼呢？
五、總結。
事實上所有asp可能出現的問題都和一個問題有關，那就是錯誤。要麼是程序寫法上出現的錯誤，要麼是客戶端提交錯誤參數導致的錯誤。ASP有一個錯誤處理機制，建議大家寫到每頁都要包含進去的那個頁面裡，就是on error resume next，忽略錯誤繼續執行，哪怕錯誤導致頁面什麼也顯示不出來，它也不會向客戶端透露一點錯誤的內容，有了它能解決不少問題。但最終ASP的安全還是要靠程序員的細心，對於每個可能出現問題的地方都加以處理，這樣的程序才會變得安全。
本文參考了atmo相關文章的很多內容，在此向atmo表示感謝！如果有什麼錯漏之處，還希望各位指出！
大家可以多參考下網站上發布的一些webshell攻擊與防范的文章。
