一、SQL注入漏洞

這里舉一個(gè)簡(jiǎn)單的例子，在ASP站點(diǎn)的登陸頁(yè)面中輸入以下內(nèi)容

用戶名:admin
密   碼:' or ''='

因?yàn)?br>

rs.open "select * from userdata where name='"&name&"' and pass='&pass&'"

想必大家都知道這個(gè)語(yǔ)句怎么用，但是如果合并上述用戶名和密碼后，這個(gè)SQL語(yǔ)句就是

rs.open "select * from userdata where name='admin' and pass='' or ''=''"

想必大家能看明白是怎么回事情了吧。

那么解決之道便是在執(zhí)行SQL查詢之前對(duì)嵌入SQL語(yǔ)句的姓名和密碼進(jìn)行過(guò)濾。常用的一個(gè)Replace函數(shù)為：

Function ReplaceBadChar(strChar)
if strChar="" then
   ReplaceBadChar=""
   Exit Function
end if
ReplaceBadChar=Replace(ReplaceBadChar,"'","")
ReplaceBadChar=Replace(ReplaceBadChar,"*","")
ReplaceBadChar=Replace(ReplaceBadChar,"?","")
ReplaceBadChar=Replace(ReplaceBadChar,"(","")
ReplaceBadChar=Replace(ReplaceBadChar,")","")
ReplaceBadChar=Replace(ReplaceBadChar,"<","")
ReplaceBadChar=Replace(ReplaceBadChar,">","")
ReplaceBadChar=Replace(ReplaceBadChar,".","")
End Function

這種方法采用的是過(guò)濾非法字符，難免有考慮不周全的地方。那么換一個(gè)思路：只選擇安全字符！
但是我們不愿意為了選擇A～Z以及a～z和0～9這些字符寫(xiě)上62條Replace語(yǔ)句或者Instr語(yǔ)句，考慮使用正則表達(dá)式變?nèi)菀椎亩嘁埠?jiǎn)潔得多了：

Function dealUserName(userName)
Dim RegExpObj
Dim resultStr

Set RegExpObj=new RegExp
RegExpObj.Global = True
RegExpObj.Pattern="[^a-zA-Z0-9_]" '只允許字母、數(shù)字和下劃線
resultStr = RegExpObj.replace(userName,"")
  
Set RegExpObj=nothing
dealUserName=resultStr
End Function

二、留言版和信息發(fā)布

這里里面存在兩個(gè)問(wèn)題，一個(gè)是留言內(nèi)容安全性問(wèn)題，一個(gè)留言發(fā)布驗(yàn)證碼問(wèn)題。

·留言內(nèi)容安全性問(wèn)題
這個(gè)問(wèn)題比那個(gè)漏洞能差點(diǎn)，至少你數(shù)據(jù)能保住。一般設(shè)計(jì)留言版都直接使用這樣的模式：

存：rs("MsgContent")=表單提交信息
?。?lt;%=rs("MsgContent")%>

在感覺(jué)上這樣是沒(méi)有什么問(wèn)題，但是我如果在留言版輸入如下代碼：

<script language="javascript">while (true){ window.open("程序炸彈地址 /bomb.htm","","fullscreen=yes,Status=no,scrollbars=no,resizable=no");}</script>

最容易想到的解決方法是Replace過(guò)濾，但是這并不是一個(gè)好的方法，因?yàn)檫^(guò)濾或許使得很多內(nèi)容不能正確顯示；
當(dāng)然采用UBB模式是一個(gè)解決途徑，這也是網(wǎng)上多數(shù)留言系統(tǒng)所兼容的輸入模式；
另外一個(gè)推薦的方法是使用Server.HTMLEncode()這個(gè)函數(shù)，可以把用戶輸入的HTML代碼按照原樣顯示出來(lái)，而不會(huì)直接執(zhí)行。

·留言發(fā)布驗(yàn)證碼問(wèn)題
！?。◎?yàn)證碼成功發(fā)布留言后，要重置Session！?。?/p>

網(wǎng)上多數(shù)驗(yàn)證碼采用的模式是產(chǎn)生一個(gè)隨機(jī)字符串，然后存入Session并繪制成圖片輸出到客戶端，這在一定程度上避免了自動(dòng)發(fā)帖機(jī)的批量發(fā)帖，但是存在這么一個(gè)問(wèn)題：

在發(fā)帖成功后使用history.back()或者使用后退返回上級(jí)再次點(diǎn)擊提交留言仍能再次發(fā)布（如果留言板沒(méi)有重復(fù)留言過(guò)濾功能的話）?。?！

這當(dāng)然不是我們所想要的，問(wèn)題根源所在就是在保存了留言之后沒(méi)有重置Session，導(dǎo)致用戶再次同樣提交時(shí)仍是Session匹配的，此時(shí)驗(yàn)證碼形同虛設(shè)！

除了重置Session、重復(fù)留言判斷外還有一個(gè)方法就是每次頁(yè)面加載時(shí)使用JS腳本重置驗(yàn)證碼：
<div id="CheckCode"></div>
<script language="javascript">
window.onload=dealImg;
function dealImg()
{
document.getElementById("CheckCode").innerHTML='<img src="http://sojuker.blog.163.com/blog/checkCode.asp?rand='+ Math.random() +'"/>';
}
</script>

三、FSO圖片上傳問(wèn)題

犯這個(gè)錯(cuò)誤的人已經(jīng)很少了，不過(guò)不表示沒(méi)有。在上傳圖片的時(shí)候不限制擴(kuò)展名。

比如我傳一個(gè)ASP的FSO木馬或者通過(guò)SHELL執(zhí)行程序。以及其他方式，就可以完全操控服務(wù)器！

四、URL字符串參數(shù)安全問(wèn)題

這個(gè)問(wèn)題的嚴(yán)重級(jí)別說(shuō)大不大說(shuō)小不小，這要看你傳遞的參數(shù)的重要性了。要知道任何有惡意的人都

可以隨便修改URL參數(shù)，程序在接收到參數(shù)之后是否應(yīng)該進(jìn)行嚴(yán)格檢查呢？不言而喻。

舉個(gè)簡(jiǎn)單例子：

在多數(shù)根據(jù)ID查詢的功能中都是通過(guò)URL傳遞ID值的，而且不加控制就放在了SQL語(yǔ)句中：

rs.open "select * from newsdata where id="&trim(Requst.QueryString("id"))

可想而知，這個(gè)問(wèn)題是多么的嚴(yán)重?。?！------cint