Первоначально я обнаружил, что это была проблема, когда я пытался найти термины, которые были добавлены хэштегом, который, как оказалось, является разделителем комментариев в SQL. Поиск не возвращался, потому что он игнорировал #term, который появился после хэштега.Как написать параметризованный SQL-запрос, чтобы предотвратить SQL-инъекцию?
Так что теперь у меня возникли проблемы с поиском надлежащего способа избежать ввода пользователя. Мне кажется, что это позволит решить проблему хештайга, а также решить гораздо большую проблему - SQL-инъекцию.
Вот фрагмент кода, я работаю с конкретно:
function (term) {
term = term.toLowerCase()
return db('ticket')
.select('*')
.where(db.raw('lower(question)'), 'like', `%${term}%`)
.orWhere(db.raw('lower(note)'), 'like', `%${term}%`)
.orWhere(db.raw('lower(user_name)'), 'like', `%${term}%`)
}
Я нашел this и this SO статью, в которой, казалось, близко, а также несколько других вещей. Кроме того, документы Knex и другие источники рекомендуют параметризованное связывание в качестве метода защиты от SQL-инъекции.
У меня возникли проблемы с поиском ясного примера, который может быть объяснен мне в JavaScript или с использованием Knex.
Является ли ваша сортировка БД особенно чувствительной к регистру? Вам не нужно использовать 'LOWER' с оператором' LIKE' - это также означает, что ваш запрос будет работать очень медленно, потому что он не может использовать индексы. – Dai
ИМО. «SQL Injection» - это что-то вроде «Проблема 2000»: много шума, но ничего серьезного. Существует два простых правила, позволяющих избежать «инъекций SQL»: 1) использовать параметризованные запросы на лицевой/средней стороне и 2) установить соответствующую безопасность уровня БД на объекты БД. – Abelisto
Спасибо за ответ. @Dai Я попробовал ваше предложение, но, похоже, он чувствителен к регистру. Я относительно новичок в db land, вы могли бы порекомендовать некоторые ресурсы, чтобы узнать об использовании индексов и сопоставлений, которые вы упомянули? Никогда не слышал условий раньше. –