Повтор атаки

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

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

Вот несколько стратегий предотвращения атак повторного воспроизведения:

1. Одноразовый (счетчик)： Каждая транзакция или запрос должны содержать значение nonce, которое представляет собой монотонно возрастающее целое число, связанное с учетной записью отправителя. В смарт-контракте при каждой отправке транзакции значение nonce увеличивается, обеспечивая уникальность каждой транзакции. Контракт проверяет nonce при обработке транзакции, и транзакция будет принята только в том случае, если значение nonce соответствует ожидаемому значению nonce учетной записи отправителя.
2. Временная метка： Временная, содержащая транзакцию метка, а затем установить разумный период окна в контракте и принимать транзакции только в течение этого периода окна. Это предотвращает повторное воспроизведение устаревших транзакций.
3. Используйте случайные числа： Добавление к транзакции случайного числа (часто называемого «вызовом» или «nonce») делает каждую транзакцию уникальной и не может быть воспроизведено, даже если она будет перехвачена.
4. проверка статуса： Перед совершением сделки смарт-контракт может проверить свой внутренний статус, чтобы убедиться, что торговые условия все еще действительны. Например, если транзакция предполагает перевод средств, контракт может проверить, достаточен ли баланс.
5. Цифровые подписи и Временная метка Служить： Используйте цифровые подписи для подтверждения происхождения транзакций в сочетании с Временной метка Служить для проверки свежести транзакции.
6. События и слушатели： После выполнения транзакции смарт-контракт может выдавать событие, а другие контракты или прослушиватели могут прослушивать эти события и соответствующим образом обновлять свой собственный статус, чтобы предотвратить повторное воспроизведение той же транзакции.
7. Двойное согласие： Требование от пользователей или систем выполнить вторичное подтверждение перед выполнением транзакции (это может быть человеческий или автоматизированный процесс) гарантирует, что цель транзакции не была изменена.

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

Демонстрационный случай

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

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

pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract TokenSpender {
    IERC20 public token;
    
    mapping(bytes32 => bool) public usedSignatures;

    constructor(address _tokenAddress) {
        token = IERC20(_tokenAddress);
    }

    function spendTokens(address spender, uint amount, bytes memory signature) public {
        bytes32 messageHash = keccak256(abi.encodePacked(msg.sender, spender, amount));
        
        // Проверьте, использовалась ли подпись уже
        require(!usedSignatures[messageHash], "Signature already used");

        // Подтвердить подпись
        address signer = recoverSigner(messageHash, signature);
        require(signer == msg.sender, "Invalid signature");

        // Отметить подпись как использованную
        usedSignatures[messageHash] = true;

        // тратить жетоны
        token.transferFrom(msg.sender, spender, amount);
    }

    function recoverSigner(bytes32 message, bytes memory sig) internal pure returns (address) {
        bytes32 r;
        bytes32 s;
        uint8 v;

        // Do some checks on the signature's length to catch common errors
        require(sig.length == 65);

        // Divide the signature into r, s and v values
        assembly {
            r := mload(add(sig, 32))
            s := mload(add(sig, 64))
            v := byte(0, mload(add(sig, 96)))
        }

        if (v < 27) {
            v += 27;
        }

        // Now we have the signature parameters. Just recover the public key and return the address
        return ecrecover(message, v, r, s);
    }
}

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

Чтобы предотвратить атаки повторного воспроизведения, мы используем отображение usedSignatures для отслеживания того, какие подписи были использованы. Когда подпись отправляется, мы проверяем, была ли она уже помечена как использованная. Если нет, проверяем валидность подписи, отмечаем подпись как использованную и выполняем операцию передачи.

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

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