設計安全的Visual Studio.NET互聯網服務

2019-11-17 04:58:58

字體：大中小

來源：轉載

供稿：網友

　　使用Visual Studio.NET開發的Web服務一般采用C#、VB.NET等可治理性編程語言編寫，這些語言具有較強的安全性。可治理代碼有助于減少緩沖溢出等安全缺陷，通過其提供的代碼訪問權限功能，編程人員能夠限制代碼的權限，防止黑客將應用程序代碼作為惡意代碼使用。

　　在經過對Web服務的安全性進行評估后，我發現VS.NET Web服務的設計人員輕易犯二個致命的錯誤，這二個錯誤都與Web服務和SQL Server、Oracle等數據庫服務器之間的連接有關。令人討厭的是，這些錯誤在java、asp、C++、和Visual Basic應用程序中都會出現。但好在它們很輕易被修復，這也是我將在本篇文章中要討論的問題。

　　錯誤1：使用系統治理員帳戶連接數據庫服務器

　　幾乎我見過的所有Web服務的SQL軟件中都含有以系統治理員身份與數據庫連接的代碼，這是一個很常見的錯誤，仔細地考慮一下，我們曾多少次地見過下面的代碼：

strConnection = "data source=DBServer;uid=sa;pwd="
　　連接到數據庫服務器上的用戶的身份是sa（SQL Server的系統治理員帳戶），密碼是空的。不使用密碼輕易造成的惡果廣大讀者也一定明白，但現在我關注的是sa帳戶的問題。

　　最少權限是一條重要的安全準則，它要求我們使用的帳戶只具有我們完成任務所必需的權限。因此，假如我們的應用程序只查詢幾個表，并更新另一個表，完成這樣的任務需要使用sa帳戶？當然，sa能夠對表完成查詢和更新操作，但它同樣能夠完成一些我們并不希望它執行的任務，它能夠刪除任何表、調用任意的存儲過程、調整每個表中的數據、定義新的數據庫等。因此，我們絕不能使用sa帳戶來完成簡單的查詢和更新操作。它的功能太強大了，能夠對數據庫執行任意的操作，應用程序中的一個小缺陷就可能使用戶受到黑客的攻擊。

　　在與數據庫進行連接時一定要符合最少權限準則。盡管這樣會需要較長的時間，但黑客要攻擊系統則需要更長的時間。。此外，不要在應用程序中存儲連接字符串，應當從外部資源中獲取連接字符串，這樣，不但能夠提高系統的安全性還提高了系統的可維護性。更多的請看：http://www.QQread.com/windows/2003/index.Html
　　錯誤2：手工編寫SQL語句

　　初看下面的代碼，它似乎不會有什么問題：

strSQL = "select sum(cost) from sales where id='" + id + "'";
　　你的軟件中有這樣的代碼嗎？一項調查顯示，80%的編程人員在軟件中編寫過類似的代碼。這類代碼的問題是它提供了用戶使用的id變量，使得黑客可能將id變量設置為其他的SQL語句。
例如，黑客可以將id變量設置為下面的值：

　　1' drop table sales --

　　上面的代碼將變為下面的形式：

select sum(cost)
from sales
where id='1' drop table sales -- '
　　這一代碼將執行一個查詢，查找id = 1的任意行，該行可能存在也可能不存在，而后，銷售數據庫表會被卸載，甚至被刪除。

　　解決辦法

　　下面用C#編寫的代碼說明了如何利用廣泛的抵御攻擊的能力（在第一種防御措施失效后，還能提供多種防御措施）減少系統被攻擊的危險：

[WebMethod]
public decimal GetSalesFigures(string CustomerID) {

SqlCommand cmd = null;
decimal sum = 0.0;

try {
// 檢查CustomerID是否有效，CustomerID必須是二位字符再加6位數字，而且對大小寫敏感
Regex reg = new Regex(@"^[a-z]{2}/d{6}$","i");
if (!reg.Match(CustomerID).SUCcess)
throw new SoapException("Invalid Sales ID",
SoapException.ClientFaultCode);

// 從外部位置獲取連接字符串
SqlConnection sqlConn= new SqlConnection(ConnectionString);

// 向存儲過程中添加銷售ID
string str="spGetSalesFigures";
cmd = new SqlCommand(str,sqlConn);
cmd.CommandType = CommandType.StoredPRocedure;
cmd.Parameters.Add("@ID",CustomerID);

cmd.Connection.Open();

sum = (decimal)cmd.ExecuteScalar();

} catch (Exception e) {
throw new SoapException(e.Message,
SoapException.ClientFaultCode);
} finally {
// 失敗后關閉連接
if (cmd != null)
cmd.Connection.Close();
}

return sum;
}

// 從外部xml配置文件獲取連接字符串
static internal string ConnectionString {
get {
XmlTextReader reader = null;
string connstring = "";
try {
reader = new XmlTextReader (@"c:/config/config.Xml");

while (reader.Read()) {
if (reader.NodeType == XmlNodeType.Element &&
reader.Name == "connectstring") {
connstring =
reader.GetAttribute("value");
}
}
} finally {
if (reader != null)
reader.Close();
}

return connstring;
}
}
　　下面我們來仔細分析上面代碼中的安全策略。
首先，也是最重要的，上面的代碼使用了規則表達式來驗證CustomerID，看它是否是由2個字符加6位數字組成的，假如不是，則CustomerID是無效的。
其次，上面的代碼從一個外部XML文件獲取連接字符串，所使用的代碼如下：

　　每個連接都是通過一個單一的身份生成的，而且都有密碼。不僅如此，在SQL Server中，我將該帳戶配置成只能訪問它需要使用的數據表和存儲過程。另外，該帳戶的訪問權限是只讀和可執行，它能夠完成的操作受到較大的限制。還需要提到的一點是，外部的XML文件存儲在Web文件空間之外，這是為了防止萬一黑客能夠讀取目錄中的文件或能夠訪問應用程序的二進制目錄。

　　第三，應用程序沒有使用手工的方式編寫SQL字符串，它調用了一個存儲過程，并使用參數化查詢方式設置過程的參數。這樣做有二個好處：它能夠阻止SQL入侵攻擊，由于其邏輯是保存在一個過程中的，黑客無法通過讀取查詢字符串輕易地確定數據庫對象的名字。

　　第四，一定要及時地關閉數據庫連接。在上面的代碼中，關閉帳戶與SQL Server之間連接的代碼被放在了finally程序塊中。無論是否有異常發生，finally程序塊中的代碼總是能夠被執行到，因此，帳戶與SQL Server之間連接就一定能夠被關閉。由于到SQL Server之間連接的數量是有一定限制的，因此應該十分小心地控制連接的使用。否則，黑客就能夠通過創建大量的連接而發動DOS攻擊，從而使有效客戶不能獲得連接。將關閉連接的代碼放在finally程序塊中就意味著連接總是能夠被及時地關閉。

上一篇：問與答:組件供應商談論.NET的挑戰

下一篇：軟件項目管理中的風險管理研究