日前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等頁面構造惡意語句的話，還有需要查看返回值的問題，總比不上直接查詢分析器來得利落。所以我們首先要做到即使讓別人注入了，也不能讓攻擊者下一步做得順當。修改方法：企業管理器
-->?你的數據庫組?-->?屬性?-->?常規?-->?網絡配置?-->?TCP/IP?-->?屬性
，在這兒將你的默認端口進行修改，和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?固定服務器角色成員自動繼承在?SQL
Server?安裝中進行操作或查看的全部權限。
數據庫對象所有者還有暗示性權限，可以對所擁有的對象執行一切活動。例如，擁有表的用戶可以查看、添加或刪除數據，更改表定義，或控制允許其他用戶對表進行操作的權限。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取消，不給攻擊者BACKUP
DATABASE和create
TABLE的機會，一但攻擊者具有這兩個權限，那么你的網站就還處在十分危險的狀態。還有注意一下，在創建數據庫賬號時，千萬不能對服務器角色進行選擇。
第四步是修改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的存儲過程是個例外，該情況下要把單引號替換成四個單引號，以保安全。
?

總結

以上是生活随笔為你收集整理的SQLserver安全设置攻略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。