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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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