Безопасность смарт-контрактов: подход Agile SDLC

Переиздано Платоном

Читают: 0

Время Читать: 10 минут

Блокчейн позиционируется как децентрализованный и защищенный от несанкционированного доступа реестр. Но этот защищенный от несанкционированного доступа реестр уязвим для взломов и эксплойтов. Децентрализация, которая является одним из самых сильных преимуществ Blockchain, является одним из недостатков.

Ну, это хорошо, но как насчет SDLC?

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

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

АНАЛИЗ ПРОБЛЕМ БЕЗОПАСНОСТИ В СМАРТ-КОНТРАКТАХ

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

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

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

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

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

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

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

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

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

РЕШЕНИЯ ДЛЯ БЕЗОПАСНОСТИ СМАРТ-КОНТРАКТОВ

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

Жизненный цикл разработки смарт-контрактов можно разделить на четыре этапа: проектирование безопасности, реализация безопасности, тестирование перед развертыванием, а также мониторинг и анализ.

*обзор тем безопасности с точки зрения жизненного цикла смарт-контракта*

1. ПРОЕКТ БЕЗОПАСНОСТИ

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

ПРИНЦИП КОНСТРУКЦИИ

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

Теперь вы можете подумать, как они помогут создать безопасный смарт-контракт?

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

ОБРАЗЕЦ ДИЗАЙНА

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

Если мы возьмем в качестве примера Ethereum, есть шесть шаблонов безопасности; Проверка-эффекты-взаимодействие, аварийная остановка, мьютекс, лежачий полицейский, ограничение скорости и ограничение баланса.

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

В то же время шаблон аварийной остановки может помочь нам прекратить выполнение контракта, если на него влияет уязвимость.

МОДЕЛИРОВАНИЕ БЕЗОПАСНОСТИ

Может быть разница между разработанным кодом и кодом, необходимым для контрактов, поскольку Solidity используется для создания контрактов; этот язык удовлетворяет полноте Тьюринга, но подвержен ошибкам.

На рисунке выше показано, что эта подфаза охватывает две фазы; проектирование и реализация безопасности.

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

2. РЕАЛИЗАЦИЯ БЕЗОПАСНОСТИ

В этом разделе мы рассмотрим две из трех тем; безопасность

Шаблон разработки и безопасности, так как мы уже рассмотрели моделирование безопасности на последнем этапе.

РАЗВИТИЕ БЕЗОПАСНОСТИ

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

На платформе Ethereum у нас есть EIP безопасности (предложения по улучшению Ethereum) — рекомендации по борьбе с проблемами безопасности на Эфириум Платформа. Таким образом, эти EIP заслуживают внимания за безопасную реализацию смарт-контрактов.

ШАБЛОН БЕЗОПАСНОСТИ

Шаблоны служат источником для новых документов. Шаблоны смарт-контрактов с рабочими параметрами связывают юридическое соглашение с исполняемым кодом.

В контексте безопасности смарт-контрактов можно извлечь стандартные шаблоны контрактов с обновленными параметрами безопасности, такими как шаблоны безопасности и библиотеки безопасности. Это снизит вероятность ошибок при ручном кодировании.

3. ТЕСТИРОВАНИЕ ПЕРЕД РАЗВЕРТЫВАНИЕМ

Опять же, требование этого этапа вытекает из одного из преимуществ смарт-контрактов — «неизменяемости».

После создания смарт-контрактов изменить их невозможно. Поэтому перед развертыванием необходимо провести достаточные тесты для обеспечения безопасности смарт-контрактов.

Этот этап охватывает три параметра безопасности, которым необходимо следовать перед развертыванием смарт-контракта; Строгая формальная проверка, инструменты анализа кода и аудит безопасности.

СТРОГАЯ ФОРМАЛЬНАЯ ПРОВЕРКА

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

Мы можем выполнять формальную проверку смарт-контрактов, поскольку контрактная программа коротка и ограничена по времени. Существует несколько способов жестко формализовать и проверить смарт-контракты; некоторые основаны на коде контракта, а другие — на семантике виртуальной машины Ethereum (EVM).

ИНСТРУМЕНТЫ АНАЛИЗА КОДА

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

Анализ, выполняемый этими инструментами, может включать один или все следующие этапы:

(I) Создайте промежуточное представление (IR), например абстрактное синтаксическое дерево (AST), для подробного анализа.

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

Но какие инструменты можно использовать для анализа кода смарт-контракта?

Хотя существует множество инструментов, которые можно использовать для проведения анализа безопасности, наиболее популярным является Oyente.

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

Архитектура Oyente показывает, что она принимает байт-код и представляет глобальное состояние Ethereum в качестве входных данных.

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

АУДИТ БЕЗОПАСНОСТИ

Мы начнем этот раздел с того места, где оставили предыдущий; ручные проверки.

Но сначала давайте поймем необходимость аудита безопасности; будь то взлом Ronin Network или взлом Poly Network, неаудированный код наиболее уязвим для взломов и эксплойтов.

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

Опять же, где найти этих профессиональных экспертов? Вам не нужно никуда идти в поисках надежных аудиторов; нажмите https://t.me/quillhash связаться с одним из них!

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

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

4. МОНИТОРИНГ И АНАЛИЗ

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

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

Мы можем выполнить; вознаграждение за обнаружение ошибок, мониторинг безопасности и постфактум анализ для преодоления этих барьеров.

ОШИБКИ

Поскольку мы рассматриваем проблемы безопасности после развертывания контрактов, Bug Bounty может быть полезным. Метод формальной верификации, рассмотренный ранее, представляет собой метод статического анализа. Bug bounty, с другой стороны, является методом динамического анализа.

Концепция Bug bounty проста; хакеры обнаруживают ошибки, а взамен получают денежное вознаграждение. Похоже на беспроигрышную ситуацию, верно? Но это не так!

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

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

Чтобы преодолеть это, была предложена система вознаграждений за ошибки, известная как «Гидра».

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

МОНИТОРИНГ БЕЗОПАСНОСТИ

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

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

Эти уязвимости, обнаруженные при анализе смарт-контрактов, можно назвать уязвимостями трассировки. Три типа контрактов лежат в основе этих уязвимостей трассировки;

(I) Жадные контракты (контракты, которые остаются в силе и блокируют эфир на неопределенный срок).

(II) Блудные контракты (контракты, которые небрежно сливают средства произвольным пользователям) и,

(III) Суицидальные контракты (контракты, которые может убить любой произвольный пользователь).

Было предложено даже понятие объектов Effectively Callback Free (ECF) для выявления уязвимостей путем мониторинга объектов ECF.

В контексте этого также был представлен онлайн-алгоритм; это помогло обнаружить неизвестные уязвимости. В том же предложении было предложено выполнить смарт-контракты в тестовой сети перед развертыванием в основной сети.

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

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

ПОСЛЕДУЮЩИЙ АНАЛИЗ

Post Hoc Analysis использует данные транзакций блокчейна для анализа, обнаружения или отслеживания потенциальных угроз в блокчейне с точки зрения непрофессионала.

Если мы обсудим анализ Graph, он был разработан как подход к сбору всех данных о транзакциях (включая внутренние транзакции из смарт-контрактов).

С помощью этих данных они построили три графика;

(I) График денежных потоков (MFG)

(II) График создания контракта (CCG) и,

(III) Граф вызова контракта (CIG)

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

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

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

*Структура интеллектуального обнаружения схемы Понци*

Ключ на вынос

Вот так, да, пока!

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

Мы попытались проанализировать безопасность смарт-контрактов с точки зрения жизненного цикла программного обеспечения.

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

Что вы думаете об этом гибком подходе SDLC к безопасности смарт-контрактов? Поделитесь своими мыслями в комментариях ниже!

46 Просмотры

сообщение Безопасность смарт-контрактов: подход Agile SDLC Появившийся сначала на Блог.quillhash.

Отметка времени: 22 апреля 2022