5 советов по аудиту безопасности от MSQ Snap и Consensys Diligence

Consensys Diligence — аудиторское подразделение Consensys Software Inc., известное непревзойдённой экспертизой в проведении тщательных аудитов в области Solidity, Cairo и широкого спектра ZK-библиотек. Команда Diligence возглавляет разработку стандартов аудита и безопасности для MetaMask Snaps и тесно сотрудничает с командой MetaMask, обеспечивая защиту функций кошелька. Кроме того, команда Diligence является первопроходцем в разработке инструментов безопасности и передовых решений для непрерывного фаззинга, проверенных в самых требовательных производственных средах.

Проект MSQ недавно был запущен в MetaMask Snaps Store. MSQ — это Snap, позволяющий пользователям взаимодействовать с сетью Internet Computer, управлять токенами на базе IC, безопасно авторизоваться в dapp-приложениях на базе IC, а также оплачивать цифровые товары и услуги. По сути, это криптовалютный кошелёк, интегрированный с MetaMask и разработанный специально для Internet Computer с уникальными функциями авторизации и платежей.

Совместно команды Diligence и MSQ определили пять ключевых областей, которые рассматриваются в этой статье: документация, архитектура программного обеспечения, код, цепочка поставок и устранение уязвимостей. Здесь представлен перечень практик, применявшихся командой MSQ в процессе разработки, а также комментарии команды Diligence, раскрывающие преимущества этих практик с точки зрения безопасности. Материал будет полезен всем, кто создаёт Snap для MetaMask Wallet или любую другую систему, критически важную с точки зрения безопасности и подлежащую возможному аудиту. Начнём!

1. Создайте многоуровневую документацию

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

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

1.1 Код

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

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

• Делайте код удобным для навигации, обеспечивая лёгкое перемещение по нему в IDE.

• Используйте развёрнутые имена, чтобы прояснить назначение и функциональность элементов кода.

• Применяйте строго типизированные языки для чёткого определения форматов данных.

Snap MSQ и фронтенды dapp разработаны на TypeScript, что позволило предотвратить множество потенциальных ошибок — в отличие от подводных камней обычного JavaScript. Аналогично наш бэкенд использует Rust, известный своей надёжной системой типов. Кроме того, MSQ Snap экспортирует ряд методов, которые могут вызываться сторонними приложениями. Однако для идентификации этих методов мы используем не строки, а константы. У нас есть константный объект следующего вида:

export const SNAP_METHODS = {
  protected: {
    identity: {
      login: "protected_identity_login",
      ...
    },
    icrc1: {      
	    ...
    },
    ...
  },
  public: {
    identity: {
      sign: "public_identity_sign",			
      ...
    },
    ...
  },
};
Копировать

В коде этот константный объект можно использовать как ориентир для обращения к нужному методу, а читатели могут многое узнать о методе по его идентификатору в объекте. Например, метод SNAP_METHODS.protected.identity.login может вызываться только companion dapp MSQ и позволяет пользователю выполнить вход. Такой подход повышает читаемость кода и упрощает рефакторинг, поскольку изменения имён методов управляются централизованно, а не вносятся в множество мест.

Для сопоставления имён методов мы используем большое выражение switch с ветками следующего вида:

case SNAP_METHODS.protected.identity.login: {
  result = protected_handleIdentityLogin(req.params.body);
  break;
  }
Копировать

Как видите, при чтении этого кода практически невозможно что-либо неверно истолковать — всё названо точно, не оставляя места для домыслов.

Комментарий Diligence Время — критически важный фактор. Разработчики тратят недели на изучение кодовой базы, тогда как у специалистов по безопасности зачастую есть лишь несколько дней на выявление рисков. Это подчёркивает важность снижения когнитивной нагрузки в коде — практики, которая одинаково полезна как для эффективности разработчиков, так и для обеспечения безопасности.

Из кодовой базы MSQ можно извлечь следующий урок: чёткий, удобный для навигации код с описательными именами и строгой типизацией (как в TypeScript) снижает вероятность недопонимания — распространённого источника уязвимостей.

Но помните: аннотации типов TypeScript проверяются только во время компиляции! Для любых данных, обрабатываемых или разбираемых во время выполнения (RPC, JSON и т. д.), необходимы дополнительные проверки типов, формата данных и допустимых значений! Для этой цели MSQ элегантно использует zod — библиотеку валидации схем с приоритетом TypeScript и статическим выводом типов. Мы рекомендуем командам следовать этому подходу.

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

1.2 Комментарии к коду

Мы считаем, что комментирование — это не про стопроцентное покрытие кода. Важно аннотировать сложные или плохо написанные части. Такие области, как регулярные выражения, криптография и операции со строками, особенно выигрывают от чётких комментариев.

Например, в MSQ есть функция, которая экранирует возможные управляющие символы Markdown в строке. Её тело — это одна строка кода, но в ней используется сопоставление с регулярным выражением, поэтому мы описываем её функциональность в комментарии:

/**
 * Escapes Markdown control characters, newline characters, and backticks in a string.
 * This function takes a string and returns a new string with all Markdown control characters, newline characters, and backticks escaped.
 * Escaping is done by prefixing each control character and backtick with a backslash (`\\`), and newline characters are replaced with `\\\\n`.
 *
 * Control characters include: `{`, `}`, `[`, `]`, `(`, `)`, `#`, `!`, `|`, `\\`, and `` ` ``.
 * Newline characters are replaced with a visible escape sequence (`\\\\n`) for demonstration or specific formatting needs.
 * Since all newlines are escaped, list creating characters `-`, `+` and `.` are allowed.
 * Text styling characters `*`, `_` are also allowed
 *
 * @param {string} text The string to be escaped.
 * @return {string} The escaped string, safe to be used in Markdown without triggering formatting, with newline characters visually represented and backticks escaped.
 */
export function escapeMarkdown(text: string) {
  return text.replace(/([{}\\[\\]()#!|\\\\`])|\\n/g, (match) => (match === "\\n" ? "\\\\n" : "\\\\" + match));
}
Копировать

Если вы не против использования ИИ в рабочем процессе, ChatGPT отлично справляется с быстрой генерацией хороших комментариев для подобных утилитарных функций (только обязательно проверяйте результат).

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

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

Поэтому делайте комментарии краткими и точными — так же, как это делает MSQ в своей кодовой базе. Встроенные комментарии — это не просто заметки; они служат маяками, направляющими нас через ваш код, а несоответствия — это подсказки о том, что что-то может быть не так.

1.3 Документация на уровне системы

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

Системная документация MSQ включает обзор архитектуры и руководство по интеграции. Эти документы, насыщенные текстовыми описаниями, примерами и диаграммами, поясняют, как взаимодействуют различные части системы.

Диаграммы последовательностей незаменимы для визуализации взаимодействий компонентов. Мы рекомендуем использовать diagrams.net (draw.io) — бесплатный инструмент, зарекомендовавший себя в самых разных проектах.

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

Представьте проверку безопасности как игру в Command & Conquer. Вы начинаете с почти закрытой картой. По мере исследования системная документация действует как разведывательные отряды, раскрывая полную архитектуру — разрешения, взаимодействия Snap с dApp, пользовательские взаимодействия. Этот постепенно открывающийся обзор позволяет проверяющим отслеживать пользовательские пути — как движение игровых юнитов — и выявлять маршруты, способные обойти защиту.

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

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

1.4 Документация общего уровня

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

Эта информация в основном касается бизнес-аспектов, но отлично отвечает на вопрос «Что?», тогда как все предыдущие уровни с разной степенью детализации отвечали на вопрос «Как?».

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

Например, главный экран лендинга MSQ крупными буквами гласит: «USE THE INTERNET COMPUTER WITH METAMASK». Прочитав эту простую фразу, читатель, вероятно, догадается: «А, значит, это кошелёк-Snap, который может хранить токены блокчейна Internet Computer. Наверное, он работает так же, как другие Snaps для других блокчейнов, только с использованием технологий из экосистемы разработчиков IC» — и это будет абсолютно верная догадка.

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

2. Ограничивайте дизайн там, где это возможно

Этот раздел, пожалуй, наиболее важен для безопасности вашего проекта. Ваш код может быть на 100% защищён от ошибок, а инфраструктура — защищена мерами на миллионы долларов. Но все эти усилия окажутся напрасными, если в вашем дизайне есть фундаментальный изъян, которым могут воспользоваться злоумышленники.

Конкретные примеры варьируются в зависимости от сценария использования, но мы предлагаем несколько универсальных советов.

2.1 Разработайте принципы безопасности и следуйте им

В начале работы над MSQ мы сформулировали основные принципы безопасности, соответствующие нашему видению:

• Команда MSQ ничего не знает: мы не собираем никакую конфиденциальную информацию пользователей, включая ключевые материалы, данные авторизационных сессий или сведения об аккаунтах.

• Криптографические материалы никогда не покидают Snap: защищённая энтропия MetaMask пользователя обрабатывается исключительно внутри Snap, генерируется по запросу и немедленно уничтожается после использования.

• MSQ детерминирован: пользователи могут детерминированно восстановить все средства, идентификаторы и ключевые пары с помощью своей корневой seed-фразы без каких-либо дополнительных знаний.

• MSQ ставит конфиденциальность на первое место: наши усилия направлены прежде всего на защиту приватности пользователей.

Эти принципы адаптированы к специфическим потребностям MSQ. Тем не менее команда MetaMask также предоставляет набор рекомендаций по безопасности для разработчиков Snap, которым следует MSQ; они доступны здесь.

Например, существует принцип минимальных разрешений, который означает: чем меньше разрешений ваш Snap запрашивает у пользователя, тем выше его безопасность. MSQ запрашивает только 4 разрешения:

• endowment:rpc

• snap_dialog

• snap_manageState

• snap_getEntropy

Нам не нужен endowment: network access, поскольку MSQ отвечает только за подписание транзакций, но не за их доставку в IC — это задача интегрирующего dapp.

Сделайте то же самое в своём Snap: возьмите стандартные рекомендации MetaMask, дополните их своими специфическими правилами и следуйте им.

Комментарий Diligence Мы говорим нашим клиентам: «Безопасность — это не функция, которую добавляют; это принцип, вокруг которого проектируют». Именно то, что MSQ сформулировал основные принципы безопасности в самом начале проекта, — это то, что мы ищем. Слишком часто проекты относятся к безопасности как к запоздалой мысли, добавляя меры защиты уже после того, как основная архитектура сформирована. Такой подход неизбежно оставляет фундаментальные изъяны, которые невозможно по-настоящему устранить на уровне кода.

В Consensys Diligence мы предоставляем услуги экспертов по безопасности, инструменты и отстаиваем права конечных пользователей. Это включает обеспечение сохранности ключевых материалов пользователей в пределах доверенной зоны кошелька — без непреднамеренного раскрытия за её пределами. Мы также уделяем особое внимание защите конфиденциальности пользователей, в идеале предотвращая даже утечку метаданных или информации по побочным каналам третьим сторонам. Кроме того, мы настаиваем на том, чтобы snaps запрашивали только минимально необходимые для работы разрешения — принцип наименьших привилегий.

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

2.2 Защищайте пользователя любой ценой

Это скорее мета-принцип — он должен быть реализован в любом программном обеспечении: от онлайн-игр до банковских систем.

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

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

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

В противовес этому MSQ применяет технику разграничения идентификаторов — каждый dapp (каждый отдельный URL-источник) имеет собственный набор пользовательских идентификаторов, с которыми он может взаимодействовать, без возможности взаимодействовать с идентификаторами пользователя из других dapp. Это не только решает проблему мошеннических сайтов, но и существенно улучшает конфиденциальность: dapp больше не могут отслеживать пользователя и вид施, с какими смарт-контрактами (называемыми в IC канистрами) он взаимодействует. Этот метод, вдохновлённый Internet Identity и спецификацией WebAuthn, значительно снижает риски безопасности.

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

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

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

Комментарий Diligence Компромисс в виде ограниченной прямой интеграции между dApp — это взвешенное решение. В наших оценках рисков мы часто говорим о «бюджете безопасности», признавая, что идеальная безопасность может ограничивать функциональность. MSQ потратил этот бюджет разумно. Ограничив межdApp-взаимодействия, они кардинально снизили один из наиболее серьёзных рисков (массовое злоупотребление идентификаторами), сохранив при этом основные функции кошелька.

3. Пишите надёжный код

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

3.1 Ваш код

«Надёжный» здесь означает, что код ведёт себя предсказуемо, обрабатывая все ожидаемые и неожиданные входные данные. Например, как должен реагировать ваш Snap, если ему передана строка base64, тогда как он ожидает hex? Или если методы вызываются в непредусмотренной последовательности, или вызывается неопределённый RPC-метод?

Для устранения этих неопределённостей необходимо:

1. Чёткая обработка ошибок: убедитесь, что каждая ветка и каждый случай в вашем коде проверяются и обрабатываются надлежащим образом. В Snap MSQ мы используем исчерпывающие проверки TypeScript в операторах switch-case для перехвата любых неожиданных вызовов методов, как показано ниже:

default: {
  err(ErrorCode.INVALID_RPC_METHOD, request.method);
}
Копировать

Эта конструкция перехватывает случаи использования неизвестного идентификатора RPC-метода.

1. Санитизация входных данных: валидация входных данных на соответствие ожидаемым типам и форматам может быть сложной задачей, но она необходима для безопасности. Для этого мы используем библиотеку zod в TypeScript, расширяя систему типов TypeScript до проверок во время выполнения. Zod позволяет задавать детальные определения схем, гарантируя обработку только валидных данных.

Например, наш метод SNAP_METHODS.protected.identity.login использует схему zod для строгой валидации входных данных:

export const ZIdentityLoginRequest = z.object({
  toOrigin: ZOrigin,
  withIdentityId: ZIdentityId,
  withLinkedOrigin: z.optional(ZOrigin),
});

export const ZOrigin = z.string().url();
export const ZIdentityId = z.number().int().nonnegative();
Копировать

Здесь ZOrigin и ZIdentityId — это не просто строки или числа, а специально валидированные подтипы, гарантирующие, что входные данные корректны не только по типу, но и контекстуально.

Определяя схемы zod максимально точно, вы можете превентивно решить многие потенциальные проблемы. Аудиторы рекомендовали ввести строгую валидацию в MSQ, и после её реализации было выявлено и устранено несколько рисков безопасности.

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

3.2 Сторонний код

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

Такая библиотека полезна по нескольким причинам:

• Упрощает сложность API: мы абстрагируем сложности Snap в удобный для пользователя API. Например, клиентская библиотека MSQ использует CBOR для кодирования данных, обходя ограничения JSON-RPC и избавляя разработчиков от необходимости вручную кодировать и декодировать данные.

• Обеспечивает безопасное и прямое взаимодействие: некоторые функции Snap доступны исключительно нашему companion dapp. Для этого мы управляем процессами перенаправления и передачи данных, обеспечивая бесперебойный поток через postMessage. Такая внутренняя обработка гарантирует, что сторонние разработчики взаимодействуют с нашим Snap через чёткий и понятный API.

• Повышает семантическую ясность: чистый API — это не просто инструмент; это средство коммуникации, делающее код более читаемым и понятным, свободным от нагромождения сложных процессов кодирования/декодирования и дополнительных операционных уровней.

Уделяя приоритетное внимание этим аспектам, MSQ стремится создать экосистему, в которой как наш Snap, так и интегрирующие dapp могут работать эффективно и безопасно.

Комментарий Diligence Подход MSQ к интеграции стороннего кода через их библиотеку демонстрирует стремление упростить разработку, не жертвуя безопасностью. Хотя в основе своей безопасность должна строго соблюдаться в контексте Snap, библиотека на стороне dapp может обеспечить удобный способ взаимодействия с ним. Тем не менее всегда следует помнить: разработчик dapp обязан обеспечить безопасное взаимодействие со Snap и безопасное кодирование данных при использовании в контексте dapp.

4. Защитите свою цепочку поставок

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

4.1 Привязывайте пакеты к конкретным версиям

Использование pnpm install --save <package-name> обычно устанавливает последнюю версию пакета в соответствии со спецификацией semver, допускающей автоматическое обновление до более новых обратно совместимых версий. Это обозначается символом каретки (^) в package.json, указывающим на диапазон допустимых версий:

Однако для предотвращения рисков от вредоносных обновлений безопаснее зафиксировать зависимости на конкретных версиях:

1. Удалите каретку (^) из package.json, чтобы зафиксировать версию каждой зависимости. Удалите существующие lock-файлы и node_modules, затем выполните pnpm install для строгого соответствия заданным версиям.

2. Используйте флаг --save-exact для будущих установок (pnpm install --save-exact <package-name>), чтобы избежать автоматических обновлений.

Доверие — важный фактор в этом решении. Например, в MSQ мы считаем пространства имён зависимостей @metamask и @dfinity безопасными и допускаем обновления в пределах их диапазона semver. Однако при этом будьте осторожны в отношении потенциальных уязвимостей из транзитивных зависимостей.

Комментарий Diligence Переход проектов на точные версии зависимостей предотвратил бесчисленное множество проблем:

• Это остановило тихие обновления, повторно вводившие уже исправленные уязвимости.

• Это предотвратило «расхождение версий», при котором разные модули видят разное поведение библиотек.

• Это оказалось критически важным в ходе расследований инцидентов, позволяя воспроизвести точную среду. Каждое следующее обновление может оказаться вредоносным — в любом пространстве имён, в любом пакете. Проверяя используемые пакеты и привязываясь только к заведомо безопасным версиям, предотвращая случайные обновления, вы дополнительно сокращаете поверхность атаки для атак на цепочку поставок. Доверять определённым поставщикам допустимо, при условии что новые версии вручную проверяются на отсутствие вредоносного кода перед использованием. Обратите внимание: особенно широко используемые пакеты, применяемые во многих проектах, являются первоочередными целями для злоумышленников, и, как показало прошлое, любая такая базовая библиотека может стать жертвой изощрённых атак на цепочку поставок (см. атаку с бэкдором XZ).

4.2 Фиксируйте lock-файлы в репозитории

Для обеспечения согласованности в команде и воспроизводимости сборок фиксируйте lock-файлы в системе контроля версий. В MSQ мы используем pnpm workspaces и turborepo, что требует единственного корневого lock-файла — pnpm-lock.yaml. Однако ваша конфигурация может потребовать ведения нескольких lock-файлов; все они должны находиться под контролем версий для гарантии согласованности среды.

Комментарий Diligence Эта практика, которую порой недооценивают как простое удобство для разработки, на самом деле является критически важным компонентом поддержания безопасной и стабильной кодовой базы. Годы аудита смарт-контрактов, компонентов блокчейна и теперь MetaMask Snaps неизменно показывают: воспроизводимые сборки — это не приятный бонус, а фундаментальное требование безопасности. Фиксация lock-файлов — один из элементов пазла по сокращению поверхности атаки для атак на цепочку поставок. Когда npm install перестаёт быть лотереей, конкретные версии и контрольные суммы оставляют след аудита в репозитории, сборки становятся более детерминированными, а дискуссии «у меня работает» уходят в прошлое.

5. Исправляйте быстро и чисто

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

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

Например, в MSQ аудиторы обнаружили, что в наши сообщения о согласии MetaMask можно внедрить управляющие символы Markdown. Вместо того чтобы исправлять каждое отдельное сообщение о согласии, внося множество изменений в разных частях кода, мы просто переопределили элементы text() и heading() (из @metamask/snaps-sdk), чтобы они сначала пропускали своё содержимое через функцию escapeMarkdown() и только затем отображали его. Это позволило нам просто заменить выражения import во всех файлах с сообщениями о согласии на наши пользовательские элементы, вместо того чтобы исправлять каждый вызов text() и heading() по отдельности — что стало значительно более чистым решением.

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

Комментарий Diligence Слишком часто мы видим, как проекты подходят к безопасности по принципу «ударить крота» — латая каждую отдельную проблему по мере её появления, не задумываясь о лежащем в основе классе уязвимостей. Устраняя первопричины проблем и не останавливаясь перед тем, чтобы глобально ликвидировать целые классы уязвимостей, MSQ демонстрирует понимание безопасности не как серии патчей, а как целостной дисциплины. Как эксперты по безопасности, мы можем лишь рекомендовать нашим клиентам не торопиться с исправлениями и уделять достаточно времени тому, чтобы превратить находку в области безопасности в событие, оказывающее положительное влияние на защищённость проекта.

Заключение

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

Consensys Diligence помогла широкому кругу проектов в экосистеме блокчейна убедиться в готовности их протоколов к запуску и в надёжной защите пользователей. Мы готовы проверить ваш Snap на наличие этих и других уязвимостей в рамках индивидуального аудита. Свяжитесь с нами и получите коммерческое предложение!