淺談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ù)庫支持標(biāo)準(zhǔn)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的合法性。那用什么呢？這里就要用到正則表達(dá)式了。
可以通過id=cint(request("id"))或clng，或者就是用正則表達(dá)式替換所有的非數(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子句就是為這種意外情況準(zhǔn)備的，別為了省事不去用它。
繞過登錄檢測的問題大多數(shù)是因為程序員把登錄檢測語句寫成這樣代碼：

Sql="select count(*) from Admin where UserName='"&UserName&"' and Pwd='"&Pwd&"'" 
if rs(0) > 0 then.... 

這個時候的注入就是用or注入，構(gòu)造出一個特殊的sql語句： 
Sql="select count(*) from Admin where UserName='' or ''='' and Pwd='' or ''='' " 
這就是在用戶名和密碼的文本框都輸入 ' or ''='' 構(gòu)造出來的，這個時候count(*)的結(jié)果必然大于0，它等于你的admin表的記錄數(shù)，因為每條記錄都符合select語句的要求。當(dāng)然我們可以通過制定相應(yīng)的規(guī)則來過濾這種注入信息，同時輔助其他方法，比如我是這樣寫的代碼：
"select password from Admin where username='"&UserName&"'" 
if rs.eof then 
... 
else 
if rs("password")=request.form("pass") then 
... 
end if 
end if 

這樣的寫法，即使你沒有制定任何規(guī)則，那么上述方式也基本無法注入，因為它只能通過第一步檢測，在后面的if rs("password")=request.form("pass") then 這里它就沒有辦法了，因為不會有人給管理員設(shè)置' or ''='' 這樣的密碼。這就沒法相等，登錄必然被拒絕。當(dāng)然，為了穩(wěn)妥起見，最好兩種辦法同時使用，確保萬無一失。 
注入還有一種經(jīng)常被人忽略的情況，就是cookie注入。在一個參數(shù)既可能通過url傳遞，又可能通過表單傳遞的時候，大多數(shù)人都會簡寫為request("page")這樣的方式。你輕松了，注入者也輕松了，因為request在不制定具體方法的時候，它嘗試接收參數(shù)的順序是QueryString/Form/Cookie，如果注入者偽造一個cookie，然后在瀏覽器中輸入www.gxlsystem.com/shownews.asp，如果shownews.asp里面寫的是request，它就不會報錯，因為程序從cookie中找到了id，如果沒有對這個參數(shù)進行檢測，那么注入就可能發(fā)生了。這里建議大家用select case或者if來判斷，麻煩了一點，但安全第一呀。 

二，ASP上傳漏洞。
用過幾種無組件上傳類，大同小異，都缺乏對上傳文件類型的有效檢測，這個問題比較郁悶，現(xiàn)在只能依靠其他手段來手動檢測，而且都是在服務(wù)器端的。如果說ASP本身有什么問題的話，就在這里了。 

三，后臺權(quán)限判斷。
看過幾個后臺，權(quán)限判斷都是只在登錄的第一個頁面判斷權(quán)限，后臺的每個頁面都沒有判斷了。后臺所有頁面都是需要判斷權(quán)限的，否則我在瀏覽器里直接輸入某個功能頁面的地址就可以暢通無阻了，你那個后臺登錄還做它干什么呢？ 

四、忽略服務(wù)器端驗證。
javascript是個強大的東西，它最常用的功能就是客戶端的檢測，比如不許輸入空字符，或者定義正則表達(dá)式完成更高級的檢測，有的程序員覺得這很好，瀏覽器幫助驗證了，客戶端就減少了很多工作量，服務(wù)器負(fù)擔(dān)也小了，性能也優(yōu)化了。但現(xiàn)在的瀏覽器幾乎都提供了取消javascript支持的選項，也就是說，客戶端提交的信息可能根本就沒有經(jīng)過檢測就被提交給服務(wù)器了。這個時候你那節(jié)省下來的服務(wù)器資源在安全性面前就顯得微不足道了，所以說客戶端和服務(wù)器端的驗證都需要，甚至你在客戶端可以沒有任何驗證，服務(wù)器端都必須有驗證。 
這同樣適合于處理站外提交的信息。站外提交也可以跳過客戶端驗證的，最簡單的做法就是右鍵查看你的表單源碼，復(fù)制到本地，把action的值改成網(wǎng)絡(luò)地址，然后去掉客戶端驗證的內(nèi)容。即使他能夠躲過你的站外提交檢測代碼，也無法跳過服務(wù)器端的驗證。當(dāng)然，如果他提交的內(nèi)容沒問題，很正常，那站外提交的東西保存也就保存了——可是，如果是這樣，他還搞這么復(fù)雜干什么呢？ 

五、總結(jié)。 
事實上所有asp可能出現(xiàn)的問題都和一個問題有關(guān)，那就是錯誤。要么是程序?qū)懛ㄉ铣霈F(xiàn)的錯誤，要么是客戶端提交錯誤參數(shù)導(dǎo)致的錯誤。ASP有一個錯誤處理機制，建議大家寫到每頁都要包含進去的那個頁面里，就是on error resume next，忽略錯誤繼續(xù)執(zhí)行，哪怕錯誤導(dǎo)致頁面什么也顯示不出來，它也不會向客戶端透露一點錯誤的內(nèi)容，有了它能解決不少問題。但最終ASP的安全還是要靠程序員的細(xì)心，對于每個可能出現(xiàn)問題的地方都加以處理，這樣的程序才會變得安全。 
本文參考了atmo相關(guān)文章的很多內(nèi)容，在此向atmo表示感謝！如果有什么錯漏之處，還希望各位指出！ 
大家可以多參考下網(wǎng)站上發(fā)布的一些webshell攻擊與防范的文章。