SQL Server上內(nèi)置了加密術用來保護各種類型的敏感數(shù)據(jù)。在很多時候，這個加密術對于你來說是完全透明的;當數(shù)據(jù)被存儲時候被加密，它們被使用的時候就會自動加密。在其他的情況下，你可以選擇數(shù)據(jù)是否要被加密。SQL Server可以加密下列這些組件:

·密碼 ·存儲過程，視圖，觸發(fā)器，用戶自定義函數(shù)，默認值，和規(guī)則。 ·在服務器和用戶之間傳輸?shù)臄?shù)據(jù) 密碼加密術 SQL Server自動將你分配給登陸和應用角色的密碼加密。盡管當你可以從主數(shù)據(jù)庫中直接察看系統(tǒng)表格而不需要密碼。你不能給對這種情況作出任何修改，事實上，你根本不能破壞它。 定義加密術 在有些時候，如果對對象進行加密是防止將一些信息分享給他人。例如，一個存儲進程可能包含所有者的商業(yè)信息，但是這個信息不能和讓其他的人看到，即使他們公開的系統(tǒng)表格并可以看到對象的定義。這就是為什么SQL Server允許你在創(chuàng)建一個對象的時候進行加密。為了加密一個存儲進程，使用下面形式的CREAT PROCEDURE 語句: create PROCEDURE procedurename [;number]
[@parameter datatype
[VARYING][ = defaultvalue][OUTPUT]]
[, …]
[WITH RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION] 我們關心的僅僅是可選的WITH參數(shù)。你可以詳細說明ARECOMPILE或者ENCRYPTION，或者你可以同時說明它們。ENCRYPTION關鍵字保護SQL Server它不被公開在進程中。結(jié)果，如果ENCRYPTION在激活的時候系統(tǒng)存儲進程sp_helptext就會被忽視,這個存儲進程將被存儲在用戶創(chuàng)建進程的文本中。如果你不想要加密，你可以使用alter PROCEDURE，忽略WITH ENCRYPTION子句來重新創(chuàng)建一個進程。 為了能夠使用加密術。用戶和服務器都應該使用TCP/IP NetworkLibraries用來連接。運行適當?shù)腘etwork Utility和檢查Force protocol encryption，看下表，用戶和服務器之間的連接將不會被加密。 加密也不能完全自由。當連接確定后，要繼續(xù)其他的構造，并且用戶和服務器必須運行代碼來解釋加密和解釋的包裹。這里將需要一些開銷并且當在編譯碼的時候會使進程慢下來。如果網(wǎng)絡包裹在你控制范圍之外，使用這種做法是非常好的。 加密術中缺少什么? 你可以注意到在這個列表中缺少一些被加密的東西:你表格中的數(shù)據(jù)。在你存儲數(shù)據(jù)之前，SQL Server不會提供任何內(nèi)置的工具來加密你的數(shù)據(jù)。如果你需要保護存儲在SQL Server上的數(shù)據(jù)，我們給你兩條建議:第一，你可以利用GRANT 和DENY關鍵字來控制你想哪個用戶可以在SQL Server中讀取的數(shù)據(jù)。 第二.如果你真的想對數(shù)據(jù)加密，不要設法加密碼。你可以利用被測試過的商業(yè)產(chǎn)品的算法。 SQL 注入攻擊 SQL 注入攻擊是一個常規(guī)性的攻擊，它可以允許一些不法用戶檢索你的數(shù)據(jù)，改變服務器的設置，或者在你不小心的時候黑掉你的服務器。SQL 注入攻擊不是SQL Server問題，而是不適當?shù)某绦?。如果你想要運行這些程序的話，你必須明白這冒著一定的風險。 測點定位弱點 SQL 注入的脆弱點發(fā)生在程序開發(fā)員構造一個where 子句伴隨著用戶的輸入的時候。比如，一個簡單的ASP程序允許用戶輸入一個顧客的ID然后檢索公司的全部人員的名字，如果顧客ID如果作為ASP頁面的請求串的一部分返回，那么開發(fā)員可以編寫下面的代碼獲得數(shù)據(jù): strConn = "Provider=SQLOLEDB;Data Source=(local);" & _
"Database=Northwind;Integrated Security=SSPI"
Set cnn = Server.createObject("ADODB.Connection")
cnn.Open strConn
strQuery = "select ContactName FROM Customers " & _
"where CustomerID = '" & Request.Form("CustID") & "'"
Set rstResults = cnn.Execute(strQuery)
Response.Write(rstResults.Fields("ContactName").Value) 現(xiàn)在你知道什么地方有問題了吧?如果用戶知道一個用戶的ID，他可以通過檢索來獲得全部的相應的名字。現(xiàn)在明白了?
獲得額外的數(shù)據(jù) 當然，對于一個攻擊程序，盡管它不知道任何顧客的ID，甚至不用去猜，它也可以獲得數(shù)據(jù)。為了完成這個工作，它將下面的文本輸入到應用程序調(diào)用顧客ID的textbox中: customer ID:
'union ALL select ContactName FROM Customers
where CustomerID <>' 如果你輸入了這個代碼，你將會看到返回一個詢問語句: select ContactName FROM Customers
where CustomerID = ''
union ALL select ContactName FROM Customers
where CustomerID <>'' 通過獲得空和非空顧客的ID并集，這個查詢語句會返回數(shù)據(jù)庫中所有的相關姓名。事實上，這個union技術可以被用來獲得你數(shù)據(jù)庫中大多數(shù)信息，看看這個CustomerID的值: 'union ALL select FirstName ' ' LastName FROM
Employees where LastName <>' 它將SQL語句變成: select ContactName FROM Customers
where CustomerID = ''
union ALL select FirstName ' ' LastName FROM
Employees where LastName <>'' 看，那就是攻擊程序從你的數(shù)據(jù)庫獲得的第一個雇員的名字。 更多的攻擊程序 如果SQL注入僅僅只有數(shù)據(jù)暴光這個弱點就已經(jīng)夠糟糕的了，但是，實際上一個良好的攻擊程序可以通過這個弱點獲取你數(shù)據(jù)庫中所有的資料?？聪旅孢@個例子: ';drop TABLE Customers;-- SQL語句變成: select ContactName FROM Customers
where CustomerID = ''
; drop TABLE Customers;-- ' 這個分號使語句和SQL Server隔離，所以，這里實際上是兩個語句。第一個語句不存在的名字，第二個則撤消的整個Customers表。兩個—SQL Server注釋符，它可以使子句不發(fā)生語法錯誤。 使用這個技術的變異，一個攻擊程序可以在任何SQL語句或者存儲過程上運行。通過使用xp_cmdshell擴展存儲過程，一個攻擊程序同樣可以在操作系統(tǒng)命令下運行，顯然，這是一個嚴重的漏洞。 保護自己的數(shù)據(jù)庫 現(xiàn)在，你知道如何防范SQL注入攻擊了嗎?首先，你不能在用戶輸入中構造where子句，你應該利用參數(shù)來使用存儲進程。在最初的ASP頁面下，重新寫的部分將和剛才我們在表中所看到的東西相似。即使你認為在你的應用程序中沒有脆弱點，你應該遵守最小特權原則。使用我們建議的其他安全技術允許你的用戶僅僅訪問他們能夠訪問的。在你沒有發(fā)現(xiàn)你數(shù)據(jù)庫脆弱點的時候，只有這樣，不會使你的數(shù)據(jù)庫崩潰。 最后的建議

這就是全部的SQL Server安全系列。也許你現(xiàn)在不是一個全面的專家，但是你已經(jīng)了解了很多反面。下一步就是你要保護你SQL Server數(shù)據(jù)，記住你在這里所學到的知識，并利用到你的數(shù)據(jù)庫中保證你的數(shù)據(jù)不被那些黑客攻擊。

最新評論