SQL SERVER安全設定攻略

日前SQL INJECTION的攻擊測試愈演愈烈，很多大型的網站和論壇都相繼被注入。這些網站一般使用的多為SQLSERVER資料庫，正因為如此，很

多人開始懷疑SQL SERVER的安全性。其實SQL SERVER2000已經通過了美國政府的C2級安全認證-這是該行業所能擁有的最高認證級別，所以使

用SQLSERVER還是相當的安全的。當然和ORCAL、DB2等還是有差距，但是SQL
SERVER的易用性和廣泛性還是能成為我們繼續使用下去的理由。那怎麼樣才能使SQL SERVER的設定讓人使用的放心呢？第一步肯定是打上

SQLSERVER最新的安全補丁，現在補丁已經出到了SP3。下載地址：http://www.microsoft.com/sql/downloads/2000/sp3.asp。如果這一步都

沒有做好，那我們也沒有繼續下去的必要了。第二步是修改預設的1433埠，並且將SQL SERVER隱藏。這樣能禁止對試圖列舉網路上現有的

SQL Server客戶端所發出的廣播作出響應。另外，還需要在TCP/IP篩選中將1433埠遮蔽掉，儘可能的隱藏你的SQLSERVER資料庫。這樣子一

但讓攻擊建立了SQLSERVER的賬號，也不能馬上使用查詢分析器遠端登陸來進行下一步的攻擊。單從ASP，PHP等頁面構造惡意語句的話，還有

需要檢視返回值的問題，總比不上直接查詢分析器來得利落。所以我們首先要做到即使讓別人注入了，也不能讓攻擊者下一步做得順當。修改

方法：企業管理器--&gt 你的資料庫組 --&gt 屬性 --&gt 常規 --&gt 網路配置 --&gt TCP/IP --&gt 屬性，在這兒將你的預設埠進行修改，和SQL

SERVER的隱藏。第三步是很重要的一步，SQL INJECTION往往在WEBCODE中產生。而做為系統管理員或者資料庫管理員，總不能常常的去看每一

段程式碼。即使常常看程式碼，也不能保證我們在上面的疏忽。那怎麼辦？我們就要從資料庫角色著手，讓資料庫使用者的許可權劃分到最低點。

SQLSERVER的預設許可權讓人真的很頭疼，許可權大得非常的高，許可權小的又什麼都做不了，SYSADMIN和db_owner真是讓人又愛又恨。攻擊者一但

確認了網站存在SQLINJECTION漏洞，肯定有一步操作步驟就是測試網站的SQL SERVER使用者具有多大的許可權。一般都會藉助

selectIS_SRVROLEMEMBER(’sysadmin’)，或者select IS_MEMBER(’db_owner’)，再或者用user= 0(讓字元和數字進行比較，SQLSERVER就

會提示了錯誤資訊，從該資訊中即可知道一些敏感資訊)等語句進行測試。方法還有，我也不敢多說了。其一怕錯，其二怕聯盟中的人扁。在

當前，如果網站的資料庫使用者用的是SA許可權，再加上確認了WEB所處在的絕對路徑，那麼就宣告了你的網站的OVER。db_owner許可權也一樣，

如果確認了絕對路徑，那麼有50％的機會能給你的機器中上WEB方式的木馬，如海陽等。所以這兒我們確認了一點，我們必須要建立自已的權

限，讓攻擊者找不著下嘴的地方。在這兒引用一個SQLSERVER聯機幫助中的例子：建立 SQL Server 資料庫角色的方法（企業管理器）
建立 SQL Server 資料庫角色
1. 展開伺服器組，然後展開伺服器。
2. 展開"資料庫"資料夾，然後展開要在其中建立角色的資料庫。
3. 右擊"角色"，然後單擊"新建資料庫角色"命令。
4. 在"名稱"框中輸入新角色的名稱。
5. 單擊"新增"將成員新增到"標準角色"列表中，然後單擊要新增的一個或多個使用者。（可選）只有選定資料庫中的使用者才能被新增到角色中

。物件許可權處理資料或執行過程時需要稱為物件許可權的許可權類別：
· select、insert、update 和 delete 語句許可權，它們可以應用到整個表或檢視中。
· select 和 update 語句許可權，它們可以有選擇性地應用到表或檢視中的單個列上。
· select 許可權，它們可以應用到使用者定義函式。
· insert 和 delete 語句許可權，它們會影響整行，因此只可以應用到表或檢視中，而不能應用到單個列上。
· EXECUTE 語句許可權，它們可以影響儲存過程和函式。語句許可權
建立資料庫或資料庫中的項（如表或儲存過程）所涉及的活動要求另一類稱為語句許可權的許可權。例如，如果使用者必須能夠在資料庫中建立表，

則應該向該使用者授予create TABLE 語句許可權。語句許可權（如 create DATABASE）適用於語句自身，而不適用於資料庫中定義的特定物件。
語句許可權有：
· BACKUP DATABASE
· BACKUP LOG
· create DATABASE
· create DEFAULT
· create FUNCTION
· create PROCEDURE
· create RULE
· create TABLE
· create VIEW暗示性許可權
暗示性許可權控制那些只能由預定義系統角色的成員或資料庫物件所有者執行的活動。例如，sysadmin 固定伺服器角色成員自動繼承在

SQLServer 安裝中進行操作或檢視的全部許可權。
資料庫物件所有者還有暗示性許可權，可以對所擁有的物件執行一切活動。例如，擁有表的使用者可以檢視、新增或刪除資料，更改表定義，或控

制允許其他使用者對錶進行操作的許可權。db_owner 在資料庫中有全部許可權。
db_accessadmin 可以新增或刪除使用者 ID。
db_securityadmin 可以管理全部許可權、物件所有權、角色和角色成員資格。
db_ddladmin 可以發出 ALL DDL，但不能發出 GRANT、REVOKE 或 DENY 語句。
db_backupoperator 可以發出 DBCC、CHECKPOINT 和 BACKUP 語句。
db_datareader 可以選擇資料庫內任何使用者表中的所有資料。
db_datawriter 可以更改資料庫內任何使用者表中的所有資料。
db_denydatareader 不能選擇資料庫內任何使用者表中的任何資料。
db_denydatawriter 不能更改資料庫內任何使用者表中的任何資料。在這兒把新建的資料庫角色的許可權配置好，比如需要使用哪個表、檢視、存

儲過程等。然後把Db_owner和db_securityadmin、db_backupoperator取消，不給攻擊者BACKUPDATABASE和createTABLE的機會，一但攻擊者具

有這兩個許可權，那麼你的網站就還處在十分危險的狀態。還有注意一下，在建立資料庫賬號時，千萬不能對伺服器角色進行選擇。
第四步是修改SQL SERVER內建儲存過程。SQLSERVER估計是為了安裝或者其它方面，它內建了一批危險的儲存過程。能讀到登錄檔資訊，能寫

入登錄檔資訊，能讀磁碟共享資訊等等……各位看到這兒，心裡可能會在想，我的網站中有其它的程式碼，又不像查詢分析器那樣能查接將結果

輸出。給你這個許可權，又不能怎麼樣，還是看不到資訊。如果各位這樣想就大錯特錯了。提示一下，如果攻擊者有createTABLE的許可權，那麼

建立一個臨時表，然後將資訊insert到表中，然select出來，接著跟數字進行比較，讓SQLSERVER報錯，那麼結果就全出來了……所以我們要

報著寧錯殺，不放過的態度進行修補。先來列出危險的內建儲存過程：
xp_cmdshell
xp_regaddmultistring
xp_regdeletekey
xp_regdeletevalue
xp_regenumkeys
xp_regenumvalues
xp_regread
xp_regremovemultistring
xp_regwriteActiveX自動指令碼：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使用的是哪個動態聯接庫。另外，將xp_cmdshell遮蔽後，我們還需要做的步驟是將xpsql70.dll檔案進行改名

，以防止獲得SA的攻擊者將它進行恢復。我們做到這兒，你的SQLSERVER就基本上安全了。但是資訊還是能一樣的外洩。畢竟select我們是無

法取消的，除非你的網站用的是HTML。SQLINJECTION的防範還需要我們這些程式設計師來注意，這才是治本之法。我們在高階設定篇再接著對

SQLSERVER的安全做下一步的分析。該篇文章如果有什麼錯漏，請大家多多包涵。謝謝……另外推薦一下，SQL INJECTION的測試工具NBSI2，

這是由聯盟中小竹同志開發，對SQLINJECTION的注入有代表性的作用，另外一個就是小弟的NBWEBSHELL了。這些工具都可以到聯盟網站進行下

載NB聯盟-jadesun(褲衩) QQ:280155
NB網站：54nb.com
SQL隱碼攻擊防禦方法-程式設計師篇作者：NB聯盟－小竹　　SQL隱碼攻擊越來越多的被利用來入侵網站，部分WEB程式設計師也開始關注這方面的知識，但由於

對入侵的方法一知半解，導致在過濾的時候漏掉某些字元，造成安全漏洞；或者是草木皆兵，把一些合法的使用者請求都拒之門外，試想一下，

當使用者想輸入個I’m a boy的時候，卻給你臭罵一頓，他還會願意再上你的網站嗎？下面，我從程式方面介紹一下SQL隱碼攻擊的防禦方法，首先

看這三句最簡單SQL語句
1.SQL="select * from Users where UserID=" & Request("ID")
2.SQL="select * from Users where UserID=’" & Request("ID") & "’"
3.SQL="select * from Users where UserName like ’%" & Request("Name")
& "%’"第一句，引數是數字型，這個很明顯。第二句，如果欄位UserID是int型，就有些人分不清楚了。其實，區分第數字弄和字元型引數，

只要看SQL語句引數兩邊有沒有單引號即可，很明顯，第一句沒單引號，是數字型；第二第三句有單引號，是字元型。
　　對於數字型變數，傳入的引數都會直接附加到SQL語句上執行，而因為引數是數字型，所以用isNumeric判斷是很安全的，我曾經試過用之

類試圖斷開引數，但結果都是失敗。
　　對於字元型變數，傳入的引數都是做為常量，比如你傳1 and 1=1進去，SQL語句就是UserID=? and
1=1’，在單引號界定範圍裡面的值永遠都只是一個常量，要打破這個範圍，唯一的字元就是界定的字元：單引號。所以，字元型變數只要過

濾了’號就完全安全了，至於如何過濾，最好是把一個單引號替換成兩個單引號，因為SQL語句裡面規定，’常量’這樣表示的常量裡面，常

量裡面如果要有單引號，可以用兩個單引號代替。這樣，既可以保持使用者輸入的原貌，又可以保證程式的安全。
　　下面是兩個函式，大家可以Copy過去直接呼叫就行了。’---------------------------------------------------------------
’ NB聯盟防注入函式 ReqNum / ReqStr
’---------------------------------------------------------------
Function ReqNum ( StrName )
ReqNum = Request ( StrName )
if Not isNumeric ( ReqNum ) then
Response.Write "引數必須為數字型!"
Response.End
End if
End FunctionFunction ReqStr ( StrName )
ReqStr = Replace ( Request(StrName), "’", "’’" )
End Function
以上面三句SQL語句，說明一下呼叫方法：
1.SQL="select * from Users where UserID=" & ReqNum("ID")
2.SQL="select * from Users where UserID=’" & ReqStr("ID") & "’"
3.SQL="select * from Users where UserName like ’%" & ReqStr("Name")
& "%’"　　重申一點：上面的方法無論對SQLServer庫還是Access或是其它資料庫，都是絕對適用、絕對安全，但注意一點，SQLServer的存

儲過程是個例外，該情況下要把單引號替換成四個單引號，以保安全。

如果是利用.NET的語言的話，我覺得一個簡單的辦法就是在Sql語句中使用引數，利用SqlCommand的引數集合設定Sql語句的引數值。而且除非

邏輯非常簡單，否則最好封裝到儲存過程中

 

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/huwei2003/archive/2009/04/07/4053840.aspx

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-625024/，如需轉載，請註明出處，否則將追究法律責任。