防止SQL注入，同时允许用户在查询结束时输入自己的条件

本文关键字：查询 结束 条件 自己的 输入 用户 注入 SQL 防止 许用户 | 更新日期: 2023-09-27 18:03:48

在我的程序中，我有一个查看联系人信息给用户的查询。该表通常显示不带过滤器的所有行。我想为用户添加一个选项，以便在SELECT语句的末尾编写他们自己的条件，以查看他们需要的信息。所以如果我的主查询是这样的:

SELECT * FROM CONTACTS

用户可以写条件

WHERE FirstName LIKE '%Michael%'

在文本框中。

然而，我知道这不是很安全，容易SQL注入。但是如何防止用户输入诸如

之类的恶意命令呢?
WHERE 1=1; DROP TABLE Contacts

在文本框中?目前，我正在使用对一些关键字的检查，例如，如果过滤器包含DELETE, DROP, UPDATE等，查询将不会运行。但我不认为这是一个非常安全的解决方案。

防止SQL注入，同时允许用户在查询结束时输入自己的条件

允许用户在{SQL}查询"的结尾编写&;他们自己的条件，会在你的应用程序中造成安全漏洞，使它容易受到SQL注入攻击。

如果您仍然希望继续，请考虑以下几点:

  • 使用正则表达式将输入限制为最基本的形式(例如，电话号码只允许0-9和连字符)
  • 在最低级别(即存储过程)实施保护机制
  • 用于存储过程中的动态查询…永远不要将字段名传递到存储过程
  • 永远不要使用不必要的权限运行。
  • 使用自己的登录名登录到应用程序的用户通常只应该对存储过程具有EXEC权限。
  • 如果你使用动态SQL，它应该被限制在读取操作，这样用户只需要SELECT权限。
  • 登录到数据库的网站不应该有任何特权，最好只有EXEC和(可能)SELECT权限。
  • 永远不要让网站管理员登录!
  • 总是使用参数化语句。
  • 进行代码审查以检查二阶攻击的可能性。
  • 确保错误消息不会泄露应用程序或数据库的内部架构。

再次…当你执行这个时要非常非常小心!

<标题>额外阅读
    Wikipedia: SQL注入攻击动态SQL的祸与福
  • SQL注入攻击和如何防止它们的一些提示
  • T‑SQL中的动态搜索条件
    • 利用SQL server系统的十大技巧

你说得对，这并不安全。没有什么安全的方法可以完全做到你想要的。任意SQL过滤器意味着用户可以平等地使用WHERE id IN (SELECT x FROM OPENROWSET(...))选择，例如，仍然允许执行DROP TABLE。

您可以做的是提供您自己的过滤器语法，并使用您自己的语法解析器，将其转换为SQL。您可以确保只允许从SQL中安全使用的特性。一些orm可能会提供这样一个开箱使用的特性，否则您将不得不自己创建一些东西。

我认为这个特性在设计上是不允许的:用户不仅需要了解数据库的工作原理，还需要知道正确的语法和数据模型。

尝试通过提供预定义的条件来掩盖这一点，例如"用户名中包含…"或"姓是"。

在c#端使用参数化查询来确保用户提供的输入是经过处理的。

这个问题无法回答。您需要一个允许SQL条件的搜索引擎，这就是SQL注入的定义。

这里有一些变通的想法:

  • 使用网格控件:您可以在网格内显示查询结果，并允许用户这样做使用网格来过滤结果。这很容易实现(你不需要重新发明轮子)，而且用户友好。此外，一些网格提供了非常强大的过滤选项。我能看到的唯一缺点是，你经常会从数据库中检索到比你实际需要的更多的结果。
  • 创建自己的过滤器语法:您可以编写自己的过滤器语法(hvd解决方案)。这将是大量的工作，如果你错过了一些东西，你可能仍然会有一个安全漏洞。
  • 编写条件构建工具:您可以提供条件构建工具。这是非常用户友好的，但最终可能不够灵活。
  • 导出到CSV:您可以提供将查询结果导出到CSV的工具，以便在Excel或Calc中轻松利用。对于有经验的电子表格用户来说，这将是非常友好的。
相关文章：