淺談女站長(zhǎng)12年建站風(fēng)險(xiǎn)經(jīng)驗(yàn)，讓您的網(wǎng)站更安全

淺談女站長(zhǎng)12年建站風(fēng)險(xiǎn)經(jīng)驗(yàn)，讓您的網(wǎng)站更安全

　　　我想寫這個(gè)文章，告訴一些開(kāi)始學(xué)習(xí)寫程序的人，怎么讓他的代碼更安全。

　　　從我寫ASP到現(xiàn)在，大約有12年了，我寫ASP的時(shí)候，那時(shí)用 WIN NT　4.0環(huán)境，安全性很不好，在地址后加幾個(gè)特殊字符

，就可以看到ASP的源代碼了，　后來(lái)，在多年寫ASP的過(guò)程中，碰到無(wú)數(shù)的黑客試圖黑我作的網(wǎng)站，花樣百出，因此我一直特別

注重程序的安全性。

　　　現(xiàn)在為止，很久沒(méi)有寫ASP了，改為用c#寫 ASP.NET，不可否認(rèn)，ASP.NET由于結(jié)構(gòu)的關(guān)系，確實(shí)容易比ASP做得更安全，

但是，在ASP中幾乎所有潛在的安全危險(xiǎn)，在ASP.NET中幾乎都存在，好處是ASP.NET源代碼不開(kāi)放，因此，黑客不太容易琢磨你

這個(gè)系統(tǒng)的代碼后，作很有針對(duì)性的攻擊。

　　實(shí)際上，我認(rèn)為，不管ASP，ASP.NET，PHP，JSP，甚至是C/S結(jié)構(gòu)的程序，都可能面臨兩個(gè)主要的共同的安全威脅：

　　�。�.　注入SQL。

　　�。�.　上傳木馬。

而對(duì)網(wǎng)站程序，或是所有B/S結(jié)構(gòu)的程序的開(kāi)發(fā)者而言，他們要作的，主要就是防這兩項(xiàng)，其它的都是小問(wèn)題了，這兩個(gè)搞定，

網(wǎng)站一般就不那么容易被黑了。

　�。�.　注入SQL，我們先看看什么是SQL注入，就是想辦法提交一個(gè)特殊的字符串，改變你的SQL語(yǔ)句，讓其變成其它的意思，

達(dá)到黑客的目的，我舉個(gè)非常簡(jiǎn)單例子，　比如，我要驗(yàn)證一個(gè)用戶的用戶名和密碼，如果找到了這個(gè)用戶，就讓他登錄，很多

入門的人，會(huì)寫這么一個(gè)SQL語(yǔ)句：

      SELECT * FROM USERS WHERE UserName='ADMIN'  and PassWord ='123456' 

這個(gè)語(yǔ)句看起來(lái)沒(méi)問(wèn)題,從用戶輸入的文本框中,得到用戶名和密碼，然后用他們來(lái)組裝SQL語(yǔ)句，如果找到這個(gè)記錄，說(shuō)明用戶

名和密碼正確，讓他登錄，如果找不到，說(shuō)明錯(cuò)誤，不讓他登錄，這看起來(lái)很完美，但實(shí)際上，這個(gè)語(yǔ)句完全沒(méi)有安全性，如果

用戶在密碼那里，　輸入一個(gè)　'   or 1=1  ，這樣一樣，我們看這個(gè)語(yǔ)句成了什么呢？

       SELECT * FROM USERS WHERE UserName='ADMIN'  and PassWord =''　or 1=1

  好了，　這樣他就能以ADMINA的身份登錄了，我們?cè)傧胍幌�，如果這個(gè)黑客，他多花點(diǎn)心思，就可以寫入一些修改數(shù)據(jù)庫(kù)，羅

列數(shù)據(jù)，破壞數(shù)據(jù)的語(yǔ)句，這就是SQL注入。

　　　那怎么注入SQL語(yǔ)句呢？

　　　方法很多，最簡(jiǎn)單的，　比如我們看很多網(wǎng)站，都有這樣的地址，比如： 這

樣的地址。這里我們要用 menuid 這個(gè)參數(shù)，往SQL語(yǔ)句中傳值，于是這成了一個(gè)注入的入口，這是最簡(jiǎn)單的。

　　　還有一種，很多網(wǎng)頁(yè)上，都要填寫表單，比如作站內(nèi)搜索，我們知道這個(gè)文本框提交之后，也會(huì)用來(lái)組裝SQL語(yǔ)句，這也

成了注入的切入點(diǎn)。

　　　第三種，用COOKIES，很多用站點(diǎn)，他會(huì)用一些COOKIES來(lái)保存一些用戶數(shù)據(jù)，比如讓用戶不掉線，過(guò)了SESSION的有效期

后，用COOKIES中的數(shù)據(jù)登錄一次，用戶看起來(lái)就不會(huì)掉線了。但這個(gè)COOKIES是可能被有的軟件改寫的，于是成了SQL注入的來(lái)

源。

　　如何防止SQL注入？

　　從上面，我們看到，凡是SQL注入，黑客必然會(huì)想辦法提交一些特殊的字符串給我們的程序，組裝出一個(gè)異常的SQL字符串，

那么，實(shí)際上要仿SQL注入，本質(zhì)上，就是要對(duì)客戶端提交的數(shù)據(jù)小心在意，我們可以用下面的辦法讓黑客的招數(shù)失效。

　　　第一，　過(guò)濾，所以要用來(lái)組裝SQL語(yǔ)句，并且這數(shù)據(jù)的來(lái)源是是從客戶端的來(lái)字符串，我們都對(duì)它進(jìn)行過(guò)濾，把一些危

險(xiǎn)可能用來(lái)注入SQL但實(shí)際上并不常用字符串過(guò)濾掉，比如單引號(hào)，大于號(hào)，小于號(hào)，等于號(hào)，空格之類，把這些過(guò)濾之后，黑

客就沒(méi)法組裝出正確的SQL語(yǔ)句，程序執(zhí)行到那里就會(huì)出錯(cuò)�！∷�就不能得逞了。

　　　第二，嚴(yán)謹(jǐn)規(guī)范的語(yǔ)句，這主要是寫　Request　時(shí)要小心。很多人，不管讀COOKIES,　GET提交的數(shù)據(jù)，POST　提交的數(shù)

據(jù)，　統(tǒng)統(tǒng)用一個(gè) Request 來(lái)解決，　這個(gè)是很危險(xiǎn)的。這是怎么回事呢？有一次，我發(fā)現(xiàn)我寫的程序，被人注入了，因?yàn)槊?

個(gè)語(yǔ)句去寫過(guò)濾的代碼太累了，所以我就在程序的前面，寫了一個(gè)遍歷所有GET,POST提交的數(shù)據(jù)的程序，只要發(fā)現(xiàn)這里面有非法

字符，就過(guò)濾掉，按理說(shuō)應(yīng)該很安全呀，結(jié)果后來(lái)，我發(fā)現(xiàn)我的程序，所有獲取數(shù)據(jù)時(shí)，都是寫的Request[“A”]，這樣的代碼

，沒(méi)有區(qū)別，結(jié)果黑客就自己假造了一個(gè)COOKIES，利用COOKIES比較優(yōu)先，從而繞過(guò)了我的過(guò)濾，成功的注入SQL,  從此之后，

我就認(rèn)真的成： Request.Form;Request.QueryString;Request.Cookies;

　　　第三，用存儲(chǔ)過(guò)程，有時(shí)，我們會(huì)碰到一些不能過(guò)濾，但又要用來(lái)作查詢條件的東西，這時(shí)怎么辦呢？用存儲(chǔ)過(guò)程，把這

些本來(lái)要用來(lái)組裝SQL語(yǔ)句的字符串，變成存儲(chǔ)過(guò)程的參數(shù)，在存儲(chǔ)過(guò)程中查詢，這樣，就避免了組裝SQL語(yǔ)句，不給黑客機(jī)會(huì)。

但也要注意，有一次，我看到一個(gè)程序員作的程序，他說(shuō)他用了存儲(chǔ)過(guò)程，還是被黑了，怎么回事呢？我看看，　發(fā)現(xiàn)這人，好

家伙，他把參數(shù)傳進(jìn)去，在存儲(chǔ)過(guò)程中過(guò)程中組裝成一個(gè) SQL字符串，再 EXEC　執(zhí)行他，　暈呀。

　　　我前面寫過(guò)一些我的經(jīng)驗(yàn)，有朋友說(shuō)要源代碼，其實(shí)，我覺(jué)得了解方法是最重要的，道理懂了，那幾個(gè)代碼，還不是很容

易的事？你不懂道理，拿到代碼又有何用？所以，我注重于介紹初學(xué)者一些方法，一些思路，而不是給一堆代碼了事。

　　　今天　先寫這些，其它的安全方面的問(wèn)題，我有時(shí)間接著寫，如果有興趣的朋友，　可以到

耐思尼克和我交流，我是耐思尼克虛擬主機(jī)SQL數(shù)據(jù)庫(kù)這個(gè)CMS系統(tǒng)的作者，還需要大家多支持。http://www.iisp.com/vhost/ahosting.php?s=lily