Кэт Чилтон, старший интерфейсный разработчик, Adyen

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

NodeJS (Node), хотя и полон противоречий, зарекомендовал себя как важный фундамент современной сети. В этом посте мы рассмотрим, почему мы приняли Node, некоторые проблемы безопасности, связанные с ним, и как мы создали инструмент автоматической проверки зависимостей для защиты Node в Adyen.

Почему Node?

Node существует уже около десяти лет и является ядром современной интерфейсной разработки. В диспетчере пакетов Node (NPM) доступно более 350 000 библиотек, что в два раза больше, чем у следующего по величине репозитория пакетов.

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

1. Согласно опросу разработчиков StackOverflow 2017 года, 72% разработчиков используют JavaScript, и как минимум половина из них использует Node. Все больше разработчиков выбирают специализацию на Node, а не на других языках. Если Адиен не использует Node, мы оттолкнем огромное количество разработчиков и упустим отличных сотрудников. Нам нужно принять Node, чтобы идти в ногу с нашим быстрым ростом.

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

Node имеет решающее значение для нашего перехода на современный, основной интерфейсный фреймворк, такой как VueJS.

Проблема: NPM небезопасен

Однако, несмотря на все свои преимущества, немногие инструменты разработчика вызывают столько же споров, как Node. Разработчики обсуждают - и даже жарят друг друга - о преимуществах и недостатках этой мощной технологии. Что же такого в Node, что вызывает такой жар, и почему кажется, что мы не можем обсуждать это, не разжигая войну пламени?

Жалобы на Node варьируются от критики того, как он написан, например, обработки ошибок, до способа выполнения кода, такого как неэффективность ЦП. Хотя эти темы спорны, большинство разработчиков согласятся, что Node Package Manager (NPM) потенциально может представлять угрозу безопасности.

Райан Даль, создатель Node, сожалеет:

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

На второстепенном уровне в package.json нет принудительного единообразия. Есть заполнители для лицензии, ссылки на исходный код и т. Д., Но отсутствие принудительного исполнения очень затрудняет автоматизацию проверки. Другая проблема заключается в том, что исходный код не виден пользователю с веб-сайта NPM. Опять же, в package.json есть заполнитель для ссылки на исходный код, но этот код не обязательно должен соответствовать коду, размещенному на Node.

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

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

Исходный пакет left-pad - отличный пример пакета, который кажется безопасным, но может быть вредоносным. Left-pad - это служебный пакет, который расширяет левую часть струн; ничем не примечательная зависимость, используемая тысячами проектов. Его автор не опубликовал и, как следствие, сломал тысячи проектов, на которых он был основан. В качестве исправления NPM обновили свою политику отмены публикации пакетов и приняли меры для предотвращения сквоттинга имен пакетов. Тем не менее, этот крайний случай подчеркивает проблемы с NPM. На самом деле никто не знает, что происходит глубоко в дереве зависимостей.

На самом деле никто не знает, что происходит глубоко в дереве зависимостей.

Поиск решения

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

Автоматическая проверка зависимостей стала предпосылкой для использования Node в Adyen. Сначала исследования привели к появлению на рынке некоторых других инструментов, которые смело заявляли о возможности «безопасно запускать весь код». Их формулы были не очень ясными, и это были неизвестные сущности с меньшими хранилищами. Что наиболее важно, это не были решения с открытым исходным кодом, и нам нужен был инструмент, в котором мы могли бы контролировать код.

Стало ясно, что обеспечение безопасности Node в Adyen - это самостоятельный проект. Мы собрали небольшую команду и начали создавать Skantek, частный пакет узлов и вспомогательную инфраструктуру.

Как работает Скантек

Skantek - это программа Node для сканирования подозрительных пакетов с использованием таких показателей, как:

  • Наличие, расположение и длина файла readme.
  • Наличие ссылки на исходный код в GitHub.
  • Появление в Snyk или других базах данных уязвимостей JavaScript.
  • Наличие лицензии.

Основываясь на этих факторах, Skantek определяет уровень риска упаковки и необходимость проверки вручную. Если пакет одобрен, он добавляется в частный реестр NPM.

Как это определяет риск

Skantek получает метаданные пакета из NPM и использует библиотеку для разрешения всех зависимостей в дереве. Он проходит по дереву и сканирует каждый пакет, присваивая рейтинг риска. Если все это пройдет, он сканирует родительский пакет. Затем он извлекает все связанные пакеты и публикует их в частном реестре.

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

Skantek регулярно выполняет повторное сканирование пакетов и включает задержку для обновления нашего внутреннего реестра NPM обновлениями. Это делает эксплойты нулевого дня гораздо более маловероятными.

Если разработчик находит новый пакет, который он считает полезным, мы рекомендуем им изучить этот пакет. Они могут вызвать Skantek, чтобы получить полный отчет о рассматриваемом пакете. Как только они поймут уровень риска, мы рекомендуем им поговорить с другими разработчиками. Это помогает определить, публиковали ли мы аналогичные пакеты или же этот пакет нужен другим членам команды. Затем они представляют свои выводы нашей группе утверждения НПМ (в настоящее время формируется). Если команда одобрит пакет, Skantek публикует библиотеку в частном репозитории Adyen.

Результаты и извлеченные уроки

Проведя это исследование, мы получили более четкое представление о рисках, связанных с использованием NPM. Мы хотели быть проактивными и реалистичными в отношении опасностей Node и предпринять шаги для его защиты, вместо того, чтобы ждать, пока что-то пойдет не так. Skantek предупреждает разработчиков о проблеме и одновременно решает ее.

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

Многие разработчики не указывают свою лицензию. Отсутствие возможности найти лицензию программным способом - более распространенная проблема, чем отклонение запрошенного пакета. Skantek упрощает проверку лицензий, но отсутствие единообразия в структуре NPM означает, что мы выполняем проверки вручную. Например, есть много авторов, которые поместили свою лицензию в файл readme, но не в свойство лицензии package.json.

Деревья зависимостей действительно глубоки. Самый простой способ снизить риск зависимостей NPM - использовать меньше библиотек. При выборе новой библиотеки для использования в проекте мы рекомендуем нашим разработчикам выбирать пакет с наименьшим количеством зависимостей. Меньшее количество зависимостей упрощает проверку кода и гарантирует, что в нем нет ничего вредоносного.

Следующие шаги

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

На данном этапе существует основной проект, работающий как пилот для Node. Наша группа безопасности одобрила первую версию Skantek, и мы опубликовали первоначальную версию нашего внутреннего реестра. Теперь разработчики могут работать с локальным экземпляром среды выполнения Node, и мы готовы развернуть наши первые интерфейсы на базе NodeJS.

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

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

В ближайшем будущем мы оптимизируем рекурсию дерева зависимостей Skantek и добавим надежное тестирование и ведение журнала. Инструмент также должен иметь возможность сканировать более одного пакета за раз (цель, которая станет более реалистичной, когда начнется оптимизация рекурсии). Skantek также должен уметь самостоятельно находить опасный код. В настоящее время он сканирует общую структуру упаковки на предмет нарушений. Затем он выполняет тест Snyk, чтобы проверить свою базу данных на наличие известных уязвимостей. Будущие версии Skantek должны сканировать на основе общих шаблонов, считывая код и выявляя слабые места.

Заключение

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

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

Техническая карьера в Adyen

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

Информационный бюллетень для разработчиков

Будьте в курсе новых сообщений в блогах и других новостей для разработчиков. "Подпишитесь сейчас".