SQL INJECTION的SQL SERVER安全設定
來源:互聯網
上載者:User
server|安全
日前SQL INJECTION的攻擊測試愈演愈烈,很多大型的網站和論壇都相繼被注入。這些網站一般使用的多為SQL SERVER資料庫,正因為如此,很多人開始懷疑SQL SERVER的安全性。其實SQL SERVER 2000已經通過了美國政府的C2級安全認證-這是該行業所能擁有的最高認證層級,所以使用SQL SERVER還是相當的安全的。當然和ORCALE、DB2等還是有差距,但是SQL
SERVER的易用性和廣泛性還是能成為我們繼續使用下去的理由。那怎麼樣才能使SQL SERVER的設定讓人使用的放心呢?
1.1. 第一步
打上SQLSERVER最新的安全補丁,現在補丁已經出到了SP3。下載地址:http://www.microsoft.com/sql/downloads/2000/sp3.asp。如果這一步都沒有做好,那我們也沒有繼續下去的必要了。
1.2. 第二步
修改預設的1433連接埠,並且將SQL SERVER隱藏。這樣能禁止對試圖枚舉網路上現有的SQL Server用戶端所發出的廣播做出響應。另外,還需要在TCP/IP篩選中將1433連接埠屏蔽掉,儘可能的隱藏你的SQL SERVER資料庫。這樣既便讓攻擊建立了SQL SERVER的帳號,也不能馬上使用查詢分析器遠程登陸來進行下一步的攻擊。單從ASP,PHP等頁面構造惡意語句的話,還有需要查看傳回值的問題,總比不上直接查詢分析器來得利落。所以我們首先要做到即使讓別人注入了,也不能讓攻擊者下一步做得順當。修改方法:
企業管理器--> 你的資料庫組 --> 屬性 --> 常規 --> 網路設定 --> TCP/IP --> 屬性,在這兒將你的預設連接埠進行修改,和SQL SERVER的隱藏。
1.3. 第三步
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 可以添加或刪除使用者識別碼。
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的機會,一但攻擊者具有這兩個許可權,那麼你的網站就還處在十分危險的狀態。還有注意一下,在建立資料庫帳號時,千萬不能對伺服器角色進行選擇。
1.4. 第四步
修改SQL SERVER內建預存程序。
SQLSERVER估計是為了安裝或者其它方面,它內建了一批危險的預存程序。能讀到註冊表資訊,能寫入註冊表資訊,能讀磁碟共用資訊等等……各位看到這兒,心裡可能會在想,我的網站中有其它的代碼,又不像查詢分析器那樣能直接將結果輸出。給你這個許可權,也不能怎麼樣,還是看不到資訊。如果各位這樣想就大錯特錯了。提示一下,如果攻擊者有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
以上各項全在我們封殺之列,例如xp_cmdshell屏蔽的方法為:
sp_dropextendedproc 'xp_cmdshell'
如果需要的話,再用
sp_addextendedproc 'xp_cmdshell', 'xpsql70.dll'
進行恢複。如果你不知道xp_cmdshell使用的是哪個.dll檔案的話,可以使用
sp_helpextendedproc xp_cmdshel
來查看xp_cmdshell使用的是哪個動態聯結庫。另外,將xp_cmdshell屏蔽後,我們還需要做的步驟是將xpsql70.dll檔案進行改名,以防止獲得SA的攻擊者將它進行恢複。
1.5. 結語
我們做到這兒,你的SQL SERVER就基本上安全了。但是資訊還是能一樣的外泄。畢竟SELECT我們是無法取消的,除非你的網站用的是HTML。SQL INJECTION的防範還需要我們這些程式員來注意,這才是治本之法。我們在進階設定篇再接著對SQL SERVER的安全做下一步的分析。該篇文章如果有什麼錯漏,請大家多多包涵。謝謝……
另外推薦一下,SQL INJECTION的測試載入器NBSI,這是由NB聯盟中小竹同志開發,對SQL
INJECTION的注入有代表性的作用,另外一個就是小弟的NBWEBSHELL了。這些工具都可以到NB聯盟網站進行下載。