Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>При наличии проблем с безопасностью может произойти утечка пользовательских данных, что приведёт к соответствующим репутационным и финансовым потерям. В этой статье мы поговорим о правилах безопасного кода в контексте Node.js-разработки.</p>

2 <h2>Правило № 1: не используйте eval</h2>

3 <p>Известная функция eval() может сделать приложение уязвимым для инъекций произвольного кода. Именно поэтому рекомендуется её не использовать. Если же без этого не обойтись, никогда не стоит передавать чистый пользовательский ввод в eval().</p>

4 <h2>Правило № 2: пользуйтесь режимом "use strict"</h2>

5 <p>С режимом use strict вы можете использовать строгий "вариант" JS, что позволяет находить ряд скрытых ошибок и отображать их.</p>

6 'use strict' delete Object.prototype // ошибка ввода var obj = { a: 1, a: 2 } // ошибка синтаксиса<h2>Правило № 3: обрабатывать ошибки надо аккуратно</h2>

7 <p>При обработке исключений возможны утечки важной информации из вашего приложения. Речь идёт, например, об информации о внутренней структуре, допустим, X-Powered-By:Express.</p>

8 <p>Да, сами по себе данные трассировки уязвимостью не являются, но часто они могут раскрывать другую информацию, которая интересует хакеров. Таким образом, предоставление отладочной информации в качестве результата, генерируемого в случае ошибки - плохая практика. Поэтому всегда записывайте информацию в логи и скрывайте от пользователя.</p>

9 <h2>Правило № 4: не забывайте про статический анализ кода</h2>

10 <p>Статический анализ кода приложения поможет вам обнаружить много ошибок. Используйте для этого ESLint совместно со Standard code style.</p>

11 <h2>Правило № 5: не запускайте процессы с root-правами</h2>

12 <p>Увы, но очень часто разработчики запускают приложения с рут-правами (например, когда хотят использовать порты 443 и 80). И это тоже плохая практика. Если возникнет ошибка, процесс может "положить" всю систему, ведь открыт доступ ко всем возможностям.</p>

13 <p>Чтобы так не делать, настройте для перенаправления запроса HTTP-сервер либо прокси. Пусть это будет nginx либо Apache. Дополнительная информация есть в<a>этой статье</a>.</p>

14 <h2>Правило № 6: настраиваем обязательные HTTP-заголовки</h2>

15 <p>Есть ряд HTTP-заголовков, которые относятся к безопасности. И их надо установить: •<strong>Strict-Transport-Security</strong>- делает обязательным безопасные соединения с сервером (HTTP через SSL/TLS); •<strong>X-Frame-Options</strong>- для защиты от кликджекинга; •<strong>X-XSS-Protection</strong>- содержит фильтр межсайтового скриптинга (XSS), который встроен в большинство веб-браузеров; •<strong>X-Content-Type-Options</strong>- для предотвращения MIME-сниффинга ответа без декларированного Content-Type; •<strong>Content-Security-Policy</strong>- для защиты от широкого спектра атак, в том числе XSS и прочих межсайтовых инъекций.</p>

16 <p>Сделать всё это в Node.js просто - достаточно задействовать модуль<strong>Helmet</strong>:</p>

17 var express = require('express') var helmet = require('helmet') var app = express() app.use(helmet())<h2>Правило № 7: управляйте сессиями корректно</h2>

18 <p>Флаги, приведённые ниже, следует установить для всех куки: •<strong>secure</strong>- браузер получает сообщение, что надо отправлять куки лишь в том случае, если запрос отправляется посредством HTTPS; •<strong>HttpOnly</strong>- помогает предотвращать атаки типа XSS за счё того, что не даёт доступ к куки через JS.</p>

19 <h2>Правило № 8: настраиваем ограничения для куки</h2>

20 <p>Если работаете с куки, используйте также и следующие флаги: •<strong>domain</strong>- для сравнения домена, который записан в куки, с домена в URL. Если домен совпадает либо это субдомен, проверяется атрибут path; •<strong>path</strong>- с помощью этого атрибута в дополнение к domain для куки можно задать URL. Если path и domain совпадают, куки можно считать валидными, поэтому они отправляются в запросе; •<strong>expires</strong>- чтобы установить срок действия куки.</p>

21 <p>Кстати, с помощью пакета<a>cookies</a>вы можете без проблем создавать куки в Node.js. Однако эта фича довольно низкоуровневая, поэтому можно просто воспользоваться оболочкой типа<a>cookie-session</a>.</p>

22 var cookieSession = require('cookie-session') var express = require('express') var app = express() app.use(cookieSession({ name: 'session', keys: [ process.env.COOKIE_KEY1, process.env.COOKIE_KEY2 ] })) app.use(function (req, res, next) { var n = req.session.views || 0 req.session.views = n++ res.end(n + ' views') }) app.listen(3000)<h2>Правило № 9: ищем уязвимости с Retire.js</h2>

23 <p>Существует инструмент Retire.js, основная цель которого - оказать помощь в обнаружении уязвимых версии модулей. Устанавливается он предельно просто:</p>

24 <p>Далее применение команды retire позволит вам обнаружить уязвимости в директории node_modules.</p>

25 <h2>Правило № 10: аудит модулей с Node Security Platform CLI</h2>

26 <p>Используя этот инструмент, вы получаете возможность выполнять аудит package.json либо npm-shrinkwrap.json, выполняя сравнение со списком уязвимых модулей NSP API.</p>

27 npm install nsp --global # Из директории вашего проекта nsp check<p><em>Источник - "<a>Node Hero - Node.js Security Tutorial</a>".</em></p>