淺談女站長12年建站風險經驗，讓您的網站更安全

淺談女站長12年建站風險經驗，讓您的網站更安全

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

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

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

注重程序的安全性。

　　　現在為止，很久沒有寫ASP了，改為用c#寫 ASP.NET，不可否認，ASP.NET由于結構的關系，確實容易比ASP做得更安全，

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

這個系統的代碼后，作很有針對性的攻擊。

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

　　　１.　注入SQL。

　　　２.　上傳木馬。

而對網站程序，或是所有B/S結構的程序的開發者而言，他們要作的，主要就是防這兩項，其它的都是小問題了，這兩個搞定，

網站一般就不那么容易被黑了。

　　１.　注入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的身份登錄了，我們再想一下，如果這個黑客，他多花點心思，就可以寫入一些修改數據庫，羅

列數據，破壞數據的語句，這就是SQL注入。

　　　那怎么注入SQL語句呢？

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

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

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

成了注入的切入點。

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

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

源。

　　如何防止SQL注入？

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

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

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

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

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

　　　第二，嚴謹規范的語句，這主要是寫　Request　時要小心。很多人，不管讀COOKIES,　GET提交的數據，POST　提交的數

據，　統統用一個 Request 來解決，　這個是很危險的。這是怎么回事呢？有一次，我發現我寫的程序，被人注入了，因為每

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

字符，就過濾掉，按理說應該很安全呀，結果后來，我發現我的程序，所有獲取數據時，都是寫的Request[“A”]，這樣的代碼

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

我就認真的成： Request.Form;Request.QueryString;Request.Cookies;

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

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

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

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

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

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

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

耐思尼克和我交流，我是耐思尼克虛擬主機SQL數據庫這個CMS系統的作者，還需要大家多支持。http://www.alapot.com/vhost/ahosting.php?s=lily