ORM 的 SQL 注入漏洞在哪里？答案

【问题标题】：Where are ORM's vulnerable for SQL injection?ORM 的 SQL 注入漏洞在哪里？
【发布时间】：2011-07-07 13:51:58
【问题描述】：

在使用 ORM（实体框架、LINQ to SQL、NHibernate ...）时，是否可以通过设计缓解 SQL 注入攻击？

如果没有，我应该在哪里做一些额外的验证/清理以防止漏洞？

【问题讨论】：

如果不是，它们就是一个非常糟糕的 ORM。

标签： nhibernate entity-framework orm sql-injection

【解决方案1】：

大多数（如果不是全部）主流 ORM 使用参数化 SQL，这将保护您免受直接 SQL 注入攻击。然而，应用层的参数化 SQL 并不能保护您免受潜在的 SQL 注入攻击。当 ORM 之外的某些东西直接连接 SQL 语句中的用户输入（例如连接用户输入以创建非参数化动态查询的批处理运行存储过程）时，就会发生这种情况。请注意，这根本不是 ORM 问题，但我想我要指出的是，参数化 SQL 只有在无处不在的情况下才能保护您免受注入，而不仅仅是在 ORM 中。

【讨论】：

【解决方案2】：

它们在 NHibernate 中使用参数化查询。

【讨论】：

【解决方案3】：

在基本概念中，ORM 被设计为安全的。大多数时候您不必担心，但如果您认为自己可能会面临真正的破解，您应该进行一些自定义调整。

对于简单的应用程序，简单的 SQL 注入将涵盖在内。在安全和 SQL 注入问题上，没有任何机构（说真的，从来没有机构）会给您灵丹妙药。这是我的建议。

【讨论】：

自定义调整？你在说什么？
获取源代码，配置的每一个小方面等等。我似乎从来没有这样做过......
除非你给我一个你必须做的调整的具体例子，否则我会假设你只是想听起来像一个安全专家而不是安全专家。

【解决方案4】：

ORM 通常使用大量动态 SQL，这是不安全的，因为它使应用程序和/或服务帐户的用户能够执行即席 SQL 查询。正确的解决方案是只有程序员和数据库管理员拥有 DataReader/DataWriter 和所有接触数据库的程序，除了参数化的存储过程之外什么都不使用，始终没有与程序关联的 DataReader/DataWriter 访问。他们只能访问我说他们可以访问的 SP。只有数据库管理员和程序员才能执行临时 SQL 查询。

【讨论】：

您能否提供一个这样的应用程序示例，该应用程序使用存储过程而没有与程序关联的 DataReader/DataWriter 访问权限？谢谢。
我有几个应用程序在工作，它们有一个数据访问层，除了 SP 之外什么都不调用，唯一使用 DataReader/DataWriter 的人是我和数据库管理员。用户帐户/服务帐户将在 SELECT * FROM MyTable 类型的语句上全部失败，除非我创建一个名为该语句的存储过程并授予它们执行权限。
SELECT * FROM MyTable类型的语句没有错，你懂的
我认为 SELECT * FROM MyTable 安全的唯一方法是如果没有连接并且字符串是文字和硬编码的。这是我相信它的唯一方式。第二个参数用于构造它，谁知道当任何结果字符串文字提交到数据库时会发生什么。实际上，问题可以通过不让任何人一开始就提交来自随机用户的临时 SQL 查询来解决。如果除了数据库管理员或程序员之外的任何人想要访问 SP，他们会使用现有的数据库或提出请求。
您的程序中没有这样的查询吗？