C# asp.net 从 viewstate 动态构建 SQL Query答案

【问题标题】：C# asp.net build SQL Query dynamically from viewstateC# asp.net 从 viewstate 动态构建 SQL Query
【发布时间】：2009-01-24 21:40:21
【问题描述】：

在我的 C# asp.net 网络表单中，我有一个搜索页面，其中包含大约 20 个“可以”用作搜索的一部分的元素。以后会有更多的补充。

我所做的是扩展文本框和下拉列表框以包含一些变量：

字段名：Tablename.columnname 数据库类型：DbType.Int32 Joinparam: LEFT Join on otherTable ON x.y = a.b

这些都存储在视图状态中并重新加载。我这样做的原因是我可以遍历所有控件并拉出所有属于我的类型的控件。然后我可以验证它们以确保它们有输入并且是正确的类型。如果是这样，我可以将它们传递给数据库访问层，让代码动态生成 SQL 语句。

除了 SELECT 语句之外，我不会让任何事情发生。选择和返回的字段不能更改，我使用db参数来尝试避免sql注入。

我担心的是，我将在搜索条件中使用的表和字段名称以及所需的 JOINS 都放在了视图状态中。这是一个真正的坏主意吗？

我可以通过在数据库中保存此信息的表中添加一些 int 索引来掩盖这一点，但这仍然需要放入视图状态中，这意味着它们将有一个额外的层来计算。

我采用这种方法的原因是我不想在 DB 层中放置大量的 IF 语句来构建语句。这将是丑陋的地狱和痛苦的维护。

感谢您对此提出的任何建议。

乔恩

编辑

感谢大家的建议。谢天谢地，这个应用程序只是一个内部的东西，所以损害是有限的。但我永远不会再使用这种技术，而是会研究搜索模板的想法。

干杯:)

【问题讨论】：

标签： c# asp.net security viewstate

【解决方案1】：

我认为在视图逻辑中对部分数据访问层进行编码是一个真正的设计错误。撇开安全问题不谈，对于任何追随你的人来说，这将很难维护和理解。我认为从长远来看，从各种选定输入生成特定查询的工厂类可能会更容易使用。或者，您可以从输入中填充“搜索模板”，并将搜索模板功能用作生成查询的工厂，就像 UserPrincipal 与 System.DirectoryServices.AccountManagement 命名空间中的 PrincipalSearcher 交互的方式一样。

【讨论】：

嗨，Tvan，我明白你在说什么。我怎样才能松散地链接您的搜索模板和网页，以便它知道应该将哪些变量映射到哪里而不会泄露任何安全问题？

【解决方案2】：

Viewstate 没有加密，它是 base64 编码的。有现成的实用程序可让您解码页面的视图状态。

可以对一个页面或所有页面的视图状态进行加密，但是： http://msdn.microsoft.com/en-us/library/aa479501.aspx

也就是说，我不会推荐这种方法。应用程序设计的最佳方法是将 UI 与业务和数据访问逻辑分离。在这种情况下，您将紧密耦合它们而没有明显的好处。

如果您确实在数据访问层中构建了更强大的即席查询功能，那么您可能正在为应用程序的后端增加价值。您可以通过 Web 服务、Windows 窗体应用程序等提供搜索功能。即使这种类型的功能不是您设想在不久的将来发生的事情，但当您采用这种方法时，它可以节省大量时间（和 $$$）。

您在 UI 中内置的逻辑可以很容易地内置到某种类型的查询引擎中。除了您想要避免的 IF，您可以构建一个方法来通过动态添加条件来组装查询。

【讨论】：

谢谢吉姆。我没有意识到它只是被编码的......那不好，（对我来说就是这样）。

【解决方案3】：

好的，所以 ViewState 默认为MACed，并且可以选择加密。因此，尽管您可以（默认情况下）读取视图状态，tampering isn't trivial。

像这样动态构建您的查询肯定会打开 Sql Injection - 您正在参数化搜索词，但如果我可以将 ;DROP TABLE 语句注入到您的 JOIN 子句中，那么您将被淹没（除非您已经当然，要小心设置数据库级别的安全性）。

话虽如此，我看不出有任何理由让您的 JOIN 子句等出现在 ViewState 中。我想你会在 ASPX 标记中将它们设置为子类文本框的属性——它们没有理由改变。您可能需要 ViewState 的唯一事情是搜索条件本身 - 已适当参数化。这类似于 SqlDataSource 保护其 SelectCommand 属性的方式——不要将其存储在 ViewState 中以免泄露信息（或有篡改风险——尽管我认为这不是一个严重的漏洞）。

至于这是否可维护的更大问题 - 好吧，我想你必须打这个电话。

【讨论】：