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

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

читають: 0

Час читання: 10 протокол

Блокчейн цитується як децентралізована та захищена від несанкціонованого доступу книга. Але ця захищена від несанкціонованого доступу книга є вразливою для злому та експлойтів. Децентралізація, яка є однією з найсильніших переваг блокчейну, є одним із недоліків.

Ну, це добре, але як щодо SDLC?

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

У першому розділі ми виклали питання безпеки в смарт-контрактах. І в наступному розділі ми обговорюємо його рішення, поділені на чотири етапи; Проектування безпеки, впровадження безпеки, тестування перед розгортанням і останній, моніторинг та аналіз.

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

Смарт-контракти вразливі до різних злому та експлойтів. Ці контракти, які є синонімами реальних юридичних угод, діють незалежно на основі умов рідних блокчейнів.

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

децентралізація: Вважається однією з переваг протоколів на основі блокчейну. Але зловмисники придумали спосіб перетворити цю позитивну рису на негативну.

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

Код з відкритим вихідним кодом: Це може вас здивувати, але так, загалом більшість кодів смарт-контрактів є дещо відкритим вихідним кодом.

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

Нерозвинені блокчейн-платформи: Для розробника головною вимогою є ознайомлення з платформою розробки. Існує багато недорозвинених або нових платформ блокчейну, тому розробники не можуть отримати глибокі знання про операції на блокчейні.

Ця невідповідність впливає на розумні контракти через відсутність синхронізації. Недоліки платформи блокчейн залишаються непоміченими через її безперервну еволюцію.

Невідомі транзакції: У першому пункті ми обговорювали анонімну особистість; так само, транзакції на блокчейнах не розголошуються. Неможливо відстежити операції, що призводять до багатьох незаконних дій. Оскільки це стосується фінансових операцій, будь-яка проблема безпеки може призвести до величезних фінансових втрат.

РІШЕННЯ З БЕЗПЕКИ ДОГОВОРУ

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

Життєвий цикл розробки смарт-контракту можна розділити на чотири фази: проектування безпеки, впровадження безпеки, тестування перед розгортанням, моніторинг та аналіз.

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

1. ДИЗАЙН БЕЗПЕКИ

Цей перший етап містить три теми; принцип проектування, шаблон проектування та моделювання безпеки (як показано на малюнку вище). Основна увага в цих темах приділяється розробці контрактів і тому, як можна запобігти загрозам безпеки.

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

Принципи проектування є основними ідеями для розробки безпечних смарт-контрактів на блокчейні. Існує п’ять основних принципів розробки контрактів: підготуватися до збою, обережно розгорнути, зберегти контракти простими, залишатися в курсі та обов’язково знати про властивості блокчейну.

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

Давайте візьмемо будь-який із принципів зверху, скажімо, «Готуйтеся до збою», це означає, що за відсутності схем виправлення контракт повинен мати можливість реагувати на помилки. І якщо відбудеться будь-яка атака, контракт повинен мати можливість призупинити, щоб запобігти подальшим збиткам.

ДИЗАЙН ВАЗОР

У розробці програмного забезпечення шаблони проектування — це рішення, які можна повторно використовувати для вирішення проблеми.

Якщо взяти приклад Ethereum, то існує шість шаблонів безпеки; Перевірка-ефекти-взаємодія, аварійна зупинка, мьютекс, різниця швидкості, обмеження швидкості та обмеження балансу.

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

У той же час шаблон аварійної зупинки може допомогти нам припинити виконання контракту, якщо на нього впливає вразливість.

МОДЕЛЮВАННЯ БЕЗПЕКИ

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

На малюнку вище показано, що ця підфаза охоплює дві фази; проектування та впровадження безпеки.

Моделювання безпеки безпосередньо пов'язане з бізнес-логікою; оскільки специфікації є похідними від бізнесу, логіку можна класифікувати за безпомилковою семантикою. Це допомагає пізніше під час офіційного процесу перевірки, що виконується для пом’якшення вразливостей.

2. РЕАЛІЗАЦІЯ БЕЗПЕКИ

У цьому розділі ми розглянемо дві з трьох тем; безпеки

Розробка та шаблон безпеки, як ми вже розглянули моделювання безпеки на останньому етапі.

РОЗВИТОК БЕЗПЕКИ

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

На платформі Ethereum ми маємо EIPs безпеки (пропозиції щодо покращення Ethereum) – рекомендації для боротьби з проблемами безпеки на Ethereum платформа. Таким чином, ці EIP заслуговують на увагу для безпечної реалізації смарт-контрактів.

ШАБЛОН БЕЗПЕКИ

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

У контексті безпеки смарт-контрактів можна отримати стандартні шаблони контрактів з оновленими параметрами безпеки, такими як шаблони безпеки та бібліотеки безпеки. Це зменшить ймовірність помилок при ручному кодуванні.

3. ТЕСТУВАННЯ ПЕРЕД РОЗКРИВАННЯМ

Знову ж таки, вимога цієї фази випливає з однієї з переваг смарт-контрактів – «незмінності».

Після створення смарт-контрактів неможливо змінити їх. Тому перед розгортанням необхідно провести достатню кількість тестів для забезпечення безпеки смарт-контрактів.

Цей етап охоплює три параметри безпеки, яких слід дотримуватися перед розгортанням смарт-контракту; Сувора офіційна перевірка, інструменти аналізу коду та аудит безпеки.

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

Формальна перевірка — це чітко визначений процес, який використовує математичні міркування та математичні докази для перевірки бажаних властивостей системи.

Ми можемо провести офіційну перевірку смарт-контрактів, оскільки контрактна програма коротка та обмежена часом. Існує кілька способів жорсткої формалізації та перевірки смарт-контрактів; деякі засновані на коді контракту, а інші на семантиці віртуальної машини Ethereum (EVM).

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

Аналіз коду виконується без виконання програм. Для цього ми використовуємо деякі інструменти, які називаються інструментами статичного тестування безпеки додатків (SAST). Ці інструменти допомагають виявити недоліки безпеки у вихідному коді.

Аналіз, який виконується цими інструментами, може включати один або всі з наступних кроків:

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

(II) Доповнюйте ІР достатньою інформацією, отриманою від статичного контролю або аналізу потоку дат і методів формальної перевірки; ці техніки включають: символічне виконання, абстрактну інтерпретацію та перевірку символічної моделі.

Але які інструменти можна використовувати для аналізу коду на Smart Contract?

Хоча існує багато інструментів, які можна використовувати для аналізу безпеки, Oyente є найпопулярнішим.

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

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

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

АУДИТ БЕЗПЕКИ

Ми почнемо цей розділ там, де залишили попередній; ручні перевірки.

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

Вони призводять до великих фінансових втрат. Власне кажучи, має значення не тільки аудит вашого проекту Web3, але й його перевірка експертами-професіоналами, оскільки це залежить від професійної здатності аудиторів проводити аудит безпеки.

Знову ж таки, де знайти цих професійних експертів? Вам не потрібно нікуди йти в пошуках надійних аудиторів; клацніть https://t.me/quillhash щоб зв'язатися з одним із них!

Ідеальний аудит смарт-контракту — це комбінація ручного та автоматичного аналізу коду; як ми обговорювали в попередньому пункті, навіть якщо після автоматизованого аналізу коду за допомогою таких інструментів, як Oyente, у контракті є ймовірність виявлення невизначених уразливостей.

Таким чином, щоб подолати це, аудитори безпеки можуть вручну проаналізувати кожен рядок коду та перевірити їх на наявність потенційних вразливостей.

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

Пам’ятаєте принцип блокчейна, який постійно розвивається, який ми обговорювали спочатку?

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

Ми можемо виконати; винагорода за помилки, моніторинг безпеки та спеціальний аналіз для подолання цих бар’єрів.

БАГОНІ

Оскільки ми розглядаємо питання безпеки після розгортання з контрактами, Bug Bounties можуть бути корисними. Формальна методика верифікації, розглянута раніше, є методом статичного аналізу. Bug bounty, з іншого боку, є технікою динамічного аналізу.

Концепція Bug bounty проста; хакери виявляють помилки, і натомість вони отримують певну фінансову винагороду. Виглядає як безпрограшна ситуація, чи не так? Але це не так!

Заковика тут є; що вартість помилок може бути вищою, ніж винагорода на сірих ринках, і ймовірно, що хакери можуть використовувати або продавати помилки, щоб отримати високу ціну.

Іноді власники проекту заперечують виплату винагороди, якщо помилки не підтверджуються; Хакери також турбуються про невизначеність платежів після виявлення помилок.

Щоб подолати це, було запропоновано систему пошуку помилок, відому як «Hydra».

Hydra використовує технологію розриву експлойтів під назвою N-of-N-version programming (NNVP) як систему винагороди за помилки в блокчейні.

МОНІТОРИНГ БЕЗПЕКИ

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

Але щоб знайти помилки та потенційні вразливості в режимі реального часу, ми повинні відстежувати та аналізувати дані транзакцій у блокчейні.

Ці вразливості, виявлені під час аналізу смарт-контрактів, можна назвати вразливістю трасування. Три типи контрактів лежать у центрі цих трасувальних вразливостей;

(I) Жадібні контракти (контракти, які залишаються живими і блокують ефір на невизначений термін).

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

(Iii) Суїцидальні контракти (контракти, які будь-який довільний користувач може вбити).

Навіть поняття об’єктів Effectively Callback Free (ECF) було запропоновано для виявлення вразливостей шляхом моніторингу об’єктів ECF.

У контексті цього був також представлений онлайн-алгоритм; це допомогло виявити невідомі вразливості. У тій же пропозиції було запропоновано виконувати розумні контракти в Testnet перед розгортанням в Mainnet.

Інтерфейс моніторингу – це платформа моніторингу блокчейн, яка використовує React.js. Цю платформу можна використовувати для здійснення транзакцій, перевірки активів і запиту про стан блокчейну.

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

АНАЛІЗ POST HOC

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

Якщо ми обговорюємо аналіз Graph, то він був розроблений як підхід до збору всіх даних транзакцій (це включало внутрішні транзакції з смарт-контрактів).

За допомогою цих даних вони підготували три графіки;

(I) Графік грошового потоку (MFG)

(II) графік створення контракту (CCG) і,

(Iii) Граф виклику контракту (CIG)

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

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

Цей механізм використовує аналіз даних і машинне навчання для виявлення контрактів Понці. Цей процес працює, навіть якщо вихідний код смарт-контрактів недоступний.

*Структура виявлення розумної схеми Понці*

Ключовий винос

Ось і все, так, поки що все!

Якби ви були з нами досі, ми будемо вдячні. Не розтягуючи більше, на завершення скажемо лише, що екосистема смарт-контрактів децентралізована, і її важко виправити на наявність помилок.

Ми спробували розібратися з безпекою смарт-контрактів з точки зору життєвого циклу програмного забезпечення.

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

Що ви думаєте про цей гнучкий підхід SDLC для безпеки смарт-контрактів? Поділіться своїми думками в коментарях нижче!

46 думки

Повідомлення Безпека смарт-контрактів: Agile SDLC-підхід вперше з'явився на Блог.quillhash.

Часова мітка: Квітень 22, 2022