分析概括ADO.NET連接信息安全
ADO.NET經過長時間的發展,很多用戶都很了解ADO.NET了,這里我發表一下個人理解,和大家討論討論ADO.NET連接信息。保護應用程序時,最重要的目標之一是保護對數據源的訪問。如果連接字符串未受保護,那么它就是一個潛在漏洞。如果以純文本形式存儲ADO.NET連接信息或者使連接信息持續位于內存中,則可能會損害整個系統。可以使用MSIL反匯編程序(Ildasm.exe)讀取嵌入在源代碼中的連接字符串,以查看已編譯的程序集中的Microsoft中間語言(MSIL)。
根據以下因素可能會出現與連接字符串有關的安全漏洞:所使用的身份驗證類型,連接字符串持久地位于內存和磁盤中的方式,以及在運行時構造連接字符串所采用的技術。
使用Windows身份驗證
#T#為了幫助限制對數據源的訪問,必須保護諸如用戶ID、密碼和數據源名稱等ADO.NET連接信息的安全。為避免公開用戶信息,建議盡可能使用Windows身份驗證(有時也稱為“集成安全性”)。使用IntegratedSecurity或Trusted_Connection關鍵字在連接字符串中指定Windows身份驗證后,不必再使用用戶ID和密碼。在使用Windows身份驗證時,用戶由Windows進行身份驗證,通過對Windows用戶和組授予權限來確定他們是否可訪問服務器和數據庫資源。
在不能使用Windows身份驗證的情況下必須格外小心,因為此時用戶憑據在連接字符串中是公開的。在ASP.NET應用程序中,您可以將Windows帳戶配置為用于連接到數據庫和其他網絡資源的固定標識。您可以在web.config文件中的標識元素中啟用模擬,并指定用戶名和密碼。
- <identityimpersonateidentityimpersonate="true"
- userName="MyDomain\UserAccount"
- password="*****"/>
固定標識帳戶應是低權限帳戶,僅被授予數據庫中的必要權限。此外,您還應該加密配置文件,從而使用戶名和密碼不會以明文形式公開。
不要使用通用數據鏈接(UDL)文件
不要在通用數據鏈接(UDL)文件中存儲OleDbConnection的連接字符串。UDL以明文形式存儲,無法加密。因為UDL文件對您的應用程序來說是一個基于文件的外部資源,所以無法使用.NETFramework保護或加密該文件。
利用連接字符串生成器避免注入攻擊
當動態字符串串聯根據用戶輸入的內容構建連接字符串時,會發生連接字符串注入攻擊。如果用戶輸入的內容未經驗證,并且惡意文本或字符串未被轉義,則攻擊者可能會訪問敏感數據或服務器上的其他資源。為解決此問題,ADO.NET2.0引入了新的連接字符串生成器類,以驗證連接字符串語法并確保不會引入附加參數。有關更多信息,請參見連接字符串生成器(ADO.NET)。
使用PersistSecurityInfo=False
PersistSecurityInfo的默認值為false;建議在所有連接字符串中使用此默認值。如果將PersistSecurityInfo設置為true或yes,則允許在打開連接后通過連接獲取安全敏感信息(包括用戶ID和密碼)。如果將PersistSecurityInfo設置為false或no,則在使用安全信息打開連接后會丟棄安全信息,這可確保不受信任的來源不能訪問安全敏感信息。
加密配置文件
您還可以在配置文件中存儲連接字符串,從而不必將它們嵌入到應用程序的代碼中。配置文件是標準XML文件,.NETFramework已為這些文件定義了一組常用的元素。配置文件中的連接字符串通常存儲在Windows應用程序的app.config的<connectionStrings>元素中,或存儲在ASP.NET應用程序的web.config文件中。有關在配置文件中存儲、檢索和加密連接字符串的基本知識的更多信息,請參見連接字符串和配置文件(ADO.NET)。