Деякі кращі практики Node.js

Крім створення зручного і чуйного інтерфейсу користувача, величезне значення має безпека програми. Відомо, що зловмисники маніпулюють додатками для отримання доступу до даних, що знаходяться поза їхньою досяжністю. Зловмисники використовують недоліки безпеки, видаючи себе за адміністраторів чи змінюючи ресурси, куди вони мають права.

Зловмисники впроваджують кінцеві точки API, побудовані на крос-платформі з відкритим кодом, такий як Node.js. Атака SQL-ін'єкції відбувається, коли користувач не санує або фільтрує дані, які він передає додатку.

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

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

Простий процес міг би уникнути катастрофи.

Найкращі практики безпеки Node.js

Це одна з найпопулярніших платформ відкритого типу, оскільки вона є бекенд-сервером для веб-додатків та встановлення додаткових модулів. Точка безпеки не рекомендується, оскільки це дає більше можливостей зловмисникам із чорного ходу. Чим популярніша платформа, тим більше зловмисники шукатимуть уразливості.

То як же захистити свої програми Node.js? Деякі з найкращих практик такі.

Валідація введення користувача

Поширеною та популярною атакою є SQL Injection. Вона відбувається, коли зловмисник може виконувати SQL-запити в базі даних жертви, і виникає коли користувач не санує свій фронт-енд.

Це означає, що Node.js back end бере параметри з даних, наданих користувачем, і використовує їх безпосередньо як частину SQL-запиту. З лицьового боку, якщо береться параметр id, ризик у тому, що зловмисник може маніпулювати запитом, відправляти з допомогою SQL-команди і знищити всю базу даних. Тому, щоб уникнути цього, потрібно не надсилати параметр наосліп, а перевіряти його на основі значень, наданих користувачем.

Атаки XSS або Cross-Site Scripting - це те саме, що і SQL Injection. Різниця в тому, що замість відправки SQL зловмисник виконує JavaScript. Тут також потрібна валідація введення від користувача для запобігання атаці.

• Сильна автентифікація

Найбільш поширеною причиною вразливості є слабкий чи неповний механізм автентифікації. Розробники роблять помилку, думаючи, що наявності аутентифікації достатньо, але насправді, якщо аутентифікація непослідовна чи слабка, її легко обійти. Немає нічого страшного, якщо у вас є рідне рішення автентифікації Node.js за умови дотримання кількох правил. Перше – під час створення паролів не використовувати вбудовану криптобібліотеку Node.js.

Також слід обмежити кількість невдалих спроб входу до системи та видавати спеціальне повідомлення, наприклад, "невірні облікові дані". По-друге, дуже важливо реалізувати аутентифікацію 2FA.

• Уникайте виявлення занадто великої кількості помилок

Декілька моментів, які слід враховувати при обробці помилок. Не слід повідомляти користувачеві про всі подробиці помилки. Він може містити повні деталі, такі як шлях або бібліотека або секрети, що використовується. Це не дозволить зловмисникам безперервно посилати шкідливі запити доти, доки програма не вийде з ладу. Щоб уникнути повені програми Nodes.js шкідливими запитами, не слід безпосередньо виводити її в інтернет. Використання балансувальника навантаження, хмарного брандмауера або шлюзу в шрифті Node.js допомагає обмежити швидкість DOS-атак за один крок до того, як зловмисник вразить програму.

• Запуск автоматичного сканування вразливостей

Система node.js має безліч модулів та бібліотек різних типів, які можна встановити. Їх можна використовувати у багатьох проектах, але це також створює проблему безпеки, коли код написаний кимось іншим, і немає впевненості, що він на 100% безпечний. Щоб бути впевненим у його безпеці, часте сканування допомагає перевірити будь-яку вразливість.

• Запобігання витоку даних

Як уже говорилося, не варто довіряти зовнішньому інтерфейсу та перевіряти, які дані він надсилає. Можна відправляти всі дані на front-end, але фільтрувати їх видимість, але для зловмисника не важко отримати приховані дані з back-end.

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

Щоб цього не сталося, необхідно витягувати з бази даних лише ім'я та прізвище. Це вимагає більше зусиль, але воно того варте.

• Налаштування протоколювання та моніторингу

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

• Використання лінтерів безпеки

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

Щоразу, коли людина використовує небезпечний код, лінтери безпеки повідомлятимуть йому про це.

Уникайте запускати Node.js від імені root

У світі мікросервісів та Docker люди схильні забувати, як виконується Node.js – запуск Docker-контейнера та думка, що він ізольований від хост-машини і, отже, безпека не відповідає дійсності. Використання Docker не означає, що можна запускати Node.js від імені root. Це поєднує можливість запуску будь-якого коду JavaScript через XSS.

Висновок

Безпека веб-додатків має велике значення. Тому часто буває так, що щільний графік та стислий термін не дозволяють нам правильно виконати роботу на кожному етапі. Саме тому безпека повинна розглядатися кожному етапі життєвого циклу розробки програмного забезпечення, від задуму до виробництва.