使用 NHibernate 时实现安全性的最佳实践是什么？
传统主义者认为，与使用 NHibernate 等对象关系映射 (ORM) 框架相比，存储过程提供了更好的安全性。
为了反驳这个论点，NHibernate 可以使用哪些方法来确保适当的安全性（例如，防止 sql 注入等）？
（每个答案请仅提供一种方法）
Traditionalist argue that stored procedures provide better security than if you use a Object Relational Mapping (ORM) framework such as NHibernate.
To counter that argument what are some approaches that can be used with NHibernate to ensure that proper security is in place (for example, preventing sql injection, etc.)?
(Please provide only one approach per answer)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
http://weblogs.asp.net/fbouma/archive/ 2003/11/18/38178.aspx
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
大多数 ORM 通过创建参数化查询来处理 SQL 注入。 在 NHibernate 中，如果您使用 LINQ to NHibernate 或 Criteria/Query over 编写查询的方法，查询会自动参数化，如果您自己动态创建 HQL/SQL 查询，您会更容易受到攻击，并且必须记住，您的查询必须参数化。
Most ORM's handle SQL injection by creating parameterized queries. In NHibernate, if you are using LINQ to NHibernate or the Criteria/Query over methods of writing queries, the queries are automatically parameterized, if you are dynamically creating HQL/SQL queries yourself you are more vunerable and would have to keep in mind that your queries would have to be parameterized.
OWASP 在 ORM 工具的上下文中提到了一种形式的 SQL 注入漏洞（并以 HQL 注入为例）： http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection
OWASP mentions one form of SQL injection vulnerability in the context of ORM tools (and gives HQL injection as an example): http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection
保护您的连接字符串。
从 .NET 2.0 和 NHibernate 1.2 开始，可以轻松地在配置文件中使用加密的连接字符串（和其他应用程序设置）。 将连接字符串存储在
connection.connection_string_name属性而不是connection.connection_string。 如果您运行的是网站而不是 Windows 应用程序，则可以使用aspnet_regiis命令行工具来加密另一种策略是对数据库连接使用集成身份验证（如果您的数据库平台支持）。 这样，您（希望）不会在配置文件中以明文形式存储凭据。
Protect your connection strings.
As of .NET 2.0 and NHibernate 1.2, it is easy to use encrypted connection strings (and other application settings) in your config files. Store your connection string in the
<connectionStrings>block, then use the NHibernateconnection.connection_string_nameproperty instead ofconnection.connection_string. If you're running a web site and not a Windows app, you can use theaspnet_regiiscommand line tool to encrypt the<connectionStrings>block, while leaving the rest of your NHibernate settings in plaintext for easy editing.Another strategy is to use Integrated Authentication for your database connection, if your database platform supports it. That way, you're (hopefully) not storing credentials in plaintext in your config file.
实际上，如果您使用 SQL 或 HQL 构建查询，NHibernate 可能容易受到 SQL 注入的攻击。 如果需要执行此操作，请确保使用参数化查询，否则您将陷入痛苦的境地。
Actually, NHibernate can be vulnerable to SQL injection if you use SQL or HQL to construct your queries. Make sure that you use parameterized queries if you need to do this, otherwise you're setting yourself up for a world of pain.
使用专用的锁定 SQL 帐户
Use a dedicated, locked-down SQL account
我听到的支持存储过程而不是 ORM 的论点之一是，他们不希望人们在数据库中做任何他们想做的事情。 他们不允许对表本身进行选择/插入/更新/删除。 每个操作都通过 DBA 审查的程序进行控制。 我可以理解这种想法的来源......尤其是当你有一群业余爱好者都在你的数据库中操作时。
但时代变了，NHibernate 也不同了。 这是令人难以置信的成熟。 在大多数情况下，它会比您的 DBA 编写更好的 SQL :)。
你仍然必须保护自己不做愚蠢的事情。 正如蜘蛛侠所说的“能力越大，责任越大”，
我认为给予 NHibernate 适当的数据库访问权限并通过其他方式（例如审计日志记录和定期备份）控制操作更为合适。 如果有人做了愚蠢的事，你总能恢复过来。
One of the arguments I've heard in favor of sprocs over ORM is that they don't want people to do whatever they want in the database. They disallow select/insert/update/delete on the tables themselves. Every action is controlled through a procedure which is reviewed by a DBA. I can understand where this thinking comes from... especially when you have a bunch of amateurs all with their hands in your database.
But times have changed and NHibernate is different. It's incredibly mature. In most cases it will write better SQL than your DBA :).
You still have to protect yourself from doing something stupid. As spiderman says "with great power comes great responsibility"
I think it's much more appropriate to give NHibernate the proper access to the database and control actions through other means, such as audit logging and regular backups. If someone were to do something stupid, you can always recover.