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)。
