淺談ASP的安全問(wèn)題
先說(shuō)句牢騷話，我經(jīng)?？吹接腥苏f(shuō)ASP不安全，比如容易被注入，這種說(shuō)法我一直感到無(wú)法理解。如果你水平不高，那么你用php用ASP.net用JSP都有被注入的可能，這關(guān)ASP什么事？ASP只是一種技術(shù)，用它開發(fā)的網(wǎng)站是否安全，只跟程序員和服務(wù)器管理員的水平有關(guān)系，任何技術(shù)開發(fā)的網(wǎng)站都一樣。只要你的程序有漏洞，而且你用的數(shù)據(jù)庫(kù)支持標(biāo)準(zhǔn)SQL語(yǔ)法，或者注入者會(huì)這種語(yǔ)法，那么就存在被注入的可能。

閑話少說(shuō)，我今天結(jié)合我個(gè)人的經(jīng)驗(yàn)來(lái)簡(jiǎn)單說(shuō)說(shuō)ASP中常見的安全問(wèn)題。

一，注入。

無(wú)論什么時(shí)候講到網(wǎng)站的安全問(wèn)題，SQL注入都是首當(dāng)其沖的。我們先來(lái)看看SQL注入是怎么回事。簡(jiǎn)單的說(shuō)，SQL注入就是通過(guò)各種方式傳遞非法的參數(shù)，其方式和目的無(wú)法是以下幾種：
·期望程序出錯(cuò)，從而從服務(wù)器返回的錯(cuò)誤信息中獲得一些注入者想要的東西，這種方法常用來(lái)判斷數(shù)據(jù)庫(kù)的類型。
·執(zhí)行特殊語(yǔ)句，用來(lái)猜解表名等。
·構(gòu)造特殊語(yǔ)句，這個(gè)常常就是用來(lái)繞過(guò)登錄檢測(cè)取得管理權(quán)限的。

針對(duì)以上問(wèn)題，我一般采用以下的應(yīng)對(duì)方法：
前面兩種情況應(yīng)該一起考慮。無(wú)論是哪種注入方式，其實(shí)都是通過(guò)構(gòu)造非法的參數(shù)來(lái)實(shí)現(xiàn)的，那么我們就通過(guò)程序來(lái)限制參數(shù)，給合法的參數(shù)制定一個(gè)規(guī)則，不符合這個(gè)規(guī)則的就是非法的。但在檢測(cè)時(shí)經(jīng)常見出現(xiàn)下面的錯(cuò)誤：

1，用isnumeric函數(shù)來(lái)檢測(cè)id。

這個(gè)函數(shù)僅僅是判斷是否是數(shù)字，僅此而已，那么如果我這樣輸入一個(gè)url：shownews.asp?id=1.1，那么也會(huì)通過(guò)檢測(cè)，因?yàn)?.1也是數(shù)字，或者id=0也行。有這樣的id嗎？沒有，任何數(shù)據(jù)庫(kù)表中的id都是從1開始的正整數(shù)。所以請(qǐng)大家不要這樣再使用它來(lái)檢測(cè)id的合法性。那用什么呢？這里就要用到正則表達(dá)式了。
可以通過(guò)id=cint(request("id"))或clng，或者就是用正則表達(dá)式替換所有的非數(shù)字字符，這樣就只有數(shù)字了。（asp下替換非數(shù)字為空的正則）

2，缺少錯(cuò)誤處理，或錯(cuò)誤處理不完善。

比如rs.eof的情況，不加處理的話，我寫個(gè)id=999999999999999，那么程序就會(huì)出錯(cuò)，我相信絕少有哪個(gè)網(wǎng)站有如此大的id，即使有我還可以換個(gè)更大的。我曾經(jīng)就遇到過(guò)有人用工具連續(xù)試探我的id，從8000測(cè)試到10000多。還有就是type參數(shù)，一般網(wǎng)站的新聞都會(huì)分好幾個(gè)欄目，這時(shí)都依靠type來(lái)確定每個(gè)列表頁(yè)面該顯示哪個(gè)欄目的內(nèi)容，如果有人提交一個(gè)不存在的type值呢？這也需要處理，select case中的case else子句就是為這種意外情況準(zhǔn)備的，別為了省事不去用它。
繞過(guò)登錄檢測(cè)的問(wèn)題大多數(shù)是因?yàn)槌绦騿T把登錄檢測(cè)語(yǔ)句寫成這樣代碼：

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

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

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

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

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

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

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