您已经在使用参数化查询来保护您免受 SQL 部分的注入，假设您始终对不受信任的数据使用参数。

正如您所说，在支持通配符的运算符中留下了通配符问题。也就是说，如果您使用“=”而不是 LIKE，则不会出现问题。在大多数有意使用 LIKE 的情况下，需要使用用户提供的数据进行搜索。因此，添加更多通配符可能不是问题。

但是，在前面添加通配符可能会对性能产生重大影响，因为前缀索引无法有效使用。因此，如果您的数据集很大，您可能需要过滤它们。标准通配符是 % 和 _，但有些数据库支持附加字符，例如 *。

这不安全，有几个原因 - 你可能甚至没有考虑过。

让我们从顶部开始：

• 您正在使用 ASP“经典”。众所周知，这个平台是不安全的。
• 您的提供商是Microsoft.Jet- 我假设这是连接到一个 MS Access 文件......同样，不是一个安全的后端。例如，没有对数据库的身份验证、共享文件的问题等。
• 我不知道你是否意识到这一点，如果它是故意的，或者它是否在你的应用程序中很重要，但是你正在从Request("odQuery")- 这可能是Request.Forms("odQuery")，Request.QueryString("odQuery")等等......攻击者可以滥用它，例如通过制作一个链接（而不是 POST）并让其他人（例如具有更高权限的人）提交它。
• 我在这里推测，但从前面的代码（以及这是“经典 ASP”这一事实）来看，“ I then go on to display the results from rs”我猜测很可能会导致 XSS（跨站点脚本）。
• 现在，让我们谈谈 SQL 注入 - 正如@Hendrik 在他的回答中指出的那样，通配符是一个问题。这可能有两个问题：
  
  • 访问用户不应访问的数据
  • 通过导致计算密集型搜索来创建 DoS（拒绝服务）攻击，例如将通配符放在大型数据集的前面（正如 @Hendrik 指出的那样）。

如果您正在专门寻找一种执行辅助查询的方法，那么您可以避免这种情况，至少在 Access 上是安全的（不使用全功能数据库的一些好处......）。
但是，还有其他形式的 SQL 注入（如上），甚至还有更多不安全的方式。