Каковы передовые методы предотвращения SQL-инъекций в node-mysql?

На эту тему было некоторое обсуждение (например, Предотвращение внедрения SQL в Node.js ), но на самом деле никакой четкой ясности или глубокого обсуждения, не говоря уже о хорошей документации. В документации по node-mysql обсуждается предотвращение SQL-инъекций и некоторые функции побега. Однако неясно, как эти функции предотвращают внедрение SQL. В руководстве сказано: «Строки безопасно экранированы». Ничего больше... Это ограничено экранированием только некоторых символов?

Похоже, что в node-mysql есть другие эквиваленты для той же функции, что и в connection.escape и pool.escape, с еще одним акцентом на том, что эти функции используются для предотвращения SQL-инъекций.

Похоже, что в node-mysql также нет поддержки истинного оператора подготовки. Планы и документация по этому поводу снова неясны. Node-mysql, безусловно, очень популярный модуль в среде node.js и довольно стабильный, по крайней мере, при том ограниченном опыте, который у меня был с ним. Каковы передовые методы предотвращения SQL-инъекций в node-mysql?


person Sunny    schedule 21.09.2015    source источник
comment
Я, конечно, не эксперт в использовании node-mysql или экранировании sql, но я бы предложил использовать синтаксис параметризованного запроса каждый раз, когда вам нужно создать запрос sql самостоятельно. Этот модуль, кажется, поддерживает это. Если вы используете какие-либо другие методы, такие как find, findById, clone и т. д., вам не нужно об этом беспокоиться, поскольку построенный запрос создается с использованием синтаксиса параметризованного запроса.   -  person Kevin B    schedule 21.09.2015


Ответы (2)


Помните, что SQL-инъекции вызываются интерпретацией враждебных строк как команд, а не блокирующими командами. Вы уверены, что возвращаете исходную строку, а не строковую версию?

Например, есть огромная разница между этими двумя: "test" и "'test'".

Как правило, экранируются только вредоносные символы, остальные оставляются как есть.

Лучше избегать использования низкоуровневого драйвера. Попробуйте использовать такую ​​библиотеку, как Sequelize, чтобы обеспечить некоторую абстракцию и дополнительную поддержку. Этот модуль поддерживает операторы-заполнители, которые обычно делают экранирование не проблематичным, оно обрабатывается автоматически.

См. раздел необработанные запросы с заменами, где у вас есть возможность сделай это:

sequelize.query('SELECT * FROM projects WHERE status = ?',
  { replacements: ['active'], type: sequelize.QueryTypes.SELECT }
).then(function(projects) {
  console.log(projects)
})

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

person tadman    schedule 21.09.2015
comment
модуль mysql (от которого зависит node-mysql) также поддерживает параметризованные запросы. - person Kevin B; 21.09.2015
comment
@kevinb Если это так, это то, что нужно использовать. В параметризованных запросах гораздо труднее ошибиться, а ошибки внедрения, если они случаются, обычно являются результатом множества ошибок, а не одной. - person tadman; 21.09.2015
comment
Я думаю, что использование sequenceize только для решения одной проблемы может не оправдать его использование. Что касается использования параметризованных запросов, разве не здесь в первую очередь вступает в игру SQL-инъекция - при присвоении пользовательских значений этим параметрам? Я думаю, что использование истинных операторов подготовки для использования параметризованных запросов имеет большое значение для предотвращения SQL-инъекций, но такие подготовленные операторы (как в PHP) здесь не поддерживаются. Или они в какой-то форме? - person Sunny; 21.09.2015
comment
@Samir Способ №1 предотвратить SQL-инъекцию - быть чрезвычайно дисциплинированным в использовании подготовленных операторов. Как отмечает Кевин Б., модуль MySQL поддерживает их, так что используйте их. SQL-инъекция проста: вы не можете правильно экранировать что-то, и это заканчивается вашим запросом. Чаще всего это происходит при неаккуратном составлении запроса. Параметризованные запросы полностью обходят это, вы никогда не размещаете пользовательские данные в потенциально опасном месте. Что касается Sequelize, это отличная библиотека, которая помогает на многих уровнях, а не только в качестве заполнителей. - person tadman; 21.09.2015
comment
@tadman, конечно, согласен с тобой насчет побега. Я хочу понять точную область или полезные примеры функции escape, предоставляемой node-mysql для использования в параметризованных запросах. Он экранирует кавычки и некоторые подобные символы, которые могут синтаксически испортить запрос, но что еще он делает, чтобы квалифицироваться как предотвращение SQL-инъекций? - person Sunny; 21.09.2015
comment
@Samir Это все, что нужно сделать. Пока ваша база данных правильно интерпретирует строку как значение, а не как оператор, ваша экранирующая функция выполнила свою работу. Это ничем не отличается от того, что вы должны делать в HTML, чтобы избежать изменения пользовательским содержимым структуры страницы. - person tadman; 21.09.2015
comment
Я удивлен, что никто не упомянул подготовленные операторы/параметры привязки. node-mysql их не использует, поэтому при использовании пользовательских значений в запросах существует неотъемлемая угроза безопасности. Однако, если вы используете подготовленные операторы в node-mysql2, вы защищены от SQL-инъекций, даже если вы используете значения, предоставленные пользователем. Sequelize использует node-mysql в качестве драйвера mysql, поэтому он уязвим. - person Cully; 05.03.2016
comment
@Cully Sequelize использует подготовленные операторы, чтобы избежать этой проблемы, но если вы сделаете все возможное, вы можете создать ошибки внедрения. Нет проблем с node-mysql, если вы правильно используете Sequelize. - person tadman; 07.03.2016
comment
@tadman Sequelize не использует подготовленные операторы. Он имитирует их в коде. Они в основном просто избегают значений. Реальные подготовленные операторы обрабатываются самой базой данных. - person Cully; 07.03.2016
comment
@Cully Вы просто спорите о деталях реализации. Их эмуляция вполне приемлема, если вы просто беспокоитесь о целостности данных. - person tadman; 07.03.2016

по-прежнему сиквелиз уязвим

db.query('SELECT Desc FROM Items WHERE Username IN (:names)', {
  replacements: {
    names: ["Bobby", "'); DELETE FROM Items WHERE 1=1; --')"]
  }
});
person Rizwan Patel    schedule 16.12.2016