防止 csv 导入应用程序中的 SQL 注入

Question

这更多的是一个概念问题。

我已经用 C# 构建了一个小型 wpf 应用程序来读取工资单数据的 csv 并将其插入到我的 sql 2005 数据库中，无需编辑或删除。

我已经采取了我能想到的所有步骤来保护应用程序免受用户输入 SQL 注入并阅读该主题。这些步骤包括将连接字符串用户作为低级 sql 用户、将我的数据网格控制列与 sql 表紧密匹配以及不可编辑的用户输入（组合框、文件和日期选择器、仅某个 csv 文件名）。我的数据源更新方法是将csv读取并显示在datagrid中的数据表合并到sql数据表中，然后更新。

我现在有一个想法，最明显的弱点是 csv 文件本身（我可以看到！）。我可以看到有人可以创建一个具有正确文件名的 csv 并在“删除[某些语句]”列中输入，然后将其读入。

所以现在我觉得有必要检查这个输入，但很多文章说这个客户端的东西是浪费时间。其他人的想法是什么？我正在考虑一个简单的类，其中包含要检查的内容列表，例如“sp”、“;”、“选择”、“删除”、“--”，然后是一个函数来根据列表检查 csv 列输入并处理为必需的。

班级理念是不是有点粗糙？

Answer 1

我正在考虑一个简单的类，其中包含要检查的内容列表，例如“sp”、“;”、“选择”、“删除”、“--”，然后是一个函数来根据列表检查 csv 列输入并处理为必需的。

班级理念是不是有点粗糙？

是的。也是无效的。寻找违规术语并将其过滤掉是一场失败的战斗。相反，您应该做的只是不要将用户输入作为数据库中的代码执行。如果有人输入字符串“DELETE”并且您将该字符串作为代码执行，那么您就很容易受到攻击。另一方面，如果有人输入字符串“DELETE”，而您只需将该字符串保存到数据库中，那么他们所做的就是将数据输入到数据库中。

将用户输入字符串视为字符串，而不是代码。拯救他们，不要处决他们。

如果没有看到实际的数据访问代码，就很难更具体。您可能对 SQL 注入攻击持开放态度。如果没有看到您的代码，这里的任何人都无法知道。

但 SQL 注入漏洞并不存在于 UI 中。这可能就是您在这个奇怪的声明中提到的内容：

很多文章都说客户端的东西是浪费时间

任何 SQL 注入漏洞都存在于与数据库交互的代码中。只要该代码的输入被正确处理为值而不是可执行代码（例如，参数化查询而不是查询串联），那么您就不应该存在 SQL 注入漏洞。