淺談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的合法性。那用什麼呢?這裡就要用到正規表達式了。
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表示感謝!如果有什麼錯漏之處,還希望各位指出!