Может ли хранение групповых строк в столбце (для использования с оператором 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;

Результат запроса:

| ID        |
|-----------|
| 3         | 

Это правильный и идиоматический способ их использования?Есть ли примеры в какой-либо документации или других справочных материалах, в которых используются подстановочные знаки SQL, подобные этому?

Answer 1

Ошибка безопасности - возможно - возникнет, если пользовательский ввод будет введен непосредственно в таблицу без проверки и пользователи ограничены тем, что они могут видеть.

То есть, если '%' может позволить кому-то видеть данные, которые он не должен.

Однако использование имени столбца для аналогичного шаблона не является риском внедрения SQL-кода в том смысле, что оно не может привести к непреднамеренному запуску другой команды. А если вы помещаете шаблоны в таблицу для сопоставления, дополнительного риска нет.

Может быть проблема с производительностью, но это совсем другая проблема.

Answer 2

В этой практике нет основных недостатков безопасности. Тем не менее, вам может понадобиться проанализировать или строго контролировать формат входных строк, чтобы вы не получили такие записи:

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

Также обратите внимание, что маловероятно, что злоумышленник захочет искать недостатки в использовании шаблона, как это, так как это очень редко.

Проблемы возможны, если новый шаблон данных непреднамеренно совпадает с существующей строкой фильтра, неправильно возвращая новую запись для старого фильтра. Тем не менее, хорошие методы форматирования данных должны быть в состоянии предотвратить любые подобные проблемы.

Answer 3

Я довольно широко использовал этот тип техники, и у меня не было проблем с производительностью или безопасностью из-за этого.Вариант использования, как правило, предназначен для хранения некоторых правил, поэтому в наборе данных есть только несколько строк, поэтому производительность никогда не будет проблемой.Примеры использования, где это весьма полезно, например:

Наличие таблиц сопоставления во время интеграций.Поэтому A1, A2, A3 в системе 1 необходимо отправить как X в другую систему.Используя подстановочные знаки, можно использовать одну строку.

Я всегда помещаю последовательность сортировки #, чтобы разрешить конфликт, и разрешение непреднамеренного значения становится ошибкой / функцией, а не недостатком безопасности.

Другой вариант, который я использовал довольно часто - когда движок должен учитывать тип атаки SQL Injtection, - это сделать шаг вперед и поставить условия.Поэтому сохраняйте полный PL / SQL или любое другое интерпретируемое условие языка, например @a = 'A' и @b = '2' ....

Предотвращение SQL-инъекций легко, но в конечном итоге экономит многокода.

Итак, вернемся к основному вопросу - техника будет работать отлично.