Aleksandr Kitov

"Польза" от уязвимостей

2025-11-26T12:49:06.878Z

Я вообще не очень люблю ныть, когда у меня нет какого-то конкретного предложения, как починить причину нытья, но тут что-то уже клинит.

Безопасность - это важно. Важно, чтобы все писали свой код так, чтобы его нельзя было просто взломать. Важно, чтобы мы не писали в своем коде NODE_TLS_REJECT_UNAUTHORIZED. Важно, чтобы библиотеки, которые обрабатывают http-запросы, не давали возможности сделать запрос типа GET ../../../etc/passwd.

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

Рандомные примеры критических уязвимостей за последнее время:

Уязвимость в fast-redact

CVE-2025-57319 - жуткая (high severity!) уязвимость в библиотеке, которая предназначена для маскирования данных в объектах. Часто используется в системах логирования. В чем же там суть? Какой-то секьюрити-ресёрчер обнаружил prototype pollution уязвимость в одном из методов библиотеки.

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

Вот пример из самой уязвимости:

// Create a custom object
const customObject = {};

// Craft the instructions to inject a property into Object.prototype
const instructions = [
  {
    target: customObject,
    path: ["polluted", "prototype", "constructor"],
    value: true
  }
];

// Call the vulnerable function with the crafted instructions
require("fast-redact/lib/modifiers").nestedRestore(instructions);

// Verify the exploit
console.log({}.polluted !== undefined ? '[POLLUTION_TRIGGERED]':'');

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

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

const fastRedact = require("fast-redact");

const customObject = {};

const redact = fastRedact({
  paths: ['polluted.prototype.constructor'],
});

console.log({}.polluted !== undefined ? '[POLLUTION_TRIGGERED]':''); // выведет ''

Да, сейчас уязвимость перевели в статус disputed. Но какой ценой? Люди уже успели наделать бесчисленное количество issue, форков, кто-то (даже поняв, что проблемы реально нет!) сделал полностью свою реализацию библиотеки.

Принесло ли это пользу человечеству? Что-то я сомневаюсь.

Уязвимость в докер-образах

Наши стандартные докер-образы основаны на node:alpine. В них почти нет лишних пакетов, и они почти совсем пустые - только код приложения и рантайм, чтобы его запустить. Да, иногда даже в совсем базовых пакетах (типа zlib или tzdata) обнаруживаются уязвимости, но это происходит не так уж и часто. Но вот недавно в кучу чатов начали стучаться. "Аларм!", "Все сломалось!", "Мы в опасности!". Сканер нашел в базовых образах критические уязвимости с высоким приоритетом, а именно CVE-2025-64756. Откуда? Из пакета glob. Откуда у нас пакет glob? Из npm. Он является базовой частью node:alpine.

А в чем там вообще уязвимость?

Оказывается, что уязвимость срабатывает только если использовать cli-интерфейс glob, запускать его с флагом --cmd. В таком случае, если злоумышленник создаст файл с именем вида $(touch pwned) и он попадет под glob - то код из имени файла успешно выполнится.

Что ж, действительно уязвимость... Но только если вы используете этот самый пакет glob как cli-утилиту. Ну и если кто-то уже понаписал в вашу файловую систему файлов с командами в их именах (а как он их туда напихал? Он уже вас взломал?)

Но у нас эта библиотека - зависимость зависимости. Никто никогда его не запускал и запускать не будет. Понятное дело, что правильным решением с точки зрения мейнтейнеров glob было бы выделить это все в отдельный пакет (что они и сделали, теперь есть отдельный glob-bin, в котором и уязвимость заодно починили). Да и вообще - виной всему любовь js-разработчиков к пакетам, в которых лежат еще пакеты, а в них - еще пакеты...

Но вот реально, являлась ли эта уязвимость критичной в нашем конкретном случае? На мой взгляд - нет.

Вместо вывода

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

Как я в самом начале и сказал - у меня нет какого-то решения. Уязвимости надо искать. Их надо исправлять. Но ощущение, что что-то в этом процессе фундаментально неправильно - не покидает меня.

Boolean - легкий способ сделать плохой API

2024-09-07T07:01:47.610Z

Что? Почему? Это же прекрасный тип данных - всего два значения, которые так легко использовать...

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

function buildApp(entryPoint: string): Promise<void>;

Вроде бы всё просто и понятно. Чуть позже вы понимаете, что части ваших пользователей хочется немного настраивать вашу сборку - они хотят использовать ts-loader вместо babel-loader для обработки ts файлов.

Что-ж, доработаем наш API!

function buildApp(
  entryPoint: string,
  useTsLoader: boolean = false,
): Promise<void>;

При вызове это выглядит как то так:

await buildApp('./my-entry.tsx', true);

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

type BuildAppParams = {
  entryPoint: string;
  useTsLoader?: boolean;
}
function buildApp({
  entryPoint,
  useTsLoader = false,
}: BuildAppParams): Promise<void>;

// вызов
buildApp({
  entryPoint: './my-entry.tsx',
  useTsLoader: true,
});

Красота? Вроде бы все понятно?

Нет. А что если мы напишем useTsLoader: false? Что это вообще будет означать? Что будет использоваться вместо него? Конечно можно прочитать документацию и понять какое будет поведение..

А что если через какое то время мы захотим добавить еще немного гибкости, и давать возможность использовать например swc или esbuild?

type BuildAppParams = {
  entryPoint: string;
  useTsLoader?: boolean;
  useSwcLoader?: boolean;
};
function buildApp(options: BuildAppParams): Promise<void>;

Теперь вопрос - что будет происходить когда и useTsLoader, и useSwcLoader выставлены в true? Наверное можно указать в документации что использование параметров одновременно - некорректно, или даже попробовать починить это на уровне типов:

type BuildAppPrams = {
  entryPoint: string;
} & ({
  useTsLoader: true;
  useSwcLoader?: false;
} | {
  useTsLoader?: false;
  useSwcLoader: true;
} | {
  useTsLoader?: false;
  useSwcLoader?: false;
})

// валидно:
buildApp({
  entryPoint: './my-entry.tsx',
});
buildApp({
  entryPoint: './my-entry.tsx', useTsLoader: true,
});
buildApp({
  entryPoint: './my-entry.tsx', useSwcLoader: true,
});
// ошибка от ts:
buildApp({
  entryPoint: './my-entry.tsx',
  useSwcLoader: true,
  useTsLoader: true,
});

Но согласитесь, смотреть на такие типы становится больно, и очень редко кто-то действительно строит такие типы.

Что же делать?

Очевидно, использовать перечисляемые типы! enum в ts недолюбливают, но есть понятная альтернатива - union + literal types.

type BuildAppParams = {
  entryPoint: string;
  loader?: 'ts' | 'babel' | 'swc';
};

buildApp({ entryPoint: './my-entry.tsx', loader: 'ts' });

Этот вариант стоит использовать даже если на текущий момент у вас предполагается всего два варианта - кто знает как захочется расширить API в будущем?

Другой вариант, предлагаемый Мартином Фаулером - делать полность отдельные методы вместо использования флагов:

function buildAppWithBabel(entryPoint: string): Promise<void>;
function buildAppWithTs(entryPoint: string): Promise<void>;
function buildAppWithSwc(entryPoint: string): Promise<void>;

Мне персонально такой вариант в мире react кажется менее удобным, но полноценных аргументов кроме вкусовщины на это у меня нет.

Конечно, бывают варианты, когда boolean является очевидным и правильным решением. Условный setModalOpen(boolean) будет понятен, и вариантов с наполовину открытой модалкой у вас скорее всего не появится. Но даже в подобных случаях лучше задумываться - например проп для селекта defaultOpen возможно стоит заменить на defaultState: 'open' | 'closed' - вдруг вы захотите менять его поведение в зависимости от количества опций?

Вообщем проектируйте апи правильно, думайте не только о том как удобно написать вам сейчас, но и как оно будет работать потом, и как это будут использовать.

Про код ревью - как перестать докапываться до мелочей и начать получать удовольствие

2024-09-07T06:58:40.588Z

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

Тем не менее зачастую разработчики пытаются сделать на ревью именно это. Советы по тому, что в коде стоит отделять дополнительным \\n, рекомендации использовать один метод вместо другого (ведь так будет на 1 строчку короче!), настоятельные просьбы вынести что-то в отдельную функцию…

А точно ли все эти комментарии нужны?

Уровни комментариев

Содержимое любого ПР-а можно условно разделить на 5 уровней:

Архитектурный. Это то, что делает фича, какие системы вызываются, как именно устроено взаимодействие с ними.
Фичёвый. А как фича реализована? Покрыты ли все нужные в бизнес-логике кейсы? Будет ли код работать корректно в специфичных кейсах?
Структурный. Это то, как код структурирован. На какие модули он разбит, как эти модули внутри взаимодействуют
Уровень кода. Это то, как внутри устроены модули. Как называются переменные, какие фичи языка используются, как реализованы какие то алгоритмы.
Уровень форматирования. Это то, как код выглядит. Пробелы, комментарии в коде, какие кавычки использованы - относится сюда.

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

Архитектурные

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

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

Фичевые

Фичевые комментарии - самые полезные при погружении в проект. Это те вещи, которые могут знать аналитики или те, кто давно работает над проектом. “А если придет пользователь с 500 записями?”, “А не забыли ли мы про мобильную версию”. Сюда же можно отнести и комментарии по нефункциональным требованиям - “Этот сервис должен маскировать данные, которые он отправляет в логи”, “Надо написать тесты” и так далее.

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

Структурные

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

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

Про код

Комментарии, относящиеся к уровню кода могут быть полезны начинающим/людям которые только присоединились к проекту. Но тут нужно быть осторожными, и не пытаться заставлять всех писать в точности так, как пишите вы. Запись if (items.length == 0) и запись if (!items.length) эквиваленты для ts. Как писать правильно? По моему субъективному мнению первая запись понятнее, но это именно субъективное мнение. Стоит ли писать про это при ревью? Если у вас нигде не зафиксированы договоренности об этом и у вас нет цели научить разработчика - вполне возможно что правильным решением будет промолчать. В то же время если в новом коде все переменные названы одной рандомной буквой - молчать нельзя.

Многие комментарии с этого уровня могут решаться автоматическими проверками. Линтеры, code-quality инструменты - все они нужны чтобы снять нагрузку на отлавливание мелочей с разработчиков и переложить их на уровень машин. Если вы замечаете что часто пишите комментарии на этом уровне - подумайте об автоматизации.

Форматирование

Комментарии про отсутствующий пробел или не ту форму кавычек - это просто трата времени. Это уровень форматирования, и он должен решаться инструментами. Для большинства языков есть автоматические форматеры. prettier в js, gofmt в go, autopep8 для python и так далее. Если тот код, который получается на выходе из таких инструментов вас не устраивает (он не такой красивый!) - у вас есть два варианта - смириться или сделать свой инструмент, который будет выдавать такой код, который будет вам казаться эстетичным. Только сделайте так, чтобы этот инструмент работал не только на вашем компьютере, но и у других разработчиков.

Критичность комментариев

Кроме разделения на “уровень” комментариев, их можно (и нужно!) разделять и по их критичности. Некоторые вещи могут быть простым замечанием - если его проигнорировать - об этом забудется очень скоро. Какие то могут быть важными моментами, на которые автору стоит обратить внимание и постараться это исправить. Ну и некоторые комментарии могут быть блокерами. Код с такими комментариями не должен попасть в мастер ни при каких условиях.

У всех известных инструментов для работы с гит есть возможность поставить блокирующий комментарий - NEED_WORKS в битбакете, request changes в гитхабе/гитлабе. Не стоит разбрасываться таким статусом по каждой мелочи. Блокирующие комментарии по уровню кода - странный выбор. Простановка такого статуса - это повод задуматься о том, что нужно поменять чтобы таких ситуаций не возникало.

Для разделения между двумя другими уровнями критичности никаких инструментов нет. В команде лучше всего выработать договоренности о том, как именно их разделять. Одним из популярных вариантов является префикс nit: для комментариев низкой критичности. Оставляя такой комментарий вы должны быть готовы что его проигнорируют. Получая - вы можете его проигнорировать (но всё же стоит о нём хотя бы задуматься - может быть там действительно ценное замечание?)

Выводы?

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

Нытье про js тулинг

2024-09-07T06:57:18.677Z

Иногда я напитываюсь огромных количеством ненависти к тому, как устроена вся “экосистема” фронтенда. Это просто дикий набор костылей, который работает просто на удаче.

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

В процессе обнаруживается что vite, будучи нацеленным в первую очередь на esm ругается на одну из зависимостей наших пакетов. Пакет A (библиотека компонентов) импортирует в себя пакет B(набор тулзов), а у него внутри некорректное поле main в package.json. Чтож, можно же поправить!

Идем в пакет B, видим что там уже всё поправлено - добавлено поле exports, которое имеет более высокий приоритет, и все сборщики (что вебпак, что vite) прекрасно с ним работают. Нужно просто обновить версию - и все будет отлично.

Идем, обновляем. Сборка проходит. Запускаем тесты - видим что теперь jest не понимает как с этим работать. Читаем внимательнее, понимаем что в библиотеке компонентов jest версии 26, а с полями exports jest научился работать только в 28.

Обновляем до 28 версии - видим 100+ ошибок о том, что теперь jest вроде как встречает неизвестный токен export в зависимости зависимости! Хотя казалось бы, мы же вроде поддержку esm должны были получить после обновления…

Смотрим в пакет на который ругается, видим что в его package.json написано такое:

  "main": "./dist/index.js",
  "exports": {
    ".": {
      "node": {
        "module": "./dist/esm-node/index.js",
        "require": "./dist/index.js",
        "import": "./wrapper.mjs"
      },
      "default": "./dist/esm-browser/index.js"
    },
    "./package.json": "./package.json"
  },

Ругается наш jest именно на esm-browser/index.js. Проверяем - руками в node_modules меняем default на ./dist/index.js - тесты идут.

Таак. И че делать? Наобум пробуем обновить jest еще дальше, на 29 версию, получаем полное расхождение всех снапшотов + проблемы с jsdom. Ок, не катит.

Вроде vitest есть! Он же совместим почти полностью по апи, и построен сразу с идеей нормальной работы с esm-модулями!

Пробуем перейти на него. Мигрируем код код-модом, это же не долго! Запускаем. Получаем кучу изменений, но вроде бы вполне вменяемых. yarn vitest… не, ну конечно оно не запустилось. Выясняется что window.computedStyle нет в jsdom! Это патчится в jest какими то костылями, но vitest логично решили что это не их дело - пусть пользователи сами разбираются.

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

Читаем внимательно то, как можно конфигурировать jest. Вроде в вебпаке можно было указывать поле в package, из которого должен браться resolution…

Такого апи нет, но можно написать свой резолвер! Пробираемся через дебри не очень подробной документации, смотрим как написаны другие резолверы, делаем свой. Отлавливаем баги, вроде все запускается.

На данном этапе на это ушло уже несколько часов, а изначальная задачка еще совсем не решена. Но мы же уже близко?

Локально тесты проходят. Создаем пр, пушим нашу ветку. Тесты падают в ci. Понимаем что наш резолвер работает не совсем корректно. Потом вспоминаем что часть разработчиков вообще сидит на windows, и наш резолвер вообще не умеет работать с отличными от / разделителями. Может пойти и просто поправить зависимости в core-components?

Теперь все это напоминает чудесный отрывок из шоу “Malcolm in the middle “

https://youtu.be/UZFI-8D5uA?si=yzBwabQNHgtBYm9

Короче говоря - в такие моменты хочется просто забить на весь этот тулинг, esm/cjs, тесты и вообще всё что связано с инструментами.

Хочется писать в блокноте код на jquery, рисовать скруглённые уголки таблицами и заливать всё это на сервер через ftp. А не вот это вот все.