Кто есть кто среди угроз для приложений на блокчейне

Кто есть кто среди угроз для приложений на блокчейне

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

В этой связи представитель компании BugBounty.Center Григорий Васильков провел анализ некоторых рисков безопасности для компаний, базирующихся на блокчейне. Итак, поехали.

Невозможность определить изменение стоимости

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

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

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

Способ устранения: За изменениями в стоимости активов необходимо все время следить, соответственно ситуации внося изменения в смарт-контракт. Если последний на большом отрезке времени автономен, то вышеупомянутый вариант не всегда сработает и стоит искать другой способ решения вопроса.

Задержка получения информации

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

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

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

Кто есть кто среди угроз для приложений на блокчейне

Несоответствие полученных данных

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

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

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

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

Зависимость выполнения работы смарт-контрактов от других смарт-контрактов

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

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

Способ устранения: Если вы не управляете сторонним контрактом (что вероятнее всего), то не нужно на него полностью полагаться. К тому же, даже если в коде смарт-контракта нет вызова операции selfdestruct, то вероятность ее выполнения все равно существует (используя, например, callcode либо delegatecall).

Сложность прогнозировать и влиять на входящие данные

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

Пример: Допустим, смарт-контракт (децентрализованный обменный сервис) обратился к бирже, чтобы получить текущий курс валюты либо токенов. В свою очередь, хакер предпримет попытку считать эту транзакцию в Memory Pool и попробовать на небольшой промежуток времени изменить курс, запрашиваемый смарт-контрактом. Стоит контракту внести полученную стоимость курса в блокчейн, хакер произведет обмен по нужной ему цене.

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

Раскрытие и влияние собственных данных на результат работы

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

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

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

Подписаться на Telegram-канал Coinsider.

Похожие статьи