Шансы на SQL впрыск в динамически построенном SQL

Question

У меня есть такой запрос в MySQL

val selectQ = "SELECT NAME FROM EMPLOYEE"
val date = "2010-10-10"
val age = 10

Теперь у меня есть несколько динамических предложений c AND, например

 val whereNameFilter = "WHERE date = $date"
 val andAgeFilter = "AND age = $age"

Я согласен whereNameFilter и andAgeFilter на основе условий, потому что иногда мне вообще не нужно его объединять

Я не хочу использовать ORM, поскольку ORM продемонстрировали низкую производительность и хотят достичь в Plain SQL, поскольку он оказался высоким представление. Точно так же у меня есть несколько подзапросов, которые являются Dynami c на основе полей ввода. Предполагая, что все мои входные данные санированы и перед созданием запроса выданы соответствующие ошибки, какова вероятность SQL внедрения?

Если есть шанс, каковы пути его предотвращения? Есть ли какая-либо утилита, которая помогает мне динамически создавать запросы с помощью подзапросов dynamici c AND / OR / IN и dynamici c?

Мой язык программирования Scala

Answer 1

Есть разница между строками, которые вы контролируете жестким кодированием в своем приложении, и строками, полученными из ненадежных источников.

Я не Scala программист, поэтому я сформирую это как псевдокод:

conditions = Array()
params = Array()
selectQ = "SELECT NAME FROM EMPLOYEE WHERE true

if (date_input) {
  selectQ += "AND date = ?"
  params.append(date_input)
}

if (age_input) {
  selectQ += "AND age = ?"
  params.append(age_input)
}

query = prepare(selectQ)
fore (params as i=>p) {
  query.setString(i, p)
}

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

Другое содержимое объединяется в качестве связанных параметров. Параметры запроса NOT просто добавляются к запросу, они хранятся отдельно до окончания prepare() запроса. После этого синтаксис запроса уже был разобран механизмом SQL, поэтому содержимое не может повлиять на синтаксический анализ.

---

Ваш комментарий:

Если сами выражения являются частью ненадежного контента (включая, но не ограничиваясь пользовательским вводом), то их дословная интерполяция в ваш запрос SQL конечно SQL инъекция. Вы не должны этого делать.

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

Еще лучше разрешить клиенту выбрать известное безопасное выражение по некоторому идентификатору. Например, клиент должен передать целое число 7, и это будет соответствовать «И возраст =?» это жестко запрограммировано в вашем приложении.

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

Это похоже на то, что вы электрик, а не инженер-программист, и ваш работодатель сказал вам провести несколько неизолированных проводов через ведро с масляной тряпкой. Я думаю, что ваша профессиональная ответственность - отказаться от выполнения их заказов. Они могут уволить вас и найти кого-то еще, чтобы сделать это, но по крайней мере вы не будете нести ответственность за неизбежный пожар в доме.