相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。如這是一個正常的網址http://localhost/lawjia/show.asp?ID=444，將這個網址提交到服務器后，服務器將進行類似Select * from 表名 where 字段="&ID的查詢(ID即客戶端提交的參數，本例是即444)，再將查詢結果返回給客戶端，如果這里客戶端故意提交這么一個網址：

　　http://localhost/lawjia/show.asp?ID=444 and user>0，這時，服務器運行Select * from 表名 where 字段=444 and user>0這樣的查詢，當然，這個語句是運行不下去的，肯定出錯，錯誤信息如下：

　　·錯誤類型：

Microsoft OLE DB Provider for ODBC Drivers (0x80040E07)
[Microsoft][ODBC SQL Server Driver][SQL Server]將 nvarchar 值 'sonybb' 轉換為數據類型為 int 的列時發生語法錯誤。
/lawjia/show.asp, 第 47 行

　　但是別有用心的人從這個出錯信息中，可以獲得以下信息：該站使用MS＿SQL數據庫，用ODBC連接，連接帳號名為：sonybb。所謂SQL注入（SQL Injection），就是利用程序員對用戶輸入數據的合法性檢測不嚴或不檢測的特點，故意從客戶端提交特殊的代碼，從而收集程序及服務器的信息，從而獲取想得到的資料。通常別有用心者的目標是獲取網站管理員的帳號和密碼。比如當某個人知道網站管理員帳號存在表login中，管理員帳號名為admin，他想知道管理員密碼，這里他從客戶端接著提交這樣一個網址：
http://localhost/lawjia/show.asp?ID=444 and (Select password from login where user_name='admin')>0，返回的出錯信息如下：

　　·錯誤類型：

Microsoft OLE DB Provider for ODBC Drivers (0x80040E07)
[Microsoft][ODBC SQL Server Driver][SQL Server]將 varchar 值 '！＠＃＊＆admin' 轉換為數據類型為 int 的列時發生語法錯誤。
/lawjia/show.asp, 第 47 行

　　你知道嗎？上面標紅的部分就是管理員帳號admin的密碼！雖然很復雜，讓人看幾遍也記不住的，但它就這樣顯示在你面前了，這時您就可以用這個帳號和密碼接管人家的網站了！這時你可能還會說，如果他不是事先知道管理員帳號存在表login中，而且知道管理員帳號為admin，那他就不可能獲得管理員密碼。你錯了，只要人家愿意多花時間嘗試，他將可以獲得數據庫連接帳號權限內所能獲得的所有信息！具體過程請參看網上的這篇文章：SQL注入漏洞全接觸。

　　當然這個過程是很煩瑣的而且要花費很多的時間，如果只能以這種手動方式進行SQL注入入侵的話，那么許多存在SQL注入漏洞的ASP網站會安全很多了，不是漏洞不存在了，而是利用這個漏洞入侵的成本太高了。但是如果利用專門的黑客工具來入侵的話，那情況就大大不同了。手動方式進行SQL注入入侵至少需要半天或一天乃至很多天的時間，而利用專門的工具來入侵就只需要幾分鐘時間了（視網速快慢決定），再利用獲得的管理帳號和密碼，上傳一個從網上下載的ASP后門程序，就輕易獲得整個網站的管理權限了，甚至整個服務器的管理權限。最有名的一種SQL注入入侵工具是NBSI 2.0，現在已經出到2.0版本了，不過，人家正式名稱不叫SQL注入入侵工具，而叫做網站安全漏洞檢測工具。有了這個所謂的檢測工具，使得入侵存在SQL注入漏洞的ASP網站成了小兒科的游戲，那些既不懂ASP又不懂SQL、年紀小小的男性青年常常得以在一天之內入侵十多個ASP網站，他們以此獲得內心的極大滿足。他們似乎也非常講究職業道德，往往并不破壞網站數據和系統，常見的破壞方式大都僅僅是改換掉網站的主頁，留下"善意的警告"，如：你的網站存在SQL注入漏洞，請管理員做好防范措施！并聲明"我沒有破壞數據和系統"，有的還要借機發布一下他的倡導："國內網站大家不要入侵，有本事入侵小日本的！"，最后，簽上他的鼎鼎大名是必不可少的程序。

　　如此大的成就多數情況下僅需動動鼠標就做到了。打開最新版的NBSI 2.0，如圖1所示：輸入地址到A區，注意網址必須是帶傳遞參數的那種，點擊右邊的檢測按鈕，即出來B區信息，顯示當前用戶為sonybb的權限為PUBLIC，當前庫為lawjia。有點可惜啊，如果是SA權限的話，就可以跨庫注入了。不過，這個權限也足夠獲取該網站管理員帳號和密碼了。點C區下的自動猜解按鈕，即出來當前庫lawjia中的各種表，哇，login表中一定是存管理員帳號和密碼的吧？選中它吧，接著點擊D區下的自動猜解按鈕，立即出來login表里的列名稱，果然是存放用戶名和密碼的啊，太棒了！趕快打上勾，迫不急待的點擊E區下的自動猜解按鈕。激動人心的時刻就要到來啦，只見唰唰地幾下，帳號與密碼全部出來了。剩下的事就是辨別哪一個帳號是管理員了。

圖1（圖中的示例網站在作者本地電腦上運行）

圖2、IIS出錯信息設置

　　但是這樣設置一個不好的地方是程序員編寫的代碼出錯時，服務器不給出詳細的錯誤提示信息，會給程序員帶來很大的不便。不過，服務器畢竟不是測試代碼的地方，應堅持安全穩定第一，這樣設置也是無可厚非的，事實上許多服務器的出錯信息都是如此設置。

　　服務器管理員還應在IIS中為每個網站設置好執行權限，可千萬別給人家靜態網站以"腳本和可執行"權限。一般情況下給個"純腳本"權限就夠了，對于那些通過網站后臺管理中心上傳的文件存放的目錄，就更吝嗇一點吧，執行權限設為"無"好了，這樣做是為了防止人家上傳ASP木馬，執行權限設為"無"，人家上傳ASP木馬也運行不了。一般情況下，SQL注入漏洞僅是涉及一個網站安全的事，如果人家通過這個漏洞上傳了ASP木馬并運行起來，那整個服務器都失陷了。所以有遠見的、有責任心的服務器管理員應該十分吝嗇的配置IIS的執行權限。

　　同樣的吝嗇態度應適用于數據庫用戶的權限配置上，當然這里數據庫是指MS＿SQL啦，ACCESS都沒有用戶權限配置這一步驟。如果PUBLIC權限足夠使用的絕不給再高的權限，可千萬別把SA級別的權限隨隨便便地給人家啊。那個所謂的網站安全漏洞檢測工具NBSI 2.0可有跨庫進行SQL注入的功能啊，如果你把SA權限給了存在SQL注入漏洞的庫，那其它庫就不保啦！城門失火，殃及池魚呀。而人家還可以通過調用xp_cmdshell命令得到系統的最高權限。具體步驟還是請參看上面提到的那篇《SQL注入漏洞全接觸》這篇文章吧。

　　接下來要講講程序員的防范措施了。程序主要要做兩件事，最重要的一件事，當然是對客戶端提交的變量參數進行仔細地檢測啦。對客戶端提交的變量進行檢查以防止SQL注入，有各種方法，到http://community.csdn.net/上搜索一下，你能獲得許多有益信息。這里介紹一種現成的方法，別人已經寫好了檢測代碼，拿來用一下，不用自己辛苦啦。那就是"楓葉SQL通用防注入V1.0 ASP版"，這是一段對用戶通過網址提交過來的變量參數進行檢查的代碼，發現客戶端提交的參數中有"exec、insert、select、delete、from、update、count、user、xp_cmdshell、add、net、Asc"等用于SQL注入的常用字符時，立即停止執行ASP并給出警告信息或轉向出錯頁面。大家可以到網上搜索一下，下載這段代碼，存為一個ASP頁面，如checkSQL.asp，把這個頁面include到每個需要帶參數查詢SQL數據庫ASP頁面中，記住，只要加一行這樣的<!--#include file="checkSQL.asp"-->代碼就行了。

　　程序員要做的第二件事是給用戶密碼加密啦。比如用MD5加密。MD5是沒有反向算法,不能解密的。人家即使知道經加密后存在數據庫里的像亂碼一樣的密碼，他也沒辦法知道原始密碼了。不過，人家可以用UPDATE方法用他的密碼代替你的密碼，但這個操作還是有點麻煩，人家可能會怕麻煩而放棄。而那個所謂的網站安全漏洞檢測工具NBSI 2.0是沒有提供UPDATE操作功能的，所以用MD5加密后，人家僅用NBSI 2.0而不輔以手動操作的話，就不可能獲得網站管理員帳號的密碼，這將擋住許多菜鳥級的攻擊者，至少那些既不懂ASP又不懂SQL、年紀小小的男性青年是沒有辦法啦！

　　文章寫到這，已經夠長了，本來還想對那些所謂的網站安全漏洞檢測工具如NBSI之流的黑客工具進行一番理性的探討的，看來還是放棄好了。為了增強網站安全，了解攻擊手段是必須的，但是，利用漏洞開發專門的黑客工具，使那些其實并不具備必要的網絡技術和網絡安全知識的人（就是文中提到的"既不懂ASP又不懂SQL、年紀小小的男性青年"）輕而易舉地侵入一家網站，這除了為許多網絡管理員制造麻煩外，是否還具有加強網絡安全意識提高網絡安全水平的功效呢？