分析概括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文件中的标识元素中启用模拟，并指定用户名和密码。

 
 

  
  

  
  
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的元素中，或存储在ASP.NET应用程序的web.config文件中。有关在配置文件中存储、检索和加密连接字符串的基本知识的更多信息，请参见连接字符串和配置文件(ADO.NET)。

网站栏目：分析概括ADO.NET连接信息安全
文章起源：http://www.shufengxianlan.com/qtweb/news21/453121.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联