Replay attack (atak powtórzeniowy, atak przez odtworzenie) polega na przechwyceniu ważnej, poprawnie podpisanej wiadomości – transakcji, zapytania do API albo podpisu – i ponownym jej użyciu w innym miejscu lub czasie. Atakujący niczego nie łamie ani nie podrabia. Wykorzystuje to, że system przyjmuje ten sam poprawny podpis drugi raz.
W krypto pojęcie pojawia się w trzech sytuacjach: przy podziale sieci przez hard fork, przy komunikacji z API giełd oraz przy podpisach w smart kontraktach.
Replay attack po hard forku
Gdy blockchain dzieli się na dwie sieci przez hard fork, obie mają wspólną historię i te same adresy z tymi samymi kluczami. Jeśli nowa sieć nie wprowadzi ochrony przed powtórzeniem (replay protection), transakcja podpisana w jednej sieci jest ważna także w drugiej. Ktoś może ją skopiować i rozgłosić w drugiej sieci – a wtedy wysyłasz środki w obu, choć chciałeś tylko w jednej.
Tak było po podziale Ethereum i Ethereum Classic w lipcu 2016 roku. Część użytkowników i giełd straciła środki, bo transakcje z jednej sieci były powtarzane w drugiej. Odpowiedzią było wprowadzenie identyfikatora sieci (chain ID) do podpisu transakcji w standardzie EIP-155 – od tej pory podpis jest ważny tylko w sieci o określonym identyfikatorze. Bitcoin Cash, oddzielony od Bitcoina w sierpniu 2017 roku, od początku miał wbudowaną ochronę przed powtórzeniem transakcji.
| Sytuacja | Ryzyko powtórzenia |
|---|---|
| Hard fork z ochroną przed powtórzeniem | niskie – transakcje są ważne tylko w jednej sieci |
| Hard fork bez ochrony | wysokie – transakcja może zostać wykonana w obu sieciach |
| Zwykła aktualizacja bez podziału sieci | brak – jest tylko jedna sieć |
Przykład: fork bez ochrony
Załóżmy, że masz na adresie 10 monet w sieci A. Po forku bez ochrony masz też 10 monet w nowej sieci B. Chcesz sprzedać tylko monety B, więc wysyłasz 10 B na giełdę. Ktoś kopiuje Twoją transakcję i rozgłasza ją w sieci A. Twoje 10 monet A również trafia na adres giełdy, choć tego nie planowałeś. Jeśli giełda nie obsługuje monet A albo przypisze je do innego konta, możesz ich nie odzyskać.
Dlatego po spornych forkach zaleca się poczekać, aż portfele i giełdy potwierdzą ochronę przed powtórzeniem, albo najpierw rozdzielić środki – przenieść je na nowe, osobne adresy w każdej sieci, zgodnie z instrukcjami portfela.
Replay attack w API giełd
Zapytania do API giełdy są podpisywane kluczem API. Gdyby giełda przyjmowała każde poprawnie podpisane zapytanie bez względu na czas, przechwycone zapytanie – np. zlecenie kupna – można by wysłać ponownie. Giełdy bronią się przed tym znacznikiem czasu i krótkim oknem ważności zapytania: podpis obejmuje timestamp, a zapytanie starsze niż kilka sekund jest odrzucane. Część systemów dodaje też jednorazowy numer (nonce), którego nie można użyć drugi raz. Dla Ciebie oznacza to przede wszystkim ochronę kluczy API i połączenia – korzystaj wyłącznie z szyfrowanego połączenia i nie udostępniaj logów zapytań.
Replay attack w smart kontraktach
W DeFi coraz częściej podpisujesz wiadomości zamiast transakcji – np. zgody na wydanie tokenów, zlecenia na giełdach z arkuszem zleceń albo podpisy do logowania. Dobrze zaprojektowany kontrakt dołącza do podpisu:
- nonce – numer, który rośnie po każdym użyciu, więc podpisu nie da się wykorzystać drugi raz,
- termin ważności – po nim podpis przestaje działać,
- identyfikator sieci i adres kontraktu – podpis działa tylko w jednej sieci i w jednym kontrakcie (tzw. separator domeny w standardzie EIP-712).
Błędy w tych zabezpieczeniach prowadziły do ataków, w których ten sam podpis wykorzystywano wielokrotnie albo w innej sieci. Użytkownik nie naprawi błędu w kontrakcie, ale może ograniczyć ryzyko: czytać, co podpisuje, unikać podpisów bez terminu ważności na dużych kwotach i nie podpisywać wiadomości na nieznanych stronach.
Najczęstsze błędy
- Przesyłanie środków tuż po spornym hard forku, zanim potwierdzona zostanie ochrona przed powtórzeniem.
- Założenie, że skoro monety są „na tym samym adresie”, to transakcje w obu sieciach są niezależne.
- Podpisywanie wiadomości w portfelu bez sprawdzenia, czego dotyczą i jak długo są ważne.
- Udostępnianie logów bota z podpisanymi zapytaniami do API.
Perspektywa tradera
Dla tradera replay attack jest ryzykiem przy forkach i airdropach. Przy spornych podziałach sieci giełdy często wstrzymują wpłaty i wypłaty, dopóki nie ma pewności co do ochrony przed powtórzeniem – to okres, w którym nie przerzucisz szybko środków między giełdami, więc arbitraż i zabezpieczanie pozycji bywają utrudnione. Najbezpieczniej zostawić monety na portfelu, nad którym masz kontrolę, poczekać na komunikaty portfela i giełd i dopiero potem je ruszać.
Najczęstsze pytania
Czy replay attack oznacza złamanie kryptografii?
Nie. Atakujący używa ważnego podpisu, który już istnieje. Problemem jest to, że system przyjmuje go ponownie albo w innej sieci.
Co to jest ochrona przed powtórzeniem (replay protection)?
Mechanizm, który sprawia, że transakcja jest ważna tylko w jednej sieci – np. przez identyfikator sieci w podpisie albo zmieniony sposób podpisywania transakcji w nowej sieci.
Czy zwykła aktualizacja sieci naraża mnie na replay attack?
Nie, jeśli sieć się nie dzieli. Ryzyko pojawia się, gdy po hard forku działają dwie sieci ze wspólną historią.
Jak chronić się przed replay attack po forku?
Poczekaj na potwierdzenie ochrony przed powtórzeniem przez twórców, portfele i giełdy, a przy braku ochrony rozdziel środki na nowe adresy w każdej sieci według instrukcji portfela.
Tekst ma charakter edukacyjny i nie stanowi rekomendacji inwestycyjnej.
