Предотвращение SQL-инъекции в Node.js

Возможно ли предотвратить инъекции SQL в Node.js (предпочтительно с помощью модуля) таким же образом, что у PHP были подготовленные заявления, защищенные от них.

Если да, то как? Если нет, то какие примеры могут обойти предоставленный мной код (см. Ниже).


Некоторые контексты:

Я создаю веб-приложение с фоновым стеком, состоящим из Node.js + MySql, используя // Prevent xss var clean_user = sanitizer . sanitize ( имя пользователя ); // предполагаем, что пароль hashed уже var post = { Имя пользователя : clean_user , Password : hash }; // Это просто использует connection.escape () под var query = connection . query ( «INSERT INTO users SET?» , post , function ( err , results ) { // Может ли инъекция Sql произойти здесь? }); Модуль rel = "noreferrer"> node-mysql . С точки зрения юзабилити, модуль замечательный, но он еще не реализовал что-то похожее на подготовленные заявления PHP(хотя я знаю, что он находится на todo ).

По моему мнению, реализация PHP готовых заявлений, среди прочего, значительно помогла предотвратить инъекции SQL. Однако я обеспокоен тем, что мое приложение node.js может быть открыто для подобных атак, даже при условии, что экранирование строки предоставляется по умолчанию (как в приведенном ниже фрагменте кода).

node-mysql, по-видимому, является самым популярным разъемом mysql для node.js, поэтому мне было интересно, что могут сделать другие люди (если они есть), чтобы учесть эту проблему - или если это даже проблема с node.js, чтобы начать с (не уверен, как этого не будет, так как вход пользователя / клиентской стороны задействован).

Должен ли я переключиться на node-mysql-native в настоящее время, поскольку он предоставляет подготовленные заявления? Я не решаюсь это сделать, потому что он не так активен, как node-mysql (хотя это может означать, что оно завершено).

Вот фрагмент кода регистрации пользователя, в котором используется модуль sanitizer , а также подготовленный синтаксис инструкции-node-mysql (который, как я уже упоминал выше, выполняет экранирование персонажа), для предотвращения межсайтового скриптинга и SQL-инъекций, соответственно:

node-mysql

javascript,mysql,node.js,sql-injection,node-mysql,

60

Ответов: 5


Некоторые контексты:

Я создаю веб-приложение с фоновым стеком, состоящим из Node.js + MySql, используя // Prevent xss var clean_user = sanitizer . sanitize ( имя пользователя ); // предполагаем, что пароль hashed уже var post = { Имя пользователя : clean_user , Password : hash }; // Это просто использует connection.escape () под var query = connection . query ( «INSERT INTO users SET?» , post , function ( err , results ) { // Может ли инъекция Sql произойти здесь? }); Модуль rel = "noreferrer"> node-mysql . С точки зрения юзабилити, модуль замечательный, но он еще не реализовал что-то похожее на подготовленные заявления PHP (хотя я знаю, что он находится на todo ).

По моему мнению, реализация PHP готовых заявлений, среди прочего, значительно помогла предотвратить инъекции SQL. Однако я обеспокоен тем, что мое приложение node.js может быть открыто для подобных атак, даже при условии, что экранирование строки предоставляется по умолчанию (как в приведенном ниже фрагменте кода).

node-mysql, по-видимому, является самым популярным разъемом mysql для node.js, поэтому мне было интересно, что могут сделать другие люди (если они есть), чтобы учесть эту проблему - или если это даже проблема с node.js, чтобы начать с (не уверен, как этого не будет, так как вход пользователя / клиентской стороны задействован).

Должен ли я переключиться на node-mysql-native в настоящее время, поскольку он предоставляет подготовленные заявления? Я не решаюсь это сделать, потому что он не так активен, как node-mysql (хотя это может означать, что оно завершено).

Вот фрагмент кода регистрации пользователя, в котором используется модуль sanitizer , а также подготовленный синтаксис инструкции-node-mysql (который, как я уже упоминал выше, выполняет экранирование персонажа), для предотвращения межсайтового скриптинга и SQL-инъекций, соответственно:

node-mysql
560
43 принят

node-mysqlБиблиотека автоматически выполняет спасаясь при использовании , как вы уже делаете. См. Https://github.com/felixge/node-mysql#escaping-query-values


9

В библиотеке есть раздел в readme об экранировании. Это Javascript-native, поэтому я не предлагаю переключиться на node-mysql-native . В документации указаны эти рекомендации по экранированию:

Редактировать: node-mysql-native также является чистым решением Javascript.

  • Номера остаются нетронутыми
  • Булевы преобразуются в true/ falseстроки
  • Объекты даты преобразуются в YYYY-mm-dd HH:ii:ssстроки
  • Буферы преобразуются в шестнадцатеричные строки, например X'0fa5'
  • Строки безопасно экранированы
  • Массивы превращаются в список, например, ['a', 'b']превращаются в'a', 'b'
  • Вложенные массивы превращаются в сгруппированные списки (для объемных вставок), например, [['a', 'b'], ['c', 'd']]превращаются в('a', 'b'), ('c', 'd')
  • Объекты превращаются в key = 'val'пары. Вложенные объекты передаются в строки.
  • undefined/ nullпреобразуются вNULL
  • NaN/ Infinityостаются как есть. MySQL не поддерживает их, и попытки вставить их в качестве значений вызовут ошибки MySQL до тех пор, пока они не будут реализованы.

Это позволяет делать так:

var userId = 5;
var query = connection.query('SELECT * FROM users WHERE id = ?', [userId], function(err, results) {
  //query.sql returns SELECT * FROM users WHERE id = '5'
});

А также это:

var post  = {id: 1, title: 'Hello MySQL'};
var query = connection.query('INSERT INTO posts SET ?', post, function(err, result) {
  //query.sql returns INSERT INTO posts SET `id` = 1, `title` = 'Hello MySQL'
});

Помимо этих функций вы также можете использовать функции escape:

connection.escape(query);
mysql.escape(query);

Чтобы избежать идентификаторов запросов:

mysql.escapeId(identifier);

И как ответ на ваш комментарий к подготовленным заявлениям:

С точки зрения юзабилити, модуль замечательный, но он еще не реализовал нечто похожее на подготовленные заявления PHP.

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

connection.config.queryFormat = function (query, values) {
  if (!values) return query;
  return query.replace(/:(w+)/g, function (txt, key) {
    if (values.hasOwnProperty(key)) {
      return this.escape(values[key]);
    }
    return txt;
  }.bind(this));
};

Это изменяет формат запроса для соединения, чтобы вы могли использовать такие запросы:

connection.query("UPDATE posts SET title = :title", { title: "Hello MySQL" });
//equivalent to
connection.query("UPDATE posts SET title = " + mysql.escape("Hello MySQL");

9

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

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

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

  1. Чтобы быть в курсе уязвимостей, вам нужно будет следить за списками рассылки, форумами, IRC и другими обсуждениями, связанными с взломом. PRO: Вы часто можете узнать о потенциальных проблемах в библиотеке до того, как поставщик был предупрежден или выпустил исправление / исправление, чтобы исправить потенциальный аспект атаки на их программное обеспечение. CON: Это может быть очень трудоемким и ресурсоемким. Если вы поедете по этому маршруту, бот с помощью RSS-каналов, разбора журнала (журналы чатов IRC) и веб-скребок с использованием ключевых фраз (в данном случае node-mysql-native) и уведомлений может помочь сократить время, затрачиваемое на троллирование этих ресурсов.

  2. Создайте fuzzer, используйте fuzzer или другую инфраструктуру уязвимости, такую ??как metasploit , sqlMap и т. Д., Чтобы помочь протестировать проблемы, которые поставщик, возможно, не искал. PRO: Это может оказаться верным методом пожарной безопасности на приемлемом уровне, независимо от того, безопасен ли модуль / программное обеспечение для открытого доступа. CON: Это также становится трудоемким и дорогостоящим. Другая проблема будет связана с ложными срабатываниями, а также необразованным обзором результатов, в которых проблема остается, но не замечена.

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

В любом случае, я понимаю, что это не ответ «да» или «нет», на который, возможно, надеялись, но я не думаю, что кто-то может дать это вам, пока они не проведут анализ данного программного обеспечения.


0

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


0

Я знаю, что этот вопрос старый, но для всех, кого интересует, Mysql-native устарел, поэтому он стал MySQL2 , это новый модуль, созданный с помощью команды исходного модуля MySQL. Этот модуль имеет больше возможностей, и я думаю, что он имеет то, что вы хотите, поскольку он подготовил операторы (using.execute ()), как в PHP, для большей безопасности.

Он также очень активен (последнее изменение было от 2 до 1 дня) Я не пробовал это раньше, но я думаю, что это то, что вы хотите и многое другое.

JavaScript, MySQL, Node.js, SQL-инъекции, узел-MySQL,
Похожие вопросы
Яндекс.Метрика