我们在一个项目中首要考虑的就安全的问题，这里就我在项目中总结的一点ADO.NET安全数据访问方面的知识做一个详细的介绍。编写安全的 ADO.NET 代码，必须了解基础数据存储（即数据库）中提供的安全机制。您还需要考虑应用程序可能包含的其他功能或组件对安全性的影响。
1.身份验证、授权和权限
连接到 Microsoft SQL Server 后，您便可以使用 Windows 身份验证（也称为集成安全），它使用当前活动 Windows 用户的标识，而不是传递用户 ID 和密码。由于不会在连接字符串中公开用户凭据，因此强烈建议使用 Windows 身份验证。如果无法使用 Windows 身份验证连接到 SQL Server，请考虑使用 SqlConnectionStringBuilder 在运行时创建连接字符串。
#T#用于身份验证的凭据需要根据应用程序的类型进行不同地处理。例如，在 Windows 窗体应用程序中，可以提示用户提供身份验证信息，也可以使用用户的 Windows 凭据。但是，Web 应用程序通常使用应用程序自身提供的凭据来访问数据，而不是使用用户提供的凭据。用户经过身份验证后，其操作范围取决于向他们授予的权限。始终遵循最小特权原则，并且仅授予绝对必需的权限。
2.参数化命令和 SQL 注入
使用参数化命令可帮助抵御 SQL 注入攻击，这种攻击的攻击者会将命令“注入”SQL 语句，从而危及服务器的安全。通过确保将从外部源接收的值仅作为值（而不是作为 Transact-SQL 语句的一部分）进行传递，参数化命令可抵御 SQL 注入攻击。这样，便不会在数据源中执行插入到值中的 Transact-SQL 命令。相反，只会将这些命令作为参数值来计算。除具备安全优势外，参数化命令还提供一种便捷方法，使用该方法可组织随 Transact-SQL 语句传递或传递到存储过程的值。
3.ADO.NET安全数据访问对脚本攻击
脚本攻击是另一种形式的注入，它使用插入到网页中的恶意字符。浏览器无法验证这些插入字符，并且会将它们作为页面的一部分进行处理。
4.保护 Microsoft Access 和 Excel 数据源
当具有最少的安全要求或没有安全要求时，Microsoft Access 和 Microsoft Excel 可充当 ADO.NET 应用程序的数据存储区。其安全功能作为一种阻止手段固然有效，但其作用仅限于阻止不了解情况的用户乱摸乱动而已。Access 和 Excel 的物理数据文件位于文件系统上，并且注定可供所有用户访问。这使得这些文件易受到攻击，从而导致文件失窃或数据丢失，因为他人可轻松复制或更改这些文件。如果需要强有力的安全措施，请使用 SQL Server 或其他基于服务器的数据库，这样便无法从文件系统读取物理数据文件。
5.ADO.NET安全数据访问企业服务
COM+ 包含其自己的安全模型，该模型依赖于 Windows NT 帐户和进程/线程模拟。System.EnterpriseServices 命名空间提供的包装允许 .NET 应用程序通过 ServicedComponent 类来集成托管代码与 COM+ 安全服务。
6.与非托管代码交互
.NET Framework 提供与非托管代码（包括 COM 组件、COM+ 服务、外部类型库及许多操作系统服务）的交互。使用非托管代码时会超出托管代码的安全边界。您的代码和调用它的任何代码都必须具有非托管代码权限（指定了 UnmanagedCode 标志的 SecurityPermission）。非托管代码会无意中将安全漏洞引入您的应用程序中。因此，除非绝对必要，否则应避免与非托管代码进行交互。
