这更像是一个概念问题。
我在 c# 中构建了一个小型 wpf 应用程序来读取工资单数据的 csv 并将其插入到我的 sql 2005 db 中，无需编辑或删除。
我已经采取了我能想到的所有步骤来保护应用程序免受用户进入 sql 注入并阅读主题。这些步骤包括将连接字符串用户作为低级 sql 用户，将我的数据网格控制列与 sql 表紧密匹配以及不可编辑的用户输入（组合框、文件和日期选择器，只有某个 csv 文件名）。我的数据源更新方法是将读取csv并在数据网格中显示的数据表合并到sql数据表，然后更新。
我现在有一个想法，最明显的弱点是 csv 文件本身（我可以看到！）。我可以看到有人可以创建一个具有正确文件名的 csv 并在“删除 [某些语句] - 等”列中输入并将其读入的可能性很小。
所以现在我觉得有必要检查这个输入，但是很多文章说这个客户端的东西是浪费时间。其他人的想法是什么？我在想一个简单的类，其中包含要检查的内容列表，例如“sp”、“;”、“选择”、“删除”、“--”，然后是一个函数来检查 csv 列输入与列表并处理为必需的。
上课的想法是不是有点粗糙？
我在想一个简单的类，其中包含要检查的内容列表，例如“sp”、“;”、“选择”、“删除”、“--”，然后是一个函数来检查 csv 列输入与列表并处理为必需的。
上课的想法是不是有点粗糙？
是的。这也是无效的。寻找冒犯性的术语并将其过滤掉是一场失败的战斗。相反，您应该做的只是不将用户输入作为数据库中的代码执行。如果有人输入字符串“DELETE”并且您将该字符串作为代码执行，那么您很容易受到攻击。另一方面，如果有人输入字符串“DELETE”，而您只需将该字符串保存到数据库，那么他们所做的就是将数据输入数据库。
将用户输入字符串视为字符串，而不是代码。保存它们，不要执行它们。
如果没有看到您的实际数据访问代码，很难更具体。您可能对 SQL 注入攻击持开放态度。没有看到您的代码，这里没有人可以知道。
但 SQL 注入漏洞不在 UI 中。这可能就是你在这个奇怪的声明中提到的：
很多文章说这个客户端的东西是浪费时间
任何 SQL 注入漏洞都将存在于您与数据库交互的代码中。只要对该代码的输入被正确处理为值而不是可执行代码（例如，参数化查询而不是查询连接），那么您就不应该存在 SQL 注入漏洞。
您应该能够使用 SQL 参数，而不是从输入数据构造 SQL 语句：