可以将通配符字符串存储在列中（与LIKE运算符一起使用）会导致意外的查询结果或安全问题吗？

Question

是否可以将通配符字符串存储在表的列中（用作LIKE查询中运算符的第二个操作数）会导致任何非显而易见的行为？我特别想知道意外查询结果或安全性问题的可能性。

这是我想知道的示例用法：

表格示例：

| ID        | String              |
|-----------|---------------------|
| 1         | A__XX____5__________|
| 2         | A__XX____6__________|
| 3         | A__YX____5__________|
| 4         | B__XX____5__________|
| 5         | A__XX____5__________|
| 6         | A__XX____7__________|
| 7         | A__YY____5__________|

查询示例：

SELECT ID
FROM ExampleTable
WHERE 'AVVYXZZZZ5ABCDEFGHIJ' LIKE String;

查询结果：

SELECT ID
FROM ExampleTable
WHERE 'AVVYXZZZZ5ABCDEFGHIJ' LIKE String;

这是使用它们的有效且惯用的方法吗？在某些文档或其他参考资料中是否有使用此类SQL通配符的示例？

Answer 1

如果将用户输入直接输入到表中而不进行验证，并且用户只能看到自己的内容，则可能会出现安全漏洞。

也就是说，如果'%'可以允许某人看到他们不应该看到的数据。

但是，在类似模式下使用列名不存在SQL注入风险，因为它不会导致另一个命令“无意间”运行。并且，如果您将模式放入表中以进行匹配，则不会有其他风险。

可能与性能有关，但这完全是另一个问题。

Answer 2

这种做法没有固有的基本安全缺陷。但是，您可能需要解析或严格控制输入字符串的格式，以免出现以下条目：

 | ID        | Identifier          |
 | --------- |---------------------|
 | 8         | A%                  |
 | 9         | %                   |

还要注意，攻击者不太可能选择在这种模式用法中寻找缺陷，因为这种情况非常罕见。

如果新的数据模式无意中与现有过滤器字符串匹配，则错误地返回了旧过滤器的新条目，则可能会出现问题。但是，良好的数据格式化做法应能够防止出现此类问题。