Обзор методологической безопасности интеллектуального контракта

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

например. для каждой функции, которую вы просматриваете

  • Есть ли возможность повторного входа и как он ведет себя при повторном входе

  • Как он себя ведет, если циклы заканчиваются газом

  • Как он себя ведет, если предел стека достигает

... и т. д.

Если такой инструмент недоступен, есть ли хороший источник или список для всех известных способов отказа от безопасной безопасности транзакций Ethereum?

18 голосов | спросил Mikko Ohtamaa 6 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 06 Sep 2016 22:09:12 +0300 2016, 22:09:12

2 ответа


15

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

Это список потенциальных атак или неправильных практик, позволяющих только эти атаки. Дополнительные ресурсы для передового опыта интеллектуальных контрактов см. В разделе «Ресурсы» в конце ответа.

Правильное использование модификаторов видимости функций

Внутренние функции помечены как таковые, и только соответствующий автор может вызвать функцию.

См. Разница в палитре кошельков .

Атака стека вызовов

Синонимы: Shallow stack attack, stack attack

Предпосылки: Функции используют send() или call()

Вызов: злоумышленник манипулирует стеком вызовов межконтрактного вызова для вызова () для отказа, вызывая контракт с стеком 1023.

Защита: всегда проверяйте возвращаемое значение send () и call (). Предпочтительно someAddress.send() over someAddress.call.value()

Дополнительная информация

Атака повторного входа

Синонимы: состояние гонки

Предпосылки: Функции используют send() или call()

Вызов: ненадежный вызываемый контракт вызывает ту же функцию обратно, имея ее в неожиданном состоянии. Вот как взломали TheDAO. Атака может быть привязана к нескольким функциям (условие гонки кросс-функций).

Защита: убедитесь, что перед выполнением вызова call() или send()

выполняются обновления внутреннего состояния и баланса в функции)

Дополнительная информация

DoS с непредвиденным броском

Предварительные требования: функции используют send() или call() с броском после сбоя

Вызов: злоумышленник манипулирует контрактным состоянием, чтобы send() всегда терпел неудачу (например, возврат)

Защита: Предпочитаете вытягивать систему оплаты через send()

Дополнительная информация

Вредоносные библиотеки

Предварительные требования: использование внешнего контракта в качестве библиотеки и получение его через реестр.

Вызов: вызов другой функции контракта через реестр контрактов (см. ключевое слово library в Solidity).

Защита: убедитесь, что динамические части не могут быть заменены в будущих версиях.

Переполнение целых чисел

Предварительные требования: Функция принимает аргумент uint с использованием в математике

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

Защита: всегда проверяйте порядок значений при выполнении математических операций. Например. https://github.com/Firstbloodio/token/blob/master/smart_contract /FirstBloodToken.sol

Дополнительная информация

Деление целых чисел

Предпосылки: Платежная логика требует оператора деления /

Вызов: ошибка программиста

Защита: знатьчто дивизии всегда округлены вниз

Длина петли и манипуляция с газом

Другие: выделение слишком малой int для массивов

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

Вызов: злоумышленник увеличивает длину массива или управляет пределом газового потока

Защита: использование платежных систем типа pull. Спред send() по нескольким транзакциям и проверить префикс msg.gas.

Резервная функция, потребляющая больше, чем предел 2300 газа

Пререквизиты: контракт на Solidity с функцией catch all () {} для получения общих отправок

Вызов: ошибка программиста

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

Дополнительная информация:

Обновление принудительного баланса

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

Вызов: selfdestruct (contractaddress) может принудительно обновить его баланс

Защита: не доверяйте этому. равновесие, чтобы оставаться в заданных пределах

Подробнее

Зависимость порядка транзакций

Синонимы: TOD

Предпосылки: рынок стиля ставок

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

Защита: схемы предварительной фиксации

Подробнее

Ресурсы

ответил Alexandre Van de Sande 22 PMpFri, 22 Apr 2016 22:24:11 +030024Friday 2016, 22:24:11
1

Devcon2: безопасность смарт-контракта Выступающие: Кристоф Джентш

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

ссылка Youtube

Другой,

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

Это ссылка на бумагу

Источник Coindesk.

ответил Ozan Yurtseven 8 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 08 Sep 2016 20:22:50 +0300 2016, 20:22:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132