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

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

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

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

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

注重程序的安全性。

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

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

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

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

　　�。�.　注入SQL。

　　�。�.　上傳木馬。

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

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

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

達到黑客的目的，我舉個非常簡單例子，　比如，我要驗證一個用戶的用戶名和密碼，如果找到了這個用戶，就讓他登錄，很多

入門的人，會寫這么一個SQL語句：

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

這個語句看起來沒問題,從用戶輸入的文本框中,得到用戶名和密碼，然后用他們來組裝SQL語句，如果找到這個記錄，說明用戶

名和密碼正確，讓他登錄，如果找不到，說明錯誤，不讓他登錄，這看起來很完美，但實際上，這個語句完全沒有安全性，如果

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

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

  好了，　這樣他就能以ADMINA的身份登錄了，我們再想一下，如果這個黑客，他多花點心思，就可以寫入一些修改數(shù)據(jù)庫，羅

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

　　　那怎么注入SQL語句呢？

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

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

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

成了注入的切入點。

　　　第三種，用COOKIES，很多用站點，他會用一些COOKIES來保存一些用戶數(shù)據(jù)，比如讓用戶不掉線，過了SESSION的有效期

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

源。

　　如何防止SQL注入？

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

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

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

險可能用來注入SQL但實際上并不常用字符串過濾掉，比如單引號，大于號，小于號，等于號，空格之類，把這些過濾之后，黑

客就沒法組裝出正確的SQL語句，程序執(zhí)行到那里就會出錯。　它就不能得逞了。

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

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

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

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

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

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

　　　第三，用存儲過程，有時，我們會碰到一些不能過濾，但又要用來作查詢條件的東西，這時怎么辦呢？用存儲過程，把這

些本來要用來組裝SQL語句的字符串，變成存儲過程的參數(shù)，在存儲過程中查詢，這樣，就避免了組裝SQL語句，不給黑客機會。

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

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

　　　我前面寫過一些我的經(jīng)驗，有朋友說要源代碼，其實，我覺得了解方法是最重要的，道理懂了，那幾個代碼，還不是很容

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

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

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