程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle數據庫基礎 >> 詳解SQL注入攻擊的原理及其防御措施

詳解SQL注入攻擊的原理及其防御措施

編輯:Oracle數據庫基礎

ASP編程門檻很低,新手很容易上路。在一段不長的時間裡,新手往往就已經能夠編出看來比較完美的動態網站,在功能上,老手能做到的,新手也能夠做到。那麼新手與老手就沒區別了嗎?這裡面區別可就大了,只不過外行人很難一眼就看出來罷了。在界面的友好性、運行性能以及網站的安全性方面是新手與老手之間區別的三個集中點。而在安全性方面,新手最容易忽略的問題就是SQL注入漏洞的問題。用NBSI 2.0對網上的一些ASP網站稍加掃描,就能發現許多ASP網站存在SQL注入漏洞,教育網裡高校內部機構的一些網站這種漏洞就更普遍了,可能這是因為這些網站大都是一些學生做的緣故吧,雖然個個都很聰明,可是畢竟沒有經驗,而且處於學習中,難免漏洞多多了。本文主要講講SQL注入的防范措施,而要明白這些防范措施的用處,須先詳細講解利用SQL注入漏洞入侵的過程。新手們看明白啦。

相當大一部分程序員在編寫代碼的時候,沒有對用戶輸入數據的合法性進行判斷,使應用程序存在安全隱患。如這是一個正常的網址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區下的自動猜解按鈕。激動人心的時刻就要到來啦,只見唰唰地幾下,帳號與密碼全部出來了。剩下的事就是辨別哪一個帳號是管理員了。

ASP編程門檻很低,新手很容易上路。在一段不長的時間裡,新手往往就已經能夠編出看來比較完美的動態網站,在功能上,老手能做到的,新手也能夠做到。那麼新手與老手就沒區別了嗎?這裡面區別可就大了,只不過外行人很難一眼就看出來罷了。在界面的友好性、運行性能以及網站的安全性方面是新手與老手之間區別的三個集中點。而在安全性方面,新手最容易忽略的問題就是SQL注入漏洞的問題。用NBSI 2.0對網上的一些ASP網站稍加掃描,就能發現許多ASP網站存在SQL注入漏洞,教育網裡高校內部機構的一些網站這種漏洞就更普遍了,可能這是因為這些網站大都是一些學生做的緣故吧,雖然個個都很聰明,可是畢竟沒有經驗,而且處於學習中,難免漏洞多多了。本文主要講講SQL注入的防范措施,而要明白這些防范措施的用處,須先詳細講解利用SQL注入漏洞入侵的過程。新手們看明白啦。

相當大一部分程序員在編寫代碼的時候,沒有對用戶輸入數據的合法性進行判斷,使應用程序存在安全隱患。如這是一個正常的網址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 SQLServer 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區下的自動猜解按鈕。激動人心的時刻就要到來啦,只見唰唰地幾下,帳號與密碼全部出來了。剩下的事就是辨別哪一個帳號是管理員了。

不知那些沒注意過SQL注入漏洞的ASP程序員們看了上圖的例子,要作何感想呢?是不是覺得這個所謂的網站安全漏洞檢測工具SBSI 2.0簡直就是MS_SQL的企業管理器呢?只不過人家不需要帳號和密碼就可以查看您數據庫裡的所有信息了。如果您的網站就這樣被人不費吹灰之力入侵了,您是不是要吐幾升血了呢?也許您已經為系統安全費盡心思了,裝補丁、安防火牆、裝殺毒軟件、巧妙配置IIS及數據庫用戶權限,但您就是沒有注意到SQL注入漏洞,於是"千裡之堤,潰於蟻穴"。防火牆與殺毒軟件對SQL注入是沒辦法防范的,因為SQL注入入侵跟普通的WEB頁面訪問沒什麼區別,所以往往是防不甚防。而且一個服務器上放置的網站往往是有很多個的,服務器管理員不可能挨個網站挨個頁面的審查其是否存在SQL注入漏洞。那麼應該如何防范SQL注入入侵呢?作為服務器管理員或網站程序員應該分別怎麼做呢?服務器管理員要做的事主要是配置IIS和數據庫用戶權限,而網站程序員主要是要在程序代碼編寫上防范SQL注入入侵。下面詳細敘述:

對了服務器管理員,既然你不可能挨個檢查每個網站是否存在SQL注入漏洞,那麼就來個一個絕招。這個絕招能有效防止SQL注入入侵而且"省心又省力,效果真好!"SQL注入入侵是根據IIS給出的ASP錯誤提示信息來入侵的,如果你把IIS設置成不管出什麼樣的ASP錯誤,只給出一種錯誤提示信息,即http 500錯誤,那麼人家就沒辦法入侵了。具體設置請參看圖2。主要把500:100這個錯誤的默認提示頁面 C:WindowsHelpIISHelpcommon500-100.ASP改成

C:WindowsHelpIISHelpcommon500.htm即可,這時,無論ASP運行中出什麼錯,服務器都只提示HTTP 500錯誤。

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

服務器管理員還應在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頁面中,記住,只要加一行這樣的[an error occurred while processing this directive]代碼就行了。

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

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

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved