a16z: Руководство по безопасности смарт-контрактов для проектов Web3

Источник: a16z

Составила: Katie 辜, 星球日报

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

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

Разработка безопасного программного обеспечения включает в себя следующие пять этапов:

1. Проектирование: разработчики описывают необходимые функции и операции системы, включая важные эталоны и фиксированные свойства;

2. Разработка: разработчики пишут код системы;

3. Тестирование и рецензирование: разработчики собирают все модули в тестовой среде и оценивают их корректность, масштаб и другие факторы;

4. Развертывание: разработчики вводят систему в эксплуатацию;

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

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

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

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

1. Аспекты безопасности смарт-контрактов на этапе проектирования ------ Моделирование угроз и безопасное проектирование

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

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

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

2. Аспекты безопасности на этапе разработки ------ Управление и контроль доступа

• Содержание: реализуйте контроль доступа, ограничивающий возможность выполнения управленческих задач (таких как обновление контрактов и установка специальных параметров) для привилегированных учетных записей и вызовов смарт-контрактов. Следуйте принципу "минимальных привилегий" ------ каждый участник должен иметь только необходимый минимум доступа.

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

• Метод: создайте мультиподписные кошельки или контракты DAO, чтобы прозрачно представлять изменения, управляемые сообществом. Изменения должны проходить тщательный процесс проверки и устанавливать временные замки (умышленное задерживание принятия решений с возможностью отмены), чтобы гарантировать, что их правильность можно проверить и откатить в случае атаки на управление. Убедитесь, что привилегированные ключи можно безопасно хранить и получать в кошельках с самостоятельным хранением или в службах безопасного хранения.

3. Учет повторно используемых, проверенных шаблонов и интеграций

• Содержание: по возможности используйте существующие стандарты смарт-контрактов (например, контракты OpenZeppelin) и оценивайте предположения о безопасности, которые могут потребоваться для интеграции с существующими протоколами.

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

• Метод: импортируйте проверенные библиотеки и интерфейсы контрактов, прошедшие аудит безопасности. Основное внимание Web3 уделяется открытости, повторному использованию и совместимости. Убедитесь, что зависимости контрактов и их версии задокументированы в кодовой базе, чтобы минимизировать занимаемое пространство кода. Например, импортируйте конкретные подмодули крупных проектов, а не импортируйте все. Понимайте свои рисковые экспозиции, следите за атаками на цепочку поставок. Используйте официальные интерфейсы для вызова внешних протоколов и учитывайте потенциальные риски интеграции. Следите за обновлениями и раскрытием безопасности повторно используемых контрактов.

4. Аспекты безопасности на этапе тестирования и рецензирования ------ Тестирование и документация

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

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

• Метод: реализуйте известные тестовые фреймворки и проверяющие безопасности, такие как Hardhat, Mythril, Slither, Truffle и т. д., которые предлагают различные тестовые техники, такие как фуззинг, проверка свойств и даже формальная верификация. Используйте комментарии NatSpec для широкого документирования кода, чтобы указать ожидаемые побочные эффекты, параметры и возвращаемые значения. Используйте инструменты генерации документации и высокоуровневые проектные описания для создания актуальной документации.

5. Учет внутренних проверок и аудита безопасности

• Содержание: уделите время для выявления уязвимостей через внутренние и внешние проверки кода.

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

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

Пожалуйста, ознакомьтесь с руководствами ConsenSys, Nassent, OpenZeppelin и Trail of Bits, которые предоставляют разработчикам список вопросов для рассмотрения, включая временные рамки, для любого, кто готовится к аудиту. Также убедитесь, что вы проверяете транзакции развертывания, чтобы гарантировать, что они используют проверенные версии кода и имеют соответствующие параметры, особенно при обновлении программного обеспечения.

6. Аспекты безопасности на этапе развертывания и обслуживания ------ Стимулирование участия сообщества белых хакеров

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

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

• Метод: используйте платформы вознаграждений за уязвимости (такие как Code4rena, HackenProof, mmunef или Secureum), чтобы мотивировать опытных хакеров безопасно раскрывать уязвимости.

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

7. Аспекты безопасности для мониторинга в реальном времени

• Содержание: реализуйте системы мониторинга смарт-контрактов и ключевых операционных компонентов (таких как оракулы и кросс-цепочные мосты) и сообщайте команде разработчиков и сообществу о подозрительной активности на основе известных моделей угроз.

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

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

8. Аспекты безопасности для реагирования на инциденты и чрезвычайные ситуации

• Содержание: используйте инструменты и процессы, которые могут немедленно реагировать на любые проблемы безопасности.

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

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

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

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