Запобігання ін’єкції SQL у Node.js

Чи можна запобігти ін'єкціям SQL в Node.js (бажано за допомогою модуля) так само, як PHP підготував заяви, які захищали від них.

Якщо так, то як? Якщо ні, то які приклади можуть обійти код, який я надав (див. Нижче).

Деякий контекст:

Я роблю веб-додаток із внутрішнім стеком, що складається з Node.js + MySql, використовуючи модуль node-mysql . З точки зору юзабіліті, модуль чудовий, але він ще не реалізував щось подібне до підготовлених заяв PHP (хоча я знаю, що це вже зроблено ).

Наскільки я розумію, реалізація PHP підготовлених заяв, серед іншого, значно допомогла у запобіганні ін'єкціям SQL. Однак я переживаю, що моя програма node.js може бути відкрита для подібних атак, навіть якщо рядок вимкнено за замовчуванням (як у фрагменті коду нижче).

node-mysql, здається, є найпопулярнішим з'єднувачем mysql для node.js, тому мені було цікаво, що можуть робити інші люди (якщо взагалі щось), щоб пояснити цю проблему - або якщо це навіть проблема з node.js для початку (не впевнений, як цього не було б, оскільки задіяно введення з боку користувача / клієнта).

Чи слід мені перейти на node-mysql-native , поки він надає підготовлені оператори? Я вагаюся це зробити, тому що це, здається, не настільки активне, як node-mysql (хоча це може просто означати, що воно завершено).

Ось фрагмент коду реєстрації користувача, який використовує модуль дезінфікуючого засобу разом із підготовленим синтаксисом, схожим на node-mysql (який, як я вже згадував вище, робить екранування символів), щоб запобігти міжсайтовим сценаріям та ін'єкціям sql відповідно:

// Prevent xss
var clean_user = sanitizer.sanitize(username);

// assume password is hashed already
var post = {Username: clean_user, Password: hash};

// This just uses connection.escape() underneath
var query = connection.query('INSERT INTO users SET ?', post,
   function(err, results)
   {
       // Can a Sql injection happen here?
   });

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

У бібліотеці є розділ у 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'
});

Окрім цих функцій, ви також можете використовувати функції екранування:

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");

Я усвідомлюю, що це старіший пост, але, схоже, відповіді так і не було позначено, тому я викину його туди.

Що стосується тестування, якщо модуль, який ви використовуєте, безпечний чи ні, є кілька шляхів, якими ви можете пройти. Я торкнусь плюсів / мінусів кожного, щоб ви могли прийняти більш обґрунтоване рішення.

На даний момент у модуля, який ви використовуєте, немає вразливих місць, однак це часто може призвести до помилкового відчуття безпеки, оскільки цілком може бути вразливість, яка зараз використовує модуль / програмний пакет, який ви використовуєте, і ви не отримаєте попередження до проблеми, доки постачальник не застосує виправлення / виправлення.

1. Щоб бути в курсі вразливостей, вам потрібно буде стежити за списками розсилки, форумами, IRC та іншими дискусіями, пов’язаними з хакерством. ПРО: Часто ви можете дізнатися про потенційні проблеми в бібліотеці, перш ніж постачальник отримає попередження або випустить виправлення / виправлення, щоб виправити потенційну можливість атаки на його програмне забезпечення. ПРОТ: Це може зайняти багато часу та вимагати ресурсів. Якщо ви все-таки пройдете цей шлях, бот використовує RSS-канали, синтаксичний аналіз журналів (журнали чату IRC) та або веб-скрепер із використанням ключових фраз (у цьому випадку node-mysql-native), а сповіщення можуть допомогти скоротити час, витрачений на тролінг цих ресурсів.

2. Створіть fuzzer, використовуйте fuzzer або інший фреймворк вразливості, такий як metasploit , sqlMap тощо, щоб допомогти перевірити проблеми, які постачальник не шукав. ПРО: Це може виявитись надійним методом забезпечення до прийнятного рівня незалежно від того, безпечний для загального доступу модуль / програмне забезпечення, яке ви впроваджуєте. ПРОТИ: Це також стає трудомістким і дорогим. Інша проблема буде пов’язана з помилковим спрацьовуванням, а також з непросвіченим переглядом результатів, якщо проблема існує, але її не помічають.

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

У будь-якому випадку, я усвідомлюю, що це не відповідь "так" чи "ні", на яку, можливо, сподівались, але я не думаю, що хтось може дати вам це, поки не проведе аналіз відповідного програмного забезпечення.

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

Він також дуже активний (остання зміна була від 2-1 днів), я раніше не пробував, але, думаю, це те, що ви хочете, і багато іншого.

Найпростіший спосіб - це обробляти всі ваші взаємодії з базою даних у власному модулі, який ви експортуєте до своїх маршрутів. Якщо ваш маршрут не має контексту бази даних, тоді SQL все одно не може його торкнутися.