25 уязвимостей, на которые следует обратить внимание в приложениях Node JS: обход каталогов, загрязнение прототипов, XSSI и многое другое…

Защита приложений — не самая простая задача. Приложение состоит из множества компонентов: логика на стороне сервера, логика на стороне клиента, хранилище данных, транспортировка данных, API и многое другое. Со всеми этими компонентами для защиты создание безопасного приложения может показаться действительно сложной задачей.

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

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

Сегодня давайте рассмотрим 25 наиболее распространенных уязвимостей, затрагивающих приложения Node.js, и способы их обнаружения и предотвращения. Уязвимости, о которых я расскажу в этом посте:

Загрязнение прототипа

JavaScript — уникальный язык со многими особенностями. Одной из этих характеристик, которая отличает его от других основных языков, является способ создания объектов в Javascript. Объекты в Javascript не создаются из классов, а наследуют свои свойства от существующего объекта или «прототипа».

С точки зрения безопасности это означает, что если злоумышленник может изменить объект-прототип и его свойства, объект-прототип может затем повлиять на свойства всех объектов, созданных на основе этого прототипа. Это может привести к чему угодно: от атак с использованием межсайтовых сценариев (XSS) в браузере до атак с удаленным выполнением кода (RCE) в приложениях Node.js. Узнайте, как работают эти атаки и как их предотвратить здесь.

Верни меня обратно наверх.

Включение межсайтового скрипта

Атаки с включением межсайтовых сценариев также называются XSSI. Эти атаки происходят, когда вредоносный сайт включает Javascript с сайта-жертвы для извлечения конфиденциальной информации из скрипта.

Политика единого источника (SOP) обычно контролирует доступ к данным из разных источников. Но SOP не ограничивает код javascript, и HTML-тегу ‹script› разрешено загружать код javascript из любого источника. Это чрезвычайно удобная функция, которая позволяет повторно использовать файлы JavaScript в разных доменах. Но эта функция также представляет угрозу безопасности: злоумышленники могут украсть данные, записанные в файлах JavaScript, загрузив файлы JS своих жертв.

Например, представьте, что веб-сайт хранит и передает конфиденциальные данные для вошедших в систему пользователей через файлы Javascript. Если пользователь посещает вредоносный сайт в том же браузере, вредоносный сайт может импортировать этот файл JavaScript и получить доступ к конфиденциальной информации, связанной с сеансом пользователя, благодаря файлам cookie пользователя, хранящимся в браузере. Посмотрите пример этой уязвимости и узнайте, как их предотвратить здесь.

Верни меня обратно наверх.

Небезопасные настройки Puppeteer

Небезопасные настройки Puppeteer — еще одна проблема для приложений Node. Puppeteer — это библиотека Node, которая позволяет приложениям программно управлять безголовой сборкой Chrome или Chromium. Puppeteer помогает автоматизировать пользовательское тестирование, имитируя действия, которые пользователи могут выполнять в браузере. Например, вы можете автоматизировать тестирование отправки форм, ввода с клавиатуры и многих других действий пользователя.

Важно поместить в песочницу браузер, который запускает Puppeteer, так как безголовый браузер может иметь доступ к диску или внутренней сети. Как это сделать читайте в этом посте.

Верни меня обратно наверх.

Неправильная конфигурация безопасности

Небезопасные настройки Puppeteer, по сути, являются типом неправильной настройки безопасности. Существует много других типов неправильных настроек безопасности, которые могут поставить под угрозу безопасность приложений Node. Они могут включать в себя использование учетных данных по умолчанию, использование неправильных заголовков безопасности HTTP, раскрытие конфиденциальной системной информации через сообщения об ошибках или отключение встроенных мер безопасности. Узнайте о некоторых из наиболее распространенных неправильных настроек безопасности в приложениях Node здесь.

Верни меня обратно наверх.

Удаленное выполнение кода

Уязвимости удаленного выполнения кода, или RCE, представляют собой класс уязвимостей, которые возникают, когда злоумышленники могут выполнить свой код на вашем компьютере. Один из способов, которым это может произойти, — уязвимости внедрения кода. Они представляют собой тип удаленного выполнения кода, который происходит, когда пользовательский ввод непосредственно объединяется с исполняемым кодом. Приложение не может различить, где находится пользовательский ввод и где находится исполняемый код, поэтому приложение выполняет пользовательский ввод как код. Злоумышленник сможет выполнить произвольный код Javascript через приложение.

Один из самых простых способов предотвратить внедрение кода — реализовать надежную проверку ввода в виде белого списка. О том, как реализовать белые списки и каких методов Javascript следует избегать, читайте здесь.

Верни меня обратно наверх.

Инъекция

Внедрение кода также относится к типу внедрения. Внедрение происходит, когда приложение не может правильно отличить ненадежные пользовательские данные от кода. Когда внедрение происходит в коде Javascript, это приводит к внедрению кода. Но уязвимости инъекций проявляются и по-другому.

Внедрение SQL

Например, при атаке с внедрением SQL злоумышленник вводит данные для управления командами SQL. Когда приложение не проверяет ввод пользователя должным образом, злоумышленники могут вставлять специальные символы языка SQL, чтобы нарушить логику запроса, тем самым выполняя произвольный код SQL. Узнайте больше о том, как работают эти атаки SQL-инъекций здесь.

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

Верни меня обратно наверх.

Вставка журнала

Вероятно, вы ведете системный журнал для отслеживания вредоносных действий, происходящих в вашей сети. Но задумывались ли вы когда-нибудь о том, что ваши записи в лог-файле могут вам лгать? Файлы журнала, как и другие системные файлы, могут быть изменены злоумышленниками. Злоумышленники часто изменяют файлы журналов, чтобы замести следы во время атаки. Внедрение журналов — это один из способов, с помощью которого злоумышленники могут изменить ваши файлы журналов. Это происходит, когда злоумышленник обманом заставляет приложение записывать поддельные записи в ваши файлы журналов.

Внедрение журнала часто происходит, когда приложение не очищает символы новой строки «\n» во входных данных, записываемых в журналы. Злоумышленники могут использовать символ новой строки для вставки новых записей в журналы приложений. Другой способ, которым злоумышленники могут использовать пользовательский ввод в журналах, заключается в том, что они могут внедрить вредоносный HTML в записи журнала, чтобы попытаться вызвать XSS в браузере администратора, который просматривает журналы.

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

Верни меня обратно наверх.

Вставка почты

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

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

Верни меня обратно наверх.

Внедрение шаблона

Механизмы шаблонов — это тип программного обеспечения, используемого для определения внешнего вида веб-страницы. Эти веб-шаблоны, написанные на таких языках шаблонов, как Jinja, предоставляют разработчикам способ указать, как должна отображаться страница, путем объединения данных приложения с веб-шаблонами. Вместе веб-шаблоны и механизмы шаблонов позволяют разработчикам отделять логику серверного приложения от клиентского кода представления во время веб-разработки.

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

Верни меня обратно наверх.

Внедрение регулярных выражений

Регулярное выражение или регулярное выражение — это специальная строка, описывающая шаблон поиска в тексте. Иногда приложения позволяют пользователям предоставлять серверу собственные шаблоны регулярных выражений для выполнения или создания регулярных выражений с пользовательским вводом. Атака с внедрением регулярных выражений или атака типа отказ в обслуживании (ReDoS) с использованием регулярных выражений происходит, когда злоумышленник предоставляет механизму регулярных выражений шаблон, для оценки которого требуется много времени. Примеры этих паттернов вы можете найти в моем посте здесь.

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

Верни меня обратно наверх.

Внедрение заголовка

Внедрение заголовков происходит, когда заголовки ответов HTTP динамически создаются из ненадежных входных данных. В зависимости от того, на какой заголовок ответа влияет уязвимость, внедрение заголовка может привести к межсайтовому скриптингу, открытому перенаправлению и фиксации сеанса.

Например, если заголовком Location можно управлять с помощью параметра URL, злоумышленники могут вызвать открытое перенаправление, указав в параметре свой вредоносный сайт. Злоумышленники могут даже выполнять вредоносные сценарии в браузере жертвы или заставлять жертв загружать вредоносное ПО, отправляя жертве полностью контролируемые HTTP-ответы посредством внедрения заголовка. Подробнее о том, как работают эти атаки здесь.

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

Верни меня обратно наверх.

Внедрение сеанса

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

Перехват сеанса означает, что злоумышленник крадет чужой файл cookie сеанса и использует его как свой собственный. Злоумышленники часто крадут файлы cookie сеанса с помощью атак XSS или MITM (man-in-the-middle). Фальсификация сеанса означает, что злоумышленники могут изменить свои файлы cookie сеанса, чтобы изменить то, как сервер интерпретирует их личность. Это происходит, когда состояние сеанса передается в файле cookie, а файл cookie неправильно подписан или зашифрован. Наконец, злоумышленники могут подделывать сеансы, когда идентификаторы сеансов предсказуемы. Если это так, злоумышленники могут подделать действительные файлы cookie сеанса и войти в систему как кто-то другой. Для предотвращения этих ловушек управления сеансом требуется многоуровневая защита.

Верни меня обратно наверх.

Отравление заголовка хоста

Веб-серверы часто размещают несколько разных веб-сайтов на одном и том же IP-адресе. После того, как HTTP-запрос поступает на IP-адрес, сервер перенаправляет запрос на хост, указанный в заголовке Host. Хотя заголовки Host обычно устанавливаются браузером пользователя, они по-прежнему вводятся пользователем, и поэтому им нельзя доверять.

Если веб-приложение не проверяет заголовок узла перед тем, как использовать его для создания адресов, злоумышленники могут запустить ряд атак, таких как XSS, подделка запросов на стороне сервера(SSRF) и атаки с отравлением веб-кэша через заголовок узла. Например, если приложение использует заголовок узла для определения местоположения сценариев, злоумышленник может отправить вредоносный заголовок узла, чтобы приложение выполнило вредоносный сценарий:

scriptURL = "https://" + properties.getProperty("host") + "/script.js";

Узнайте больше о том, как работают атаки на заголовок хоста здесь.

Верни меня обратно наверх.

Утечки конфиденциальных данных

Утечка конфиденциальных данных происходит, когда приложение не может должным образом защитить конфиденциальную информацию, предоставляя пользователям доступ к информации, которую они не должны были им предоставлять. Эта конфиденциальная информация может включать в себя технические детали, помогающие атаке, такие как номера версий программного обеспечения, внутренние IP-адреса, конфиденциальные имена файлов и пути к файлам. Он также может включать исходный код, который позволяет злоумышленникам проводить проверку исходного кода приложения. Иногда приложение пропускает личную информацию пользователей, такую ​​как номера их банковских счетов, адреса электронной почты и почтовые адреса.

Некоторые распространенные способы, с помощью которых приложение может утечь конфиденциальные технические данные, включают описательные заголовки ответов, описательные сообщения об ошибках с трассировкой стека или сообщения об ошибках базы данных, открытые списки каталогов в файловой системе системы и раскрытие комментариев в HTML и файлах шаблонов. О том, как предотвратить утечку данных в приложениях Node, вы можете узнать здесь.

Верни меня обратно наверх.

Обход аутентификации

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

Верни меня обратно наверх.

Неправильный контроль доступа

Проблемы обхода аутентификации, по сути, представляют собой неправильный контроль доступа. Неправильный контроль доступа возникает каждый раз, когда контроль доступа в приложении реализован неправильно и может быть обойден злоумышленником. Однако управление доступом включает в себя больше, чем аутентификацию. В то время как аутентификация просит пользователя подтвердить свою личность: «Кто вы?», авторизация спрашивает приложение: «Что разрешено делать этому пользователю?». Надлежащая аутентификация и авторизация вместе гарантируют, что пользователи не смогут получить доступ к функциям за пределами их разрешений.

Существует несколько способов настройки авторизации для пользователей: управление доступом на основе ролей, управление доступом на основе владения, списки контроля доступа и многое другое. Хороший пост для справки по реализации контроля доступа — здесь.

Верни меня обратно наверх.

Обход каталога

Уязвимости обхода каталога — еще один тип ненадлежащего контроля доступа. Они происходят, когда злоумышленники могут просматривать, изменять или запускать файлы, к которым у них не должно быть доступа, манипулируя путями к файлам в полях ввода пользователя. Этот процесс включает в себя манипулирование переменными пути к файлу, которые приложение использует для ссылки на файлы, добавляя символы ../ или другие специальные символы к пути к файлу. Последовательность ../ относится к родительскому каталогу текущего каталога в системах Unix, поэтому, добавляя его к пути к файлу, вы часто можете получить доступ к системным файлам за пределами веб-каталога.

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

Верни меня обратно наверх.

Произвольные записи файлов

Уязвимости записи произвольных файлов работают аналогично обходу каталогов. Если приложение записывает файлы на основной компьютер и определяет имя выходного файла с помощью пользовательского ввода, злоумышленники могут создавать произвольные файлы по любому пути или перезаписывать существующие системные файлы. Злоумышленники могут изменить важные системные файлы, такие как файлы паролей или файлы журналов, или добавить свои собственные исполняемые файлы в каталоги сценариев.

Лучший способ снизить этот риск — не создавать имена файлов на основе каких-либо данных, вводимых пользователем, включая информацию о сеансе, данные HTTP или что-либо, что контролируется пользователем. Вы должны контролировать имя файла, путь и расширение для каждого созданного файла. Например, вы можете генерировать случайное буквенно-цифровое имя файла каждый раз, когда пользователю нужно создать уникальный файл. Вы также можете удалить введенные пользователем специальные символы перед созданием файла. Узнайте об этих техниках в этом посте.

Верни меня обратно наверх.

Атаки отказа в обслуживании

Атаки типа «отказ в обслуживании» или DoS-атаки нарушают работу целевой машины, так что законные пользователи не могут получить доступ к ее службам. Злоумышленники могут запускать DoS-атаки, истощая все ресурсы сервера, вызывая сбои процессов или выполняя одновременно слишком много длительных HTTP-запросов.

От атак типа отказ в обслуживании трудно защититься. Но есть способы минимизировать риск, максимально усложнив задачу для злоумышленников. Например, вы можете развернуть брандмауэр, обеспечивающий защиту от DoS-атак, и предотвратить DoS-атаки на основе логики, установив ограничения на размер файлов и запретив определенные типы файлов. Более подробные шаги по предотвращению атак типа отказ в обслуживании вы можете найти здесь.

Верни меня обратно наверх.

Уязвимости шифрования

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

Некоторые распространенные ошибки, которые допускают разработчики при реализации шифрования на сайте:

  • Использование слабых алгоритмов
  • Использование неправильного алгоритма для цели
  • Создание пользовательских алгоритмов
  • Генерация слабых случайных чисел
  • Принятие кодировки за шифрование

Руководство по безопасности шифрования можно найти здесь.

Верни меня обратно наверх.

Массовое назначение

Массовое присвоение относится к практике одновременного присвоения значений нескольким переменным или свойствам объекта. Уязвимости массового назначения возникают, когда приложение автоматически назначает пользовательский ввод нескольким программным переменным или объектам. Это функция многих платформ приложений, предназначенная для упрощения разработки приложений.

Однако эта функция иногда позволяет злоумышленникам перезаписывать, изменять или создавать новые программные переменные или свойства объекта по своему желанию. Это может привести к обходу аутентификации и манипулированию логикой программы. Чтобы предотвратить массовое назначение, вы можете отключить функцию массового назначения в используемой вами структуре или использовать белый список, чтобы разрешить назначение только для определенных свойств или переменных.

Верни меня обратно наверх.

Открытые перенаправления

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

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

Чтобы предотвратить открытые перенаправления, вам необходимо убедиться, что приложение не перенаправляет пользователей в вредоносные места. Например, вы можете полностью запретить внешние перенаправления, проверив URL-адреса перенаправления. Есть много других способов предотвращения открытых перенаправлений, таких как проверка реферера запросов или использование индексов страниц для перенаправлений. Но поскольку проверить URL-адреса сложно, открытые перенаправления остаются распространенной проблемой в современных веб-приложениях.

Верни меня обратно наверх.

Подделка межсайтовых запросов

Подделка межсайтовых запросов (CSRF) — это техника на стороне клиента, используемая для атаки на других пользователей веб-приложения. Используя CSRF, злоумышленники могут отправлять HTTP-запросы, которые якобы исходят от жертвы, выполняя нежелательные действия от имени жертвы. Например, злоумышленник может изменить ваш пароль или перевести деньги с вашего банковского счета без вашего разрешения.

В отличие от открытых перенаправлений, существует надежный способ предотвращения CSRF: использование комбинации токенов CSRF и файлов cookie SameSite и отказ от использования GET-запросов для действий по изменению состояния.

Верни меня обратно наверх.

Подделка запросов на стороне сервера

SSRF или Подделка запросов на стороне сервера — это уязвимость, которая возникает, когда злоумышленник может отправлять запросы от имени сервера. Он позволяет злоумышленникам подделывать сигнатуры запросов уязвимого сервера, тем самым занимая привилегированное положение в сети, обходить средства управления брандмауэром и получать доступ к внутренним службам.

В зависимости от разрешений, предоставленных уязвимому серверу, злоумышленник может читать конфиденциальные файлы, выполнять внутренние вызовы API и получать доступ к внутренним службам, таким как скрытые панели администратора. Самый простой способ предотвратить уязвимости SSRF — никогда не делать исходящие запросы на основе пользовательского ввода. Но если вам нужно делать исходящие запросы на основе пользовательского ввода, вам необходимо проверить эти адреса перед инициированием запроса.

Верни меня обратно наверх.

Нарушение границ доверия

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

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

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

Верни меня обратно наверх.

Какие еще концепции безопасности вы хотели бы узнать? Я хотел бы знать. Не стесняйтесь общаться в Твиттере @vickieli7.

Теперь, когда вы знаете, как исправить эти уязвимости, защитите свое приложение Node.js, отсканировав эти уязвимости! ShiftLeft CORE (https://www.shiftleft.io/shiftleft-core/) может найти эти уязвимости в вашем приложении, показать вам, как исправить эти ошибки, и защитить вас от проблем с безопасностью Node.js.