我可以通过转义单引号并用单引号包围用户输入来防止 SQL 注入吗？

我意识到参数化 SQL 查询是在构建包含用户输入的查询时清理用户输入的最佳方法，但我想知道获取用户输入并转义任何单引号并用单引号包围整个字符串有什么问题。这是代码：

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

用户输入的任何单引号都会替换为双单引号，这消除了用户结束字符串的能力，因此他们可能输入的任何其他内容（例如分号、百分号等）都将成为字符串的一部分，并且实际上并未作为命令的一部分执行。

我们使用的是 Microsoft SQL Server 2000，我相信单引号是唯一的字符串分隔符，也是转义字符串分隔符的唯一方法，因此无法执行用户输入的任何内容。

我没有看到任何方法可以针对此问题发起 SQL 注入攻击，但我意识到，如果这像我认为的那样万无一失，那么其他人可能已经想到了它，并且这将是常见的做法。

这段代码有什么问题？有没有办法让 SQL 注入攻击绕过这种清理技术？利用此技术的示例用户输入将非常有帮助。

UPDATE:

我仍然不知道有什么方法可以有效地针对此代码发起 SQL 注入攻击。一些人建议反斜杠可以转义一个单引号并保留另一个来结束字符串，以便字符串的其余部分将作为 SQL 命令的一部分执行，我意识到这种方法可以将 SQL 注入到MySQL 数据库，但在 SQL Server 2000 中（我已经找到的）转义单引号的唯一方法是使用另一个单引号；反斜杠不会这样做。

除非有一种方法可以阻止单引号的转义，否则用户输入的其余部分都不会被执行，因为它们都将被视为一个连续的字符串。

我知道有更好的方法来清理输入，但我真的更感兴趣的是了解为什么我上面提供的方法不起作用。如果有人知道针对这种清理方法发起 SQL 注入攻击的任何具体方法，我很乐意看到它。

首先，这只是不好的做法。输入验证总是必要的，但它也总是不确定的。
更糟糕的是，黑名单验证总是有问题的，最好明确并严格地定义您接受的值/格式。诚然，这并不总是可能的——但在某种程度上它必须始终做到。
关于该主题的一些研究论文：

• http://www.imperva.com/docs/WP_SQL_Injection_Protection_LK.pdf http://www.imperva.com/docs/WP_SQL_Injection_Protection_LK.pdf
• http://www.it-docs.net/ddata/4954.pdf http://www.it-docs.net/ddata/4954.pdf（披露，最后一个是我的；））
• https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf（基于之前的论文，该论文已不再可用）

要点是，您所做的任何黑名单（以及过于宽松的白名单）都可以被绕过。我论文的最后一个链接显示了甚至可以绕过引用转义的情况。

即使这些情况不适用于您，但这仍然是一个坏主意。此外，除非您的应用程序非常小，否则您将不得不处理维护问题，也许还需要进行一定程度的治理：如何确保它在任何时候、任何地方都正确执行？

正确的做法是：

• 白名单验证：类型、长度、格式或接受的值
• 如果您想列入黑名单，请直接进行。引用转义是好的，但要在其他缓解措施的背景下进行。
• 使用命令和参数对象来准备和验证
• 仅调用参数化查询。
• 更好的是，专门使用存储过程。
• 避免使用动态 SQL，并且不要使用字符串连接来构建查询。
• 如果使用 SP，您还可以将数据库中的权限限制为仅执行所需的 SP，而不直接访问表。
• 您还可以轻松验证整个代码库仅通过 SP 访问数据库...