免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

一、SQL注入漏洞

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

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

因?yàn)?br>

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

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

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

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

那么解決之道便是在執(zhí)行SQL查詢之前對(duì)嵌入SQL語句的姓名和密碼進(jìn)行過濾。常用的一個(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

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

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è)問題，一個(gè)是留言內(nèi)容安全性問題，一個(gè)留言發(fā)布驗(yàn)證碼問題。

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

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

在感覺上這樣是沒有什么問題，但是我如果在留言版輸入如下代碼：

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

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

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

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

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

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

除了重置Session、重復(fù)留言判斷外還有一個(gè)方法就是每次頁面加載時(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圖片上傳問題

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

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

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

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

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

舉個(gè)簡單例子：

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

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

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