实体框架4.0的扩展和安全性

Question

实体框架4.0的扩展和安全性

asp.netsecurityentity-framework-4scalability

4

我想使用ORM，一直在看EF 4。这个平台可扩展吗？我在网上看到了很多东西，但每个人的观点都有所偏见。有人知道基准测试或非主观信息吗？

关于这一点，EF能否防止SQL注入或XSS攻击？我知道它使用参数化查询，但这是否足够？

感谢任何帮助。

- user295368

2个回答

1

不，ORM不是扩展性的万能药。对象和数据库之间存在所谓的阻抗不匹配问题，这个问题已经存在多年了。ORM通过提供魔法代码生成/映射解决方案来解决这个问题，从而表现出仅使用对象即可工作的外观。

在一个多层环境中，有许多客户端程序和单个/多个服务器场景，在每次需要提交到数据库的更改中，需要进行检查以确保您没有覆盖其他人对数据所做的更改，或者尝试更新已删除的数据。这不是ORM引入的新问题，而是在N-Tier环境中更新数据库时经常出现的问题。ORM无法解决此问题。在某些情况下，如果ORM是连接数据库的唯一入口，则ORM成为瓶颈。这意味着使用ORM创建可扩展架构变得棘手，因为在ORM上执行DB检查意味着在使用具有重复ORM层的N-Tier ORM解决方案时可能会绕过更新异常检查。

由于以上原因，这就是为什么我们使用存储过程的原因。但如果您使用存储过程，自然会混淆数据库底层数据结构，这会增加对象和数据库实体之间的阻抗不匹配。对于使用存储过程并依赖表锁定/行锁定的一个好处是解决了某些更新方案，例如将瓶颈转移至底层数据库设计的性能。

那么答案是什么呢？不要使用对象来操作数据库。对象在分析时很棒，在与RDBMS数据库交互时则很糟糕。

如果您真的认为SQL和RDBMS数据解决方案存在问题（在某些情况下确实如此），请看看一些现有的NOSQL解决方案。虽然并非万无一失，但在某些情况下它们提供了比直接SQL解决方案更好的解决方案。

对象并不是所有问题的答案。从您的代码中退后一步，看看您正在尝试做什么，并考虑一下对象是否是正确的方法。

至于安全性，ORMS并不能提高安全性。虽然它们确实有助于防止某些形式的注入攻击。

- WeNeedAnswers

我是通过吃亏学到的。当时我认为我的项目已经完成了大约75%，但后来发现我的安全策略基于对Entity Framework缺乏深入理解。在我的应用程序中，数据安全非常重要，因此只有被允许查看数据的用户才能查看数据。然而，使用Entity Framework实现这种级别的安全性是不可能的。 - Parth Shah

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- RPM1984 · Accepted Answer

好的，我看到这里有两个问题。

EF是否可扩展

很难（且主观）回答，但在我看来是可以的。

以下是一些原因：

使用通用查询语言（LINQ）
允许多个提供程序（SqlServer、Oracle等）
允许双向映射（代码优先、模型优先、数据库优先）
包括“经典ADO.NET”支持（存储过程、Entity-SQL）

可扩展性的主要实际好处在于框架建立在LINQ-to-Entities上。当您编写查询时，您不是针对SQL Server或Oracle编写，而是针对模型编写。取决于您设置的提供程序（在web.config中），EF将把这些模型查询转换为适当的T-SQL（或P-SQL）。

因此（理论上），您可以针对SQL Server编写代码，然后更改web.config提供程序为Oracle，并且您的代码应该能够工作。当然，这不适用于Entity-SQL（因为您正在编写T-SQL，而不是LINQ）。

EF是否防止SQL注入或XSS

没有ORM工具可以真正“防止”SQL注入攻击-它们只能为开发人员提供工具以防止它。

与使用参数化查询的经典ADO.NET一样，Entity Framework有Entity-SQL，它允许执行预生成的SQL、存储过程等。

在这种情况下，需要使用参数化查询来防止SQL注入。对于大多数EF工作，您将使用LINQ编写查询，这是比较安全的，因为它会通过许多阶段进行填充，然后变成SQL。

XSS是通过诸如注入JavaScript、可疑电子邮件等方式在客户端上利用的。与Entity Framework无关。预防XSS是在客户端上使用HTML编码等方法实现的。