Тази статия е предоставена от общността. Автор е Минжи Хе, одитор в CertiK.
Мненията в тази статия са на сътрудника/автора и не отразяват непременно тези на Binance Academy.
Резюме
Блокчейн мостовете са критични за постигане на оперативна съвместимост в блокчейн пространството. Следователно сигурността на моста е от първостепенно значение. Някои често срещани уязвимости в сигурността на моста включват слабо валидиране в блокчейна и извън него, неправилно боравене със собствени токени и неправилни конфигурации. Препоръчва се тестване на моста срещу всички възможни вектори на атака, за да се гарантира надеждна логика за проверка.
Въведение
Блокчейн мостът е протокол, свързващ две блокчейн вериги, за да позволи взаимодействие между тях. Ако притежавате биткойн, но искате да участвате в DeFi дейност в мрежата Ethereum, блокчейн мостът ви позволява да го направите, без да продавате своя биткойн.
Блокчейн мостовете са фундаментални за постигане на оперативна съвместимост в блокчейн пространството. Те функционират с помощта на различни валидации в блокчейна и извън него и следователно имат различни уязвимости в сигурността.
Защо сигурността на моста е критична?
Мостът обикновено държи токена, който потребителят иска да прехвърли от един блокчейн към друг. Често внедрени като смарт договори, мостовете държат значително количество токени, тъй като трансферите между блокчейните се натрупват, което ги прави доходоносни цели за хакери.
В допълнение, блокчейн мостовете имат голяма повърхност за атака, тъй като включват много компоненти. Имайки предвид това, злонамерените участници са силно мотивирани да се насочат към междуверижни приложения, за да източат големи суми средства.
Мостовите атаки доведоха до загуби от над 1,3 млрд. USD през 2022 г., което представлява 36% от общите загуби за годината, според оценките на CertiK.
Често срещани уязвимости в сигурността на моста
За да подобрите сигурността на мостовете, е ценно да разберете често срещаните уязвимости в сигурността на мостовете и да тествате мостовете за тях преди стартиране. Тези уязвимости могат да бъдат категоризирани в следните четири области.
Слабо валидиране в блокчейна
За прости мостове, особено тези, предназначени за специфични DApp-ове, валидирането в блокчейна е сведено до минимум. Тези мостове разчитат на централизиран бекенд за изпълнение на основни операции като създаване, изгаряне и прехвърляне на токени, докато всички проверки се извършват извън блокчейна.
За разлика от тях, други видове мостове използват смарт договори за валидиране на съобщения и извършване на проверки в блокчейна. В този сценарий, когато потребител депозира средства в блокчейн, смарт договор генерира подписано съобщение и връща подписа в трансакцията. Този подпис служи като доказателство за депозита и се използва за проверка на заявката за теглене на потребителя в другия блокчейн. Този процес трябва да може да предотврати различни атаки срещу сигурността, включително атаки за повторение и фалшиви записи на депозити.
Въпреки това, ако има уязвимост по време на процеса на валидиране в блокчейна, нападателят може да причини сериозни щети. Например, ако мост използва дърво на Merkle за валидиране на записа на трансакцията, нападателят може да генерира подправени доказателства. Това означава, че той може да заобиколи валидирането на доказателство и да създаде нови токени в своя акаунт, ако процесът на валидиране е уязвим.
Някои мостове прилагат концепцията за „опаковани токени“. Например, когато потребител прехвърли DAI от Ethereum към BNB Chain, неговият DAI се взема от договора за Ethereum и еквивалентно количество опакован DAI се издава в BNB Chain.
Въпреки това, ако тази трансакция не е правилно валидирана, нападателят може да разположи злонамерен договор, за да насочи опакованите токени от моста към неправилен адрес чрез манипулиране на функцията.
Нападателите също така се нуждаят от жертви, за да одобрят договора за мост, за да прехвърлят токени, използвайки функцията „transferFrom“, за да източат активи от договора за мост.
За съжаление това се влошава, защото много мостове изискват безкрайно одобрение на токени от потребителите на DApp-ове. Това е обичайна практика, която намалява таксите за газ, но създава допълнителни рискове, като позволява на смарт договора да има достъп до неограничен брой токени от портфейла на потребителя. Нападателите могат да се възползват от липсата на валидиране и прекомерното одобрение, за да прехвърлят токени от други потребители към себе си.
Слабо валидиране извън блокчейна
В някои мостови системи бекенд сървърът извън блокчейна играе критична роля при проверката на легитимността на съобщенията, изпратени от блокчейна. В този случай ние се фокусираме върху проверката на депозитни трансакции.
Блокчейн мост с валидиране извън веригата работи по следния начин:
Потребителите взаимодействат с DApp, за да депозират токени в смарт договор на изходния блокчейн.
След това DApp-ът изпраща хеша на депозитната трансакция към бекенд сървъра чрез API.
Хешът на трансакцията подлежи на няколко проверки от сървъра. Ако се счита за легитимен, подписващият подписва съобщение и изпраща подписа обратно към потребителския интерфейс чрез API.
При получаване на подписа DApp-ът го проверява и позволява на потребителя да изтегли своите токени от изходния блокчейн.
Бекенд сървърът трябва да гарантира, че депозитната трансакция, която обработва, действително се е случила и не е подправена. Този бекенд сървър определя дали даден потребител може да изтегли токени от изходния блокчейн и следователно е цел с висока стойност за нападателите.
Бекенд сървърът трябва да потвърди структурата на излъченото събитие на трансакцията, както и адреса на договора, който е излъчил събитието. Ако последното бъде пренебрегнато, нападателят може да разположи злонамерен договор, за да фалшифицира депозитно събитие със същата структура като легитимно депозитно събитие.
Ако бекенд сървърът не провери кой адрес е излъчил събитието, той ще счита това за валидна трансакция и ще подпише съобщението. След това нападателят може да изпрати хеша на трансакцията до бекенда, заобикаляйки проверката и позволявайки му да изтегли токените от изходния блокчейн.
Неправилно боравене със собствени токени
Мостовете използват различни подходи към обработката на собствени токени и помощни токени. Например в мрежата Ethereum собственият токен е ETH и повечето помощни токени се придържат към стандарта ERC-20.
Когато потребител възнамерява да прехвърли своя ETH към друг блокчейн, той трябва първо да го депозира в мостовия договор. За да постигне това, потребителят просто прикачва ETH към трансакцията и количеството ETH може да бъде извлечено чрез четене на полето „msg.value“ на трансакцията.
Депозирането на токени ERC-20 се различава значително от депозирането на ETH. За да депозира токен ERC-20, потребителят трябва първо да позволи на мостовия договор да изразходва своите токени. След като той одобри това и депозира токените в мостовия договор, договорът или ще изгори токените на потребителя с помощта на функцията "burnFrom()", или ще прехвърли токена на потребителя в договора с помощта на функцията "transferFrom()".
Един подход за разграничаване на това е да се използва оператор if-else в рамките на същата функция. Друг подход е да се създадат две отделни функции за обработка на всеки сценарий. Опитът за депозиране на ETH чрез функцията за депозиране ERC-20 може да доведе до загуба на тези средства.
Когато обработват заявки за депозит ERC-20, потребителите обикновено предоставят адреса на токена като вход към функцията за депозит. Това представлява значителен риск, тъй като по време на трансакцията могат да възникнат ненадеждни външни повиквания. Внедряването на бял списък, който включва само токените, поддържани от моста, е обичайна практика за минимизиране на риска. Само адресите в белия списък могат да бъдат предавани като аргументи. Това предотвратява външни повиквания, тъй като екипът на проекта вече е филтрирал адреса на токена.
Проблеми обаче могат да възникнат и когато мостовете обработват междуверижно прехвърляне на собствен токен, тъй като собственият токен няма адрес. Нулев адрес (0x000...0) е представителен за собствения токен. Това може да бъде проблематично, тъй като предаването на нулевия адрес към функцията може да заобиколи проверката на белия списък, дори ако е внедрена неправилно.
Когато мостовият договор извиква „transferFrom“ за прехвърляне на потребителски активи към договора, външното извикване към нулевия адрес връща false, тъй като няма функция „transferFrom“, внедрена в нулевия адрес. Въпреки това, трансакцията все още може да се случи, ако договорът не обработва правилно върнатата стойност. Това създава възможност за нападателите да изпълнят трансакцията, без да прехвърлят токени към договора.
Неправилна конфигурация
В повечето блокчейн мостове привилегирована роля е отговорна за поставянето в бели или черни списъци на токени и адреси, задаване или промяна на подписващи лица и други критични конфигурации. Гарантирането, че всички конфигурации са точни е от решаващо значение, тъй като дори привидно тривиални пропуски могат да доведат до значителни загуби.
Всъщност имаше инцидент, при който нападателят успешно заобиколи проверката на записа за прехвърляне поради неправилна конфигурация. Екипът на проекта внедри надграждане на протокола няколко дни преди хака, което включваше промяна на променлива. Променливата беше използвана за представяне на стойността по подразбиране на надеждното съобщение. Тази промяна доведе до това, че всички съобщения автоматично се считат за доказани, което позволява на атакуващия да изпрати произволно съобщение и да премине процеса на проверка.
Как да подобрим сигурността на моста
Четирите общи уязвимости на моста, обяснени по-горе, демонстрират предизвикателствата пред осигуряването на сигурност във взаимосвързана блокчейн екосистема. Съществуват важни съображения за справяне с всяка от тези уязвимости и нито една инструкция не се прилага за всички тях.
Например предоставянето на общи насоки за осигуряване на процес на проверка без грешки е предизвикателство, тъй като всеки мост има уникални изисквания за проверка. Най-ефективният подход за предотвратяване на заобикаляне на проверката е да се тества щателно моста срещу всички възможни вектори на атака и да се гарантира, че логиката на проверка е стабилна.
За да обобщим, важно е да се извърши стриктно тестване срещу потенциални атаки и да се обърне специално внимание на най-честите уязвимости в сигурността на мостовете.
Заключителни мисли
Поради високата си стойност мостовете между блокчейни отдавна са мишена за нападатели. Разработчиците могат да подобрят сигурността на своите мостове, като проведат задълбочено тестване преди внедряването и се включат в одити от трети страни, намалявайки риска от опустошителните хакове, които измъчваха мостовете през последните няколко години. Мостовете са критични в многоверижния свят, но сигурността трябва да бъде основна грижа при проектирането и изграждането на ефективна Web3 инфраструктура.
Допълнителни статии
Какво е оперативна съвместимост между блокчейните?
Три популярни крипто моста и как работят
Какво представляват опакованите токени?
Отказ от отговорност и предупреждение за риск: Това съдържание ви се представя на база „както е“ само за обща информация и образователни цели, без твърдения или гаранция от какъвто и да е вид. Не трябва да се тълкува като финансов, правен или друг професионален съвет, нито има за цел да препоръча покупката на конкретен продукт или услуга. Трябва да потърсите собствен съвет от подходящи професионални съветници. Когато статията е предоставена от сътрудник трета страна, имайте предвид, че тези изразени мнения принадлежат на сътрудника трета страна и не отразяват непременно тези на Binance Academy. Моля, прочетете нашия пълен отказ от отговорност тук за повече подробности. Цените на цифровите активи могат да бъдат нестабилни. Стойността на вашата инвестиция може да намалее или да се повиши и може да не си върнете инвестираната сума. Вие носите цялата отговорност за вашите инвестиционни решения и Binance Academy не носи отговорност за каквито и да било загуби, които може да понесете. Този материал не трябва да се тълкува като финансов, правен или друг професионален съвет. За повече информация вижте нашите Условия за ползване и Предупреждението за риск.