ASP檔案中的安全問題

淺談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的合法性。那用什麼呢？這裡就要用到Regex了。
可以通過id=cint(request("id"))或clng，或者就是用Regex替換所有的非數字字元，這樣就只有數字了。（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是個強大的東西，它最常用的功能就是用戶端的檢測，比如不許輸入Null 字元，或者定義Regex完成更進階的檢測，有的程式員覺得這很好，瀏覽器協助驗證了，用戶端就減少了很多工作量，伺服器負擔也小了，效能也最佳化了。但現在的瀏覽器幾乎都提供了取消javascript支援的選項，也就是說，用戶端提交的資訊可能根本就沒有經過檢測就被提交給伺服器了。這個時候你那節省下來的伺服器資源在安全性面前就顯得微不足道了，所以說用戶端和伺服器端的驗證都需要，甚至你在用戶端可以沒有任何驗證，伺服器端都必須有驗證。
這同樣適合於處理站外提交的資訊。站外提交也可以跳過用戶端驗證的，最簡單的做法就是右鍵查看你的表單源碼，複製到本地，把action的值改成網路地址，然後去掉用戶端驗證的內容。即使他能夠躲過你的站外提交檢測代碼，也無法跳過伺服器端的驗證。當然，如果他提交的內容沒問題，很正常，那站外提交的東西儲存也就儲存了——可是，如果是這樣，他還搞這麼複雜幹什麼呢？
五、總結。
事實上所有asp可能出現的問題都和一個問題有關，那就是錯誤。要麼是程式寫法上出現的錯誤，要麼是用戶端提交錯誤參數導致的錯誤。ASP有一個錯誤處理機制，建議大家寫到每頁都要包含進去的那個頁面裡，就是on error resume next，忽略錯誤繼續執行，哪怕錯誤導致頁面什麼也顯示不出來，它也不會向用戶端透露一點錯誤的內容，有了它能解決不少問題。但最終ASP的安全還是要靠程式員的細心，對於每個可能出現問題的地方都加以處理，這樣的程式才會變得安全。
本文參考了atmo相關文章的很多內容，在此向atmo表示感謝！如果有什麼錯漏之處，還希望各位指出！
大家可以多參考下網站上發布的一些webshell攻擊與防範的文章。