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