日前SQL?INJECTION的攻擊測試愈演愈烈，很多大型的網(wǎng)站和論壇都相繼被注入。這些網(wǎng)站一般使用的多為SQL?SERVER數(shù)據(jù)庫SPAN>，正因為如此，很多人開始懷疑SQL?SERVER的安全性。其實SQL?SERVER?2000已經(jīng)通過了美國政府的C2級安全認證-這是該行業(yè)所能擁有的最高認證級別，所以使用SQL?SERVER還是相當?shù)陌踩摹．斎缓蚈RCAL、DB2等還是有差距，但是SQL?SERVER的易用性和廣泛性還是能成為我們繼續(xù)使用下去的理由。那怎么樣才能使SQL?SERVER的設(shè)置讓人使用的放心呢？

第一步肯定是打上SQL?SERVER最新的安全補丁，現(xiàn)在補丁已經(jīng)出到了SP3。下載地址： http://www.microsoft.com/sql/downloads/2000/sp3.asp。如果這一步都沒有做好，那我們也沒有繼續(xù)下去的必要了。

第二步是修改默認的1433端口，并且將SQL?SERVER隱藏。這樣能禁止對試圖枚舉網(wǎng)絡(luò)上現(xiàn)有的?SQL?Server?客戶端所發(fā)出的廣播作出響應。另外，還需要在TCP/IP篩選中將1433端口屏蔽掉，盡可能的隱藏你的SQL?SERVER數(shù)據(jù)庫SPAN>。這樣子一但讓攻擊創(chuàng)建了SQL?SERVER的賬號，也不能馬上使用查詢分析器遠程登陸來進行下一步的攻擊。單從ASP，PHP等頁面構(gòu)造惡意語句的話，還有需要查看返回值的問題，總比不上直接查詢分析器來得利落。所以我們首先要做到即使讓別人注入了，也不能讓攻擊者下一步做得順當。修改方法：企業(yè)管理器?-->?你的數(shù)據(jù)庫SPAN>組?-->?屬性?-->?常規(guī)?-->?網(wǎng)絡(luò)配置?-->?TCP/IP?-->?屬性?，在這兒將你的默認端口進行修改，和SQL?SERVER的隱藏。

第三步是很重要的一步，SQL?INJECTION往往在WEB?CODE中產(chǎn)生。而做為系統(tǒng)管理員或者數(shù)據(jù)庫SPAN>管理員，總不能常常的去看每一段代碼。即使常常看代碼，也不能保證我們在上面的疏忽。那怎么辦？我們就要從數(shù)據(jù)庫SPAN>角色著手，讓數(shù)據(jù)庫SPAN>用戶的權(quán)限劃分到最低點。SQL?SERVER的默認權(quán)限讓人真的很頭疼，權(quán)限大得非常的高，權(quán)限小的又什么都做不了，SYSADMIN和db_owner真是讓人又愛又恨。攻擊者一但確認了網(wǎng)站存在SQL?INJECTION漏洞，肯定有一步操作步驟就是測試網(wǎng)站的SQL?SERVER使用者具有多大的權(quán)限。一般都會借助SELECT?IS_SRVROLEMEMBER('sysadmin')，或者SELECT?IS_MEMBER('db_owner')，再或者用user?=?0(讓字符和數(shù)字進行比較，SQL?SERVER就會提示了錯誤信息，從該信息中即可知道一些敏感信息)等語句進行測試。方法還有，我也不敢多說了。其一怕錯，其二怕聯(lián)盟中的人扁。在當前，如果網(wǎng)站的數(shù)據(jù)庫SPAN>使用者用的是SA權(quán)限，再加上確認了WEB所處在的絕對路徑，那么就宣告了你的網(wǎng)站的OVER。db_owner權(quán)限也一樣，如果確認了絕對路徑，那么有50％的機會能給你的機器中上WEB?方式的木馬，如海陽等。所以這兒我們確認了一點，我們必須要創(chuàng)建自已的權(quán)限，讓攻擊者找不著下嘴的地方。在這兒引用一個SQL?SERVER聯(lián)機幫助中的例子：

創(chuàng)建?SQL?Server?數(shù)據(jù)庫SPAN>角色的方法（企業(yè)管理器）
創(chuàng)建?SQL?Server?數(shù)據(jù)庫SPAN>角色?
1.????????展開服務器SPAN>組，然后展開服務器SPAN>。
2.????????展開"數(shù)據(jù)庫SPAN>"文件夾，然后展開要在其中創(chuàng)建角色的數(shù)據(jù)庫SPAN>。
3.????????右擊"角色"，然后單擊"新建數(shù)據(jù)庫SPAN>角色"命令。
4.????????在"名稱"框中輸入新角色的名稱。
5.????????單擊"添加"將成員添加到"標準角色"列表中，然后單擊要添加的一個或多個用戶。（可選）?
只有選定數(shù)據(jù)庫SPAN>中的用戶才能被添加到角色中。

對象權(quán)限
處理數(shù)據(jù)或執(zhí)行過程時需要稱為對象權(quán)限的權(quán)限類別：?
·????????SELECT、INSERT、UPDATE?和?DELETE?語句權(quán)限，它們可以應用到整個表或視圖中。
·????????SELECT?和?UPDATE?語句權(quán)限，它們可以有選擇性地應用到表或視圖中的單個列上。
·????????SELECT?權(quán)限，它們可以應用到用戶定義函數(shù)。
·????????INSERT?和?DELETE?語句權(quán)限，它們會影響整行，因此只可以應用到表或視圖中，而不能應用到單個列上。
·????????EXECUTE?語句權(quán)限，它們可以影響存儲過程和函數(shù)。?

語句權(quán)限
創(chuàng)建數(shù)據(jù)庫SPAN>或數(shù)據(jù)庫SPAN>中的項（如表或存儲過程）所涉及的活動要求另一類稱為語句權(quán)限的權(quán)限。例如，如果用戶必須能夠在數(shù)據(jù)庫SPAN>中創(chuàng)建表，則應該向該用戶授予?CREATE?TABLE?語句權(quán)限。語句權(quán)限（如?CREATE?DATABASE）適用于語句自身，而不適用于數(shù)據(jù)庫SPAN>中定義的特定對象。
語句權(quán)限有：?
·????????BACKUP?DATABASE
·????????BACKUP?LOG
·????????CREATE?DATABASE
·????????CREATE?DEFAULT
·????????CREATE?FUNCTION
·????????CREATE?PROCEDURE
·????????CREATE?RULE
·????????CREATE?TABLE
·????????CREATE?VIEW?

暗示性權(quán)限
暗示性權(quán)限控制那些只能由預定義系統(tǒng)角色的成員或數(shù)據(jù)庫SPAN>對象所有者執(zhí)行的活動。例如，sysadmin?固定服務器SPAN>角色成員自動繼承在?SQL?Server?安裝中進行操作或查看的全部權(quán)限。?
數(shù)據(jù)庫SPAN>對象所有者還有暗示性權(quán)限，可以對所擁有的對象執(zhí)行一切活動。例如，擁有表的用戶可以查看、添加或刪除數(shù)據(jù)，更改表定義，或控制允許其他用戶對表進行操作的權(quán)限。

db_owner??????????????????????????在數(shù)據(jù)庫SPAN>中有全部權(quán)限。
db_accessadmin????????????????????????可以添加或刪除用戶?ID。
db_securityadmin????????????????可以管理全部權(quán)限、對象所有權(quán)、角色和角色成員資格。
db_ddladmin????????????????????????可以發(fā)出?ALL?DDL，但不能發(fā)出?GRANT、REVOKE?或?DENY?語句。
db_backupoperator????????????????可以發(fā)出?DBCC、CHECKPOINT?和?BACKUP?語句。
db_datareader????????????????????????可以選擇數(shù)據(jù)庫SPAN>內(nèi)任何用戶表中的所有數(shù)據(jù)。
db_datawriter????????????????????????可以更改數(shù)據(jù)庫SPAN>內(nèi)任何用戶表中的所有數(shù)據(jù)。
db_denydatareader????????????????不能選擇數(shù)據(jù)庫SPAN>內(nèi)任何用戶表中的任何數(shù)據(jù)。
db_denydatawriter????????????????不能更改數(shù)據(jù)庫SPAN>內(nèi)任何用戶表中的任何數(shù)據(jù)。

在這兒把新建的數(shù)據(jù)庫SPAN>角色的權(quán)限配置好，比如需要使用哪個表、視圖、存儲過程等。然后把Db_owner和db_securityadmin、db_backupoperator取消，不給攻擊者BACKUP?DATABASE和CREATE?TABLE的機會，一但攻擊者具有這兩個權(quán)限，那么你的網(wǎng)站就還處在十分危險的狀態(tài)。還有注意一下，在創(chuàng)建數(shù)據(jù)庫SPAN>賬號時，千萬不能對服務器SPAN>角色進行選擇。


第四步是修改SQL?SERVER內(nèi)置存儲過程。SQL?SERVER估計是為了安裝或者其它方面，它內(nèi)置了一批危險的存儲過程。能讀到注冊表SPAN>信息，能寫入注冊表SPAN>信息，能讀磁盤共享信息等等……各位看到這兒，心里可能會在想，我的網(wǎng)站中有其它的代碼，又不像查詢分析器那樣能查接將結(jié)果輸出。給你這個權(quán)限，又不能怎么樣，還是看不到信息。如果各位這樣想就大錯特錯了。提示一下，如果攻擊者有CREATE?TABLE的權(quán)限，那么創(chuàng)建一個臨時表，然后將信息INSERT到表中，然SELECT出來，接著跟數(shù)字進行比較，讓SQL?SERVER報錯，那么結(jié)果就全出來了……所以我們要報著寧錯殺，不放過的態(tài)度進行修補。

先來列出危險的內(nèi)置存儲過程：

xp_cmdshell
xp_regaddmultistring
xp_regdeletekey
xp_regdeletevalue
xp_regenumkeys
xp_regenumvalues
xp_regread
xp_regremovemultistring
xp_regwrite

ActiveX自動腳本：

sp_OACreate
sp_OADestroy
sp_OAMethod
sp_OAGetProperty
sp_OASetProperty
sp_OAGetErrorInfo
sp_OAStop

以上各項全在我們封殺之列，例如xp_cmdshell屏蔽的方法為：sp_dropextendedproc?'xp_cmdshell'，如果需要的話，再用sp_addextendedproc?'xp_cmdshell',?'xpsql70.dll'進行恢復。如果你不知道xp_cmdshell使用的是哪個.dll文件的話，可以使用sp_helpextendedproc?xp_cmdshell來查看xp_cmdshell使用的是哪個動態(tài)聯(lián)接庫。另外，將xp_cmdshell屏蔽后，我們還需要做的步驟是將xpsql70.dll文件進行改名，以防止獲得SA的攻擊者將它進行恢復。

我們做到這兒，你的SQL?SERVER就基本上安全了。但是信息還是能一樣的外泄。畢竟SELECT我們是無法取消的，除非你的網(wǎng)站用的是HTML。SQL?INJECTION的防范還需要我們這些程序員來注意，這才是治本之法。我們在高級設(shè)置篇再接著對SQL?SERVER的安全做下一步的分析。該篇文章如果有什么錯漏，請大家多多包涵。謝謝……

總結(jié)

以上是生活随笔為你收集整理的针对SQL INJECTION的SQL SERVER安全设置初级篇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。