Що таке replay-атака?
Replay-атака — це атака, коли вже дійсну транзакцію або авторизацію повторно подають у систему, і вона виконується ще раз. Це схоже на ситуацію, коли копіюють підписаний документ і подають його на різних стійках для отримання кількох штампів.
У блокчейні підпис створюють за допомогою приватного ключа — це цифрова печатка, яка підтверджує: «Я дозволяю цю дію». Якщо підписану транзакцію можна розпізнати в інших контекстах, вона стає вразливою до повторного виконання (replay).
Щоб уникнути дублювання, у блокчейні використовують унікальний ідентифікатор — nonce. Nonce — це серійний номер для кожної операції, який не повторюється. Система приймає лише невикористані nonce.
У кросчейнових або форкованих середовищах також потрібен chainId. ChainId — це ідентифікатор мережі, який прив’язує транзакцію до певного ланцюга й не дозволяє повторно виконати її в іншому ланцюгу.
Чому виникають replay-атаки?
Replay-атаки відбуваються тоді, коли система не визначає чітко контекст дії. Контекст — це, до якого блокчейну належить дія, чи має вона унікальний ідентифікатор, чи вказано строк дії, або чи прив’язана до певного домену чи смартконтракту.
Якщо підпис підтверджує лише згоду на дію — без уточнення ланцюга, застосунку чи строку — будь-хто, хто має цей підпис, може використати його повторно деінде.
Якщо застосунок відстежує статус «використано/невикористано» лише локально або в кеші, а не у ланцюгу, здійснити replay-атаку простіше. Так само після форку, якщо обидва ланцюги мають однакові формати транзакцій і nonce, можлива кросчейнова replay-атака.
Як replay-атаки реалізують у блокчейні?
У replay-атаках в межах одного ланцюга зловмисник перехоплює повідомлення авторизації або спеціальну транзакцію та подає її повторно в тому ж ланцюгу. Це часто трапляється, коли офлайн-авторизації підпису не мають унікального nonce або позначки строку дії.
У кросчейнових replay-атаках транзакції чи повідомлення не мають прив’язки до chainId, або після форку обидва ланцюги приймають однаковий формат підпису. Зловмисник може виконати дійсну транзакцію з ланцюга A ще раз на ланцюгу B.
На рівні смартконтракту, якщо контракти не відстежують ідентифікатори оброблених повідомлень або не забезпечують ідемпотентність (тобто повторні виклики мають кумулятивний ефект), зловмисники можуть викликати операцію кілька разів, хоча мала бути лише одна дія.
Приклади replay-атак у реальному світі
У 2016 році в мережі Ethereum відбувся поділ ланцюга, у результаті з’явилися ETH і ETC. Оскільки ранні транзакції не розрізняли ланцюги, з’явився ризик кросчейнових replay-атак. У 2016 році запровадили EIP-155, який додав chainId до транзакцій і значно знизив кількість таких атак (див. історію Ethereum Improvement Proposal).
У сценаріях авторизації, якщо підписні дозволи на переказ або ліміти витрат не мають строку дії та унікального nonce, підписи можуть повторно подати. У 2020 році запровадили EIP-2612 для стандартизації підписної авторизації для ERC-20 токенів, що вимагає nonce і строку дії (див. Ethereum Improvement Proposal).
Якщо кросчейнові мости та протоколи обміну повідомленнями не призначають унікальні ідентифікатори й не відстежують використані повідомлення, replay-атаки можуть спричинити повторне створення чи випуск активів. Зараз індустрія знижує ці ризики за допомогою ідентифікаторів повідомлень і відстеження стану у ланцюгу.
Як виявити ознаки replay-атаки
Перевіряйте зміст кожного запиту на підпис. Якщо гаманець пропонує «сліпий підпис» (без чітких деталей транзакції, домену чи інформації про ланцюг), ризик replay-атаки вищий.
Перевіряйте, чи в авторизації є строк дії та унікальний nonce. Відсутність одного з них підвищує ризик.
Перевіряйте наявність явного контексту ланцюга. Якщо немає chainId або розділення домену (наприклад, у EIP-712), ризик replay-атаки в різних середовищах зростає.
Звертайте увагу на незвичайні повторні виконання — наприклад, одна й та сама авторизація використовується кілька разів, активи переказують неодноразово за короткий час або ідентичні повідомлення впливають на кілька ланцюгів.
Технічні заходи захисту від replay-атак
Крок 1. Прив’язуйте транзакції до контексту ланцюга. Використовуйте chainId з EIP-155, щоб обмежити кожну транзакцію її цільовим ланцюгом і запобігти кросчейновим replay-атакам.
Крок 2. Призначайте кожній авторизації унікальний nonce і строк дії. Стандарти EIP-2612 і Permit2 вимагають, щоб кожен підпис містив nonce і deadline; прострочені авторизації стають недійсними.
Крок 3. Фіксуйте використані повідомлення або nonce у смартконтрактах. Кожне повідомлення повинно мати невідновлюваний ідентифікатор, а його стан використання зберігатися у ланцюгу для ідемпотентної обробки.
Крок 4. Використовуйте структуровані підписи згідно EIP-712. Підпис має містити доменне ім’я (verifyingContract, name, version), chainId і зрозумілий зміст, щоб мінімізувати ризики зловживання та повторного виконання.
Крок 5. Впроваджуйте двосторонню перевірку у кросчейнових мостах і каналах повідомлень. Перевіряйте не лише джерело й цільовий ланцюг, а й унікальність повідомлення, номери пакетів і статус обробки, щоб уникнути повторного виконання через різні маршрути.
Як користувачам уникати replay-атак у щоденних операціях?
Крок 1. Підписуйте лише на інтерфейсах із чіткими деталями. Відхиляйте сліпі підписи — переконайтесь, що у запиті є домен, інформація про ланцюг і опис мети.
Крок 2. Встановлюйте межі для авторизацій. Обирайте дозволи з обмеженим терміном і лімітом; регулярно відкликайте невикористані дозволи через блокчейн-експлорери або інструменти керування. Під час виведення коштів з бірж на кшталт Gate завжди перевіряйте правильність мережі та адреси, щоб уникнути помилок між середовищами.
Крок 3. Відокремлюйте основні кошти від робочих гаманців. Зберігайте основні активи у апаратних гаманцях чи гаманцях лише для перегляду; для взаємодії з DApps використовуйте гарячі гаманці з невеликими сумами, щоб мінімізувати втрати через повторні авторизації.
Крок 4. Користуйтесь адресними книгами та білими списками. Зберігайте часто використовувані адреси з примітками у адресній книзі Gate та активуйте білі списки для виведення, щоб зменшити ризики помилкових дій або фішингових підписів, які призводять до повторних подань.
Крок 5. Слідкуйте за аномальною активністю. Якщо помітили повторювані транзакції чи авторизації за короткий час, негайно призупиніть операції, відкличте дозволи й перевірте безпеку пристрою та розширень.
Чим replay-атака відрізняється від double-spend або Sybil-атаки?
Replay-атака — це повторне подання тієї ж дійсної транзакції чи авторизації, тобто проблема — у повторному виконанні. Double-spend — це спроба витратити один і той самий актив двічі, часто із залученням механізмів консенсусу та перебудови блоків, тобто це інший рівень протоколу.
Sybil-атака — це використання багатьох ідентичностей для імітації багатьох користувачів із метою маніпуляції голосуванням або розподілом; це не стосується повторення транзакцій, а пов’язане з рівнем ідентичності. Replay-атаки відбуваються на рівні транзакцій або повідомлень.
Крім того, атаки «man-in-the-middle» зазвичай змінюють дані або маршрутизацію; replay-атаки можуть не змінювати зміст, а лише повторно подавати ідентичні дані.
Як replay-атаки еволюціонують у Web3?
Після впровадження chainId у EIP-155 у 2016 році кросчейнові replay-атаки різко зменшилися. EIP-2612 (2020) і Permit2 стандартизували nonce і строк дії для підписних дозволів. До 2025 року, із зростанням мультичейнових і Layer 2 мереж, канали повідомлень, anti-replay ID та ідемпотентний дизайн стають основою інфраструктури.
Абстракція акаунтів (наприклад, ERC-4337) впроваджує доменне управління nonce і стратегії — використання різних nonce для різних операцій знижує внутрішньодоменний ризик повторного виконання. Кросчейнові мости зараз приділяють увагу перевірці джерела й унікальному відстеженню повідомлень, щоб обмежити повторне виконання.
Підсумок replay-атаки та рекомендовані дії
Суть replay-атаки — це повторне виконання дійсного змісту у неправильному контексті. Рішення — чітко визначати контекст: ідентифікатори ланцюга, унікальні nonce, строки дії, прив’язка до домену і завжди фіксувати використані стани у ланцюгу. Для розробників: впроваджуйте EIP-155, EIP-712, EIP-2612/Permit2 і ідемпотентний дизайн. Для користувачів: уникайте сліпих підписів, використовуйте авторизації з обмеженим терміном, розділяйте гаманці за функціями й активуйте білі списки на біржах. Якщо бачите аномальне повторення, пов’язане з коштами, зупиніть операції та відкличте дозволи.
FAQ
Чи можуть replay-атаки призвести до втрати моїх активів?
Replay-атаки не крадуть ваші активи напряму, але можуть спричинити повторні шкідливі транзакції. Наприклад, якщо ви переводите 100 токенів у ланцюгу A, а зловмисник повторно виконає цю транзакцію в ланцюгу B, ви втратите кошти на обох ланцюгах. Головний захист — використовувати гаманці з перевіркою chain ID і бути уважним під час кросчейнових операцій.
Чи потрібно хвилюватися щодо replay-атак під час торгівлі на Gate?
Централізовані біржі, такі як Gate, мають кілька рівнів безпеки. Звичайні користувачі практично не ризикують стати жертвами replay-атак під час торгівлі на платформі. Основний ризик виникає під час кросчейнових переказів із гаманців самостійного зберігання. Для спотової чи деривативної торгівлі на Gate ризики контролює платформа.
Чи можуть великі події, наприклад об’єднання Binance, спричинити масштабні replay-атаки?
Великі зміни в екосистемі (наприклад, об’єднання ланцюгів або форки) дійсно підвищують ризик replay-атак. Проте проєкти зазвичай впроваджують захист, наприклад, оновлюють chain ID завчасно. Як користувач, завжди чекайте офіційних оголошень перед кросчейновими операціями під час переходу, щоб не стати мішенню.
Якщо мій приватний ключ скомпрометовано, чи погіршить replay-атака втрати?
Витік приватного ключа вже є серйозною загрозою безпеці. Replay-атака погіршує ситуацію, дозволяючи зловмиснику переміщувати активи не лише в одному ланцюгу, а й повторно виконувати транзакції на кількох ланцюгах — це може призвести до втрати всіх активів. Негайно переведіть кошти на новий гаманець — це єдиний спосіб захисту.
Як EIP-155 допомагає запобігти replay-атакам?
EIP-155 запровадив механізм chain ID, тому кожна транзакція містить унікальний ідентифікатор мережі й не може виконуватись в інших ланцюгах. Сучасні мережі Ethereum та сумісні ланцюги вже впровадили цей стандарт, тому більшість replay-атак неможливі. Вибір гаманця з підтримкою EIP-155 — найпростіший спосіб захисту для користувачів.
