前 SQL INJECTION 攻擊測試愈演愈烈， 很多大型的網站和論壇都相繼被注入。 這些網站一般使用的多為 SQL SERVER 數據庫， 正因為如此， 很多人開始懷疑 SQL SERVER 平安性。 其實 SQL SERVER 2000 已經通過了美國政府的 C2 級安全認證 - 這是該行業所能擁有的最高認證級別， 所以使用 SQL SERVER 還是相當的平安的當然和 ORCAL DB2 等還是有差距， 但是 SQL SERVER 易用性和廣泛性還是能成為我繼續使用下去的理由。 那怎么樣才干使 SQL SERVER 設置讓人使用的放心呢？

第一步肯定是打上 SQL SERVER 最新的平安補丁 . 如果這一步都沒有做好， 那我也沒有繼續下去的必要了

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

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

創立 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_backupoper 取消， 不給攻擊者 BACKUP DATABASE 和 CREATE TABLE 機會， 一但攻擊者具有這兩個權限， 那么你網站就還處在十分危險的狀態。 還有注意一下， 創建數據庫賬號時， 千萬不能對服務器角色進行選擇。

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

先來列出危險的內置存儲過程：

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

將有安全問題的 SQL 過程刪除 . 比較全面 . 一切為了平安 !

刪除有安全隱患的擴展 :

    exec sp_dropextendedproc 'xp_cmdshell'   [ 刪除此項擴展后 , 將無法遠程連接數據庫 ]

    exec sp_dropextendedproc 'xp_dirtree'    [ 刪除此項擴展后 , 將無法新建或附加數據庫 ]

    exec sp_dropextendedproc 'xp_enumgroups'

    exec sp_dropextendedproc 'xp_fixeddrives'

    exec sp_dropextendedproc 'xp_loginconfig'

    exec sp_dropextendedproc 'xp_regaddmultistring'

    exec sp_dropextendedproc 'xp_regdeletekey'

    exec sp_dropextendedproc 'xp_regdeletevalue'

    exec sp_dropextendedproc 'xp_regread'

    exec sp_dropextendedproc 'xp_regremovemultistring'

    exec sp_dropextendedproc 'xp_regwrite'

    exec sp_dropextendedproc 'xp_enumerrorlogs'

    exec sp_dropextendedproc 'xp_getfiledetails'

    exec sp_dropextendedproc 'xp_regenumvalues'

    恢復擴展

    exec sp_addextendedproc 'xp_cmdshell', 'xplog70.dll'

    exec sp_addextendedproc 'xp_dirtree', 'xpstar.dll'

    exec sp_addextendedproc 'xp_enumgroups', 'xplog70.dll'

    exec sp_addextendedproc 'xp_fixeddrives', 'xpstar.dll'

    exec sp_addextendedproc 'xp_loginconfig', 'xplog70.dll'

    exec sp_addextendedproc 'xp_regaddmultistring', 'xpstar.dll'

    exec sp_addextendedproc 'xp_regdeletekey', 'xpstar.dll'

    exec sp_addextendedproc 'xp_regdeletevalue', 'xpstar.dll'

    exec sp_addextendedproc 'xp_regread', 'xpstar.dll'

    exec sp_addextendedproc 'xp_regremovemultistring', 'xpstar.dll'

    exec sp_addextendedproc 'xp_regwrite', 'xpstar.dll'

    exec sp_addextendedproc 'xp_enumerrorlogs', 'xpstar.dll'

    exec sp_addextendedproc 'xp_getfiledetails', 'xpstar.dll'

    exec sp_addextendedproc 'xp_regenumvalues', 'xpstar.dll'

全部復制到 "SQL 查詢分析器 "

點擊菜單上的 --" 查詢 "--" 執行 " 就會將有安全問題的 SQL 過程刪除 ( 以上是 7i24 正版用戶的技術支持 )

更改默認 SA 空密碼 . 數據庫鏈接不要使用 SA 帳戶 . 單數據庫單獨設使用帳戶 . 只給 public 和 db_owner 權限 .

數據庫不要放在默認的位置 .

SQL 不要裝置在 PROGRAM FILE 目錄下面 .

以 上各項全在封殺之列， 例如 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 攻擊者將它進行恢復。

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