程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> SQLINJECTION的SQLServer安全設置

SQLINJECTION的SQLServer安全設置

編輯:關於SqlServer
日前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         可以添加或刪除用戶 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的機會,一但攻擊者具有這兩個權限,那麼你的網站就還處在十分危險的狀態。還有注意一下,在創建數據庫賬號時,千萬不能對服務器角色進行選擇。
  
  1.4.第四步
  修改SQL Server內置存儲過程。
  
  SQLSERVER估計是為了安裝或者其它方面,它內置了一批危險的存儲過程。能讀到注冊表信息,能寫入注冊表信息,能讀磁盤共享信息等等……各位看到這兒,心裡可能會在想,我的網站中有其它的代碼,又不像查詢分析器那樣能直接將結果輸出。給你這個權限,也不能怎麼樣,還是看不到信息。如果各位這樣想就大錯特錯了。提示一下,如果攻擊者有CREATE TABLE的權限,那麼創建一個臨時表,然後將信息INSERT到表中,然SELECT出來,接著跟數字進行比較,讓SQL Server


您正在看的SQLserver教程是:SQLINJECTION的SQLServer安全設置。報錯,那麼結果就全出來了……所以我們要報著寧錯殺,不放過的態度進行修補。
  
  先來列出危險的內置存儲過程:
  
  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. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved