
В этом блоге рассматривается модель доверия MetaMask Snaps, описываются распространённые проблемы безопасности и лучшие практики для разработчиков в экосистеме web3.

MetaMask Snaps — это система с открытым исходным кодом, позволяющая пользователям безопасно расширять функциональность MetaMask и открывающая новые возможности для работы с кошельком. В основе системы лежит Snap — программа на JavaScript, работающая внутри MetaMask в изолированной среде.
В этом блоге мы рассмотрим ландшафт безопасности MetaMask Snaps. Как аудиторы безопасности блокчейна из Consensys Diligence, мы специализируемся на безопасности смарт-контрактов. Consensys Diligence — компания в области безопасности блокчейна, предоставляющая комплексные услуги по аудиту смарт-контрактов, помогая проектам в сфере web3 создавать безопасные dapp-приложения.
Каждый разработчик Snaps должен понимать модель доверия, лежащую в основе MetaMask Snaps. Эта модель определяет границы доверия между различными участниками. Ключевой тезис, который необходимо запомнить: конечные пользователи доверяют MetaMask, но не доверяют dapp-приложениям.
Мы формализовали и обобщили модель доверия на диаграмме ниже. На ней изображены различные границы доверия, которые разработчики должны учитывать при создании Snaps:
Первая граница доверия существует между пользователем и dapp-приложением. Пользователи никогда не доверяют dapp-приложениям. Действительно, они могут быть вредоносными или скомпрометированными. Они могут заставить пользователей думать, что те подписывают определённые данные, тогда как на самом деле подписывается что-то совершенно иное.
Вторая граница доверия охватывает MetaMask и его расширения. Хотя пользователи не доверяют dapp-приложениям, они доверяют MetaMask. MetaMask является источником истины для пользователя. Данные, отображаемые и подписываемые внутри MetaMask — будь то через его основной модуль или Snaps — имеют решающее значение.
Третья граница доверия существует между основным модулем MetaMask и Snap. Разработчики Snaps могут взаимодействовать с основным модулем MetaMask через Snaps API. Этот API реализует систему разрешений, то есть разработчики должны запрашивать разрешения перед получением доступа к ограниченным функциям API. Тем не менее при наличии соответствующих разрешений Snaps могут выполнять критически важные действия: получать доступ к корневой энтропии MetaMask, подписывать данные или взаимодействовать с внешними API.
По существу, руководящий принцип для конечных пользователей в экосистеме MetaMask прост, но глубок: конечные пользователи должны доверять только той информации и тем взаимодействиям, которые происходят в контексте MetaMask и MetaMask Snap, известном как Trust Module.
Модель доверия MetaMask обеспечивает структурированный подход к аудиту и помогает аудиторам выявлять проблемы безопасности. В ходе наших аудитов Snaps мы выявили различные категории проблем. Нам было интересно узнать о других потенциальных категориях. Поэтому мы провели комплексный анализ 40 Snaps, проверенных 9 аудиторскими компаниями. Мы разработали классификацию и распределили проблемы по категориям. Ниже мы выделяем несколько интересных категорий с примерами. Обратите внимание, что этот список не является исчерпывающим.
Внедрение Markdown и управляющих символов: риск внедрения нежелательного кода или команд через Markdown или управляющие символы в пользовательских вводах.
Санитизация и валидация пользовательского ввода:- Проблемы проверки типов, путаницы типов и парсинга
API не отклоняет недопустимые параметры RPC: проблема возникает, когда API не отклоняет недопустимые параметры, такие как неверные идентификаторы цепочки, контрольные суммы адресов или структуры комиссий.
Ненадлежащая валидация URI: проблема может возникнуть при использовании нестрогих регулярных выражений при валидации URI, например.
Нарушение устоявшихся паттернов UX MetaMask: проблема возникает, когда приложения отклоняются от устоявшихся паттернов пользовательского опыта MetaMask.- Отсутствие запроса на доступ к аккаунту: MetaMask всегда запрашивает подтверждение пользователя перед подключением любого аккаунта к dapp-приложению. Разработчики Snaps должны следовать той же схеме.
Перечисление аккаунтов: проблема конфиденциальности, при которой приложение может перечислять или отображать аккаунты пользователей без надлежащего согласия.
Отсутствие запроса согласия пользователя:- При подписании данных: случаи, когда приложение выполняет действия, связанные с подписью, без явного одобрения пользователя.
Отображение приватного ключа без переключателя видимости пароля: приватные ключи отображаются без использования компонента «нажмите для отображения» с сопроводительным текстом-предупреждением. Это может быть проблематично, например, если пользователь находится в общественном месте.
Непрозрачные диалоги Snap: диалоги, которым не хватает прозрачности или ясности.- Диалог подписания транзакции с отсутствующей информацией: случай, когда в диалогах подписания транзакций опускается важная информация или представленная пользователю информация не читается человеком.
Проблемы неточности при округлении комиссий: неточности или недостаточная точность в расчётах и отображении комиссий.
Отображение источника: Snap не отображает источник действия. Это может ввести пользователя в заблуждение, заставив думать, что действие было инициировано одним dapp-приложением, тогда как на самом деле оно исходило от другого.
Уязвимые/ненадёжные зависимости.
Атаки на цепочку поставок: зависимость может быть скомпрометирована через прямые или косвенные векторы атак.
Устаревшие зависимости: использование устаревших зависимостей может иметь серьёзные последствия для безопасности, поскольку они могут содержать уязвимости.
Избыточные разрешения: предоставление слишком большого количества разрешений снижает уровень безопасности.
Доступ к низкоуровневым разрешениям: ненадлежащее управление энтропией корневых ключей MetaMask для Ethereum, например.
Утечка криптографических материалов:- Запрос dapp-приложения на получение приватного ключа: приватные ключи никогда не должны покидать MetaMask!
Управление аккаунтами: Snap должен запрашивать подтверждение пользователя перед подключением любого аккаунта при первом подключении.
В настоящее время мы уточняем результаты нашего анализа и выявляем новые закономерности. Скоро будет больше. Следите за обновлениями :)
Помните, что вы разрабатываете модуль доверия! Пользователи доверяют MetaMask, но не dapp-приложениям. Пользователь должен подтверждать каждое действие и иметь всю необходимую информацию для принятия обоснованного решения. Ключи никогда не покидают MetaMask. Следовательно, как разработчик Snaps, вы должны:
Запрашивать минимально необходимые разрешения: Snaps должны запрашивать доступ только к тем функциям или данным, которые необходимы для их работы, чтобы минимизировать поверхность атаки.
Валидировать и санитизировать ненадёжные входные данные: избегайте атак внедрения или выполнения ненадёжного кода. Учитывая способность Snap расширять функциональность кошелька пользователя, обеспечение безопасности всех входных данных и их защита от эксплойтов крайне важны для сохранности кошелька и активов пользователя.
Управлять цепочкой поставок: тщательно выбирайте и обновляйте зависимости, чтобы избежать уязвимостей.
Учёт этих принципов и лежащих в их основе распространённых проблем в процессе разработки делает будущее Snaps значительно безопаснее для следующего миллиарда пользователей.
Consensys Diligence помогла широкому кругу проектов в экосистеме блокчейна обеспечить готовность их протоколов к запуску и надёжную защиту пользователей. Consensys Diligence готова проверить ваш Snap на наличие этих и других уязвимостей в рамках индивидуального аудита. Свяжитесь с нами и получите коммерческое предложение!
Martin Ortner (tintinweb)
Valentin Quelquejay
Мартин и Валентин, специалисты по безопасности в Consensys Diligence, находятся на переднем крае исследований безопасности Snap, неустанно работая над повышением уровня безопасности платформы.
Переведено ИИ. Может содержать ошибки. Пожалуйста, всегда проверяйте информацию.