Replay-attack
Атака, при которой злоумышленник повторно отправляет ранее подписанную транзакцию, рассчитывая, что она исполнится снова. В TON предотвращается счётчиком seqno в wallet-контракте — каждая подпись валидна только при определённом значении.
Синонимы: replay attack, повторная атака, replay-атака
Replay-attack — атака, при которой злоумышленник перехватывает или находит публично доступную подписанную транзакцию и пытается отправить её повторно, чтобы она исполнилась дважды. В правильно спроектированном протоколе это невозможно: каждая транзакция привязана к уникальному состоянию и после исполнения не может быть применена снова.
Защита в TON
В TON replay невозможен благодаря seqno (sequence number) в wallet-контракте:
- Контракт хранит счётчик seqno в своих данных.
- Каждая внешняя транзакция включает seqno в подписываемое сообщение.
- Контракт проверяет: подписанный seqno = текущий seqno в state? Если да — исполнить, инкрементировать. Если нет — отвергнуть.
После исполнения транзакции с seqno = N контракт ждёт следующую с seqno = N+1. Любая попытка переиграть транзакцию с N будет отклонена.
Где это становится проблемой
Replay actually опасен в нескольких сценариях:
- Кросс-чейн bridges. Транзакция, валидная в одной сети, может быть переотправлена в другую (например, форк). Защита — chain ID или domain separator в подписи.
- Подписи вне транзакций. Если dApp просит подписать «proof of ownership» без привязки к timestamp или nonce, атакующий может переиспользовать подпись на другом сайте. Поэтому TON Connect signatures всегда включают домен и timestamp.
- Старые версии контрактов. Wallet v1 без seqno (или с предсказуемым) теоретически уязвим — поэтому давно не используется. Все актуальные версии (v3, v4, v5) включают seqno.
Highload-кошельки
У Highload Wallet — специального контракта для бирж и автоматизированных систем — вместо seqno используется query_id + timeout. Это позволяет отправлять параллельные транзакции (seqno-схема ограничивает один-за-другим). Каждый query_id используется только раз; защита от replay сохраняется, но реализация другая.
В классической безопасности
Концепция replay-attack шире, чем блокчейн. Например, перехват и переотправка cookie сессии — тоже replay, и защита аналогичная: уникальные nonce, timestamp, ограниченные time-to-live токенов. В блокчейне просто всё это формализовано в протоколе.
Что делать пользователю
Самостоятельно защищаться от replay не нужно — защита встроена в кошельки. Главное — не использовать кустарные old-style контракты и не подписывать «голые» сообщения без контекста (домен, timestamp, nonce). При работе с TON Connect это делается автоматически; ручной экспорт ключа в скрипты-боты — потенциальная зона риска.