Dlaczego portfel można opróżnić „bez podpisu”
Cel tego przewodnika: wyjaśnij, jak działają uprawnienia
(zatwierdzenie jest aktem nadania uprawnień, allowance to zarejestrowany limit wydatków),
rozbij główny
EVM to grupa kompatybilnych sieci blockchain, które korzystają z tych samych zasad realizacji inteligentnych kontraktów,
gdzie zarządzanie tokenami i NFT opiera się na systemie uprawnień.
W tych sieciach approve, allowance i
Główną luką jest oczekiwanie, że każdy wydatek będzie wymagał osobnego podpisu. W interfejsie portfela podpis wygląda jak zwykły krok („zezwól”, „połącz”, „potwierdź wymianę”), więc użytkownik nie potwierdza przeniesienia, ale przyznanie praw które są przechowywane w umowie i wykorzystywane później bez kolejnego okna potwierdzenia.
Niepotrzebny allowance
(limit zapisany w umowie określający ile tokenów można wydać)
na monetę typu stablecoin lub aktywną
Jeśli oceniasz ryzyko DeFi szerzej niż zatwierdzenia, dodaj osobne powierzchnie ataku do swojej listy kontrolnej: dApp frontendy, mosty, MEV, klucze i błędy operacyjne. Przewodnik bezpieczeństwa DeFi: mapa zagrożeń i lista kontrolna .
Wyłudzanie informacji w celu zatwierdzenia wykorzystuje uprawnienia poprzez approve/permit
(tworzenie lub zmiana allowance)
lub
Jeden podpis approve/permit lub
Czym jest phishing zatwierdzeniowy i dlaczego jego „uczciwość” jest nieuczciwa
Kluczowe terminy w tej sekcji:
-
Wydający to adres inteligentnego kontraktu, na który można wydawać tokeny ERC-20 właściciela
w ramach allowance do
transferFrom . -
Operatora to adres, który otrzymał prawo do przeniesienia NFTs właściciela
setApprovalForAll , bez limitu ilości tokenów kolekcjonerskich. - Zasiłek to wartość w kontrakcie ERC-20, która definiuje maksymalną liczbę tokenów spender może wydać.
- Revoke to transakcja resetująca allowance lub wyłączająca operator, wygaśnięcie prawa do wydawania lub przenoszenia majątku.
Phishing zatwierdzający wykorzystuje normalne mechanizmy uzyskiwania uprawnień: przyznanie praw wygląda na zgodne z prawem, nie powoduje natychmiastowej utraty środków i dlatego często nie jest postrzegane jako ryzyko w momencie podpisywania.
Phishing zatwierdzający to atak, podczas którego użytkownik zostaje nakłoniony do udzielenia zgody pozwolenie (zatwierdzenie/allowance) do zarządzania tokenami lub NFTs, a uprawnienie to jest następnie wykorzystywane do wycofywania aktywów. Niebezpieczna akcja jest maskowana jako znajomy krok interfejsu: „potwierdź wymianę”, „zezwól na wymianę”, „podpisz roszczenie”, „udziel dostępu do depozytu”.
W przeciwieństwie do kradzieży klucza, atakujący nie potrzebuje klucza prywatnego i nie potrzebuje bezpośredniego transferu środków. Wystarczy, że użytkownik to zrobi raz przyznaj określonemu adresowi prawo do wydawania zasobów: spender dla tokenów ERC-20 lub operator dla NFTs. Następnie wypłata odbywa się bez nowych okien portfela i bez wielokrotnych potwierdzeń przez właściciela.
Na poziomie blockchain transakcje wyglądają na prawidłowe: użytkownik rzeczywiście zmienił stan umowy i przyznał uprawnienia do konkretnego adresu. Dlatego portfel nie jest formalnie „zhakowany”: aktywa wychodzą poprzez wcześniej przyznane uprawnienia, a nie przez obejście podpisu.
Approve zwykle nie przenosi środki natychmiast. Rejestruje limit allowance w umowie tokena, po przekroczeniu którego spender może wywołać
Choć równowaga się nie zmieniła, podpis jest często postrzegany jako bezpieczny. Z nieograniczona zgoda lub setApprovalForAll, osoba atakująca może wycofać bieżące aktywa i wszelkie przyszłe depozyty do czasu zresetowania allowance lub wyłączenia statusu operator.
W prostych słowach: approve nie jest przelewem, lecz przyznaniem uprawnień do wydatków na konkretny adres. Phishing zatwierdzający oznacza, że użytkownik zostaje nakłoniony do przyznania tego prawa adresowi kontrolowanemu przez osobę atakującą, podczas gdy jest to przedstawiane jako normalny krok wymiany, wymiany lub roszczenia.
Phishing zatwierdzający działa poprzez ważne uprawnienia. Niebezpieczeństwo pojawia się po podpisaniu, gdy czynne prawo do wydatków zostanie wykorzystane bez udziału właściciela.
Uprawnienia w EVM to zapisy praw zawartych w umowach, a nie jednorazowe działania; dlatego approve może pozostać aktywny przez wiele miesięcy i być używany bez ponownego podpisu.
Jak działają uprawnienia w EVM: allowance, spender i „infinite approve”
Uprawnienie EVM to rekord stanu w tokenie lub umowie NFT, który łączy Twój adres z konkretnym adresem spender/operator. Ten rekord określa, kto może wydawać tokeny
- ERC-20: approve → allowance → transferFrom
- Użytkownik dzwoni approve(spender, kwota) i określa adres spender.
- Umowa tokenowa przechowuje allowance limit — maksymalna liczba tokenów, które spender może wydać.
- Połączenia spender transferFrom i wydaje tokeny bez nowych podpisów, dopóki allowance nie osiągnie wartości 0 lub nie zostanie wyczerpany.
- Umowa sprawdza allowance podczas
transferFrom ; nie wymaga podpisu właściciela przy każdym wydatku.
- Dodatek jest powiązany z właścicielem → spender → tokenem
- Uprawnienie istnieje tylko dla określonego tokena i konkretnego spender.
- approve dla USDT nie zapewnia dostępu do USDC i nie obejmuje innych kontraktów.
- Każdy nowy token lub nowy spender wymaga osobnego approve.
- Nieograniczona zgoda to maksymalna wartość allowance
- W przypadku nieograniczonej liczby approve, allowance przechowuje maksymalną wartość numeryczną.
- spender otrzymuje prawo do wydawania tokenów z tego kontraktu w ramach tej wartości, z uwzględnieniem przyszłych wpłat na adres.
- Uprawnienie pozostaje aktywne do czasu transakcji revoke, nawet jeśli usługa nie jest już używana.
- NFT: setApprovalForAll to status operator bez limitu
- setApprovalForAll(operator, prawda) włącza status operator dla całej kolekcji NFT właściciela.
- Nie jest to ograniczenie ilościowe ani wartościowe: prawo pozostaje do setApprovalForAll(operator, fałsz) jest wysyłany.
- Jeśli operator zostanie naruszony, NFTs może zostać wycofany bez potwierdzenia przez nowego właściciela.
Nielimitowane approve dla ERC-20 zwiększa maksymalną kwotę, którą można wydać przez
Uprawnienia EVM to długoterminowe zapisy praw w umowach. Jeden approve może pracować miesiącami, bez ograniczeń zwiększa dostępny limit wydatków i
Podpis permit (na przykład EIP-2612) daje aplikacji prawo do ustawienia allowance poprzez podpisany komunikat; aplikacja używa następnie tego podpisu w transakcji przyznającej prawa i wykonuje akcję w jednym wywołaniu.
Zezwolenie, Permit2 i podpisy wiadomości: w jaki sposób uprawnienia są przyznawane bez osobnego approve i dlaczego atakujący tego używają
Oprócz zwykłego approve, EVM ma sposoby na udzielenie pozwolenia bez oddzielnej transakcji. Użytkownik po prostu podpisuje wiadomość, a aplikacja używa tego podpisu w swojej własnej transakcji, która zarówno przyznaje prawo do wydawania pieniędzy, jak i wykonuje akcję — zamianę, depozyt lub roszczenie. Te mechanizmy nazywane są permit i rozszerzenia, np Permit2.
Z punktu widzenia UX wygląda to na mniejszą liczbę kroków: nie ma oddzielnej transakcji approve i do oddzielnego wywołania approve nie jest wymagany gaz. Konsekwencja techniczna jest taka sama: w umowie pojawia się prawo do wydatków, które może pozostać aktywne po pojedynczej operacji, jeżeli parametry podpisu określają szeroki limit lub długi okres obowiązywania.
Użytkownicy najczęściej mylą dwa typy potwierdzeń:
- Transakcja (w łańcuchu): approve / revoke / transfer — wysyłany do sieci, wymaga gazu i zmienia stan umowy.
- Podpis wiadomości (poza łańcuchem): permit i podobne mechanizmy — w momencie podpisywania nie jest potrzebny gaz, ale pozwalają aplikacji zainstalować te same prawa dostępu.
| ⚙️ Mechanizm | 🧾To co dajesz | 📍 Gdzie się pojawia | ⚠️Kluczowe ryzyko |
|---|---|---|---|
| Approve (ERC-20) | Limit wydatków tokena dla spender | DEX, pożyczki, rolnictwo, mosty | Nieograniczony allowance pozostaje aktywny do revoke |
| Zezwolenie (EIP-2612 i analogi) | Zezwolenie poprzez podpis bez osobnego approve | Swapy „jednym kliknięciem”, agregatory, interfejsy DeFi | Podpis wygląda na „bezpieczny”, ale określa rzeczywiste prawa |
| UstawZatwierdzenieDlaWszystkich (NFT) | Globalny dostęp do całej kolekcji | Targowiska, mennice, gry dApps | NFTs można przenieść bez wielokrotnych potwierdzeń |
Kluczowy niuans: approve i permit prowadzą do tego samego rezultatu – konkretny adres otrzymuje prawo do zarządzania majątkiem właściciela. Formularz potwierdzenia jest inny: transakcja w łańcuchu lub podpis wiadomości, który jest później używany w transakcji.
Lista kontrolna przed podpisaniem (30 sekund): szybki filtr pozwalający sprawdzić, czy podpis przyznaje uprawnienia do wydatków.
- Co jest potwierdzane? Zezwolenie lub approve oznacza przyznanie dostępu.
- Kto otrzymuje dostęp? Spójrz na spender lub operator w parametrach, a nie na projekcie witryny.
- Jaki jest limit? Nieograniczona liczba żetonów płynnych zwiększa dostępną kwotę wydatków.
- Czy istnieje setApprovalForAll? Dla NFTs jest to pełny status operator w kolekcji.
- Czy jest coś pilnego? Często stosuje się presję czasu, aby ludzie podpisywali bez sprawdzania parametrów.
Zezwolenie i „podpisy bezgazowe” zmieniają jedynie formę potwierdzenia. Podpis wiadomości może instalować prawa dostępu do tokenów lub NFTs, podobnie jak approve, więc parametry podpisu należy odczytać jako przyznanie uprawnień.
W typowych schematach phishingu zatwierdzającego użytkownik jest namawiany do podpisania approve/permit lub
Typowe schematy phishingu związanego z zatwierdzeniem: w jaki sposób zostajesz naprowadzony do „właściwego” podpisu
Schematy te wykorzystują znane interfejsy i standardowe przepływy pracy, co sprawia, że nadanie uprawnień wygląda jak zwykły krok serwisowy.
Prawie wszystkie ataki opierają się na tej samej logice: najpierw użytkownik zostaje przekierowany na stronę wyglądającą jak interfejs dApp, następnie strona żąda podpisu przyznającego prawo do wydatków lub prawo operator, a następnie aktywne zezwolenie zostaje wykorzystane do wycofania zasobów bez nowych potwierdzeń.
Kluczową cechą jest brak bezpośredniego żądania wysłania przelewu. Zamiast przeniesienia witryna żąda approve/permit lub
- Klon popularnej usługi
- Fałszywa domena lub link reklamowy prowadzi do wizualnie podobnej kopii DEX-u lub rynku.
- Interfejs żąda approve „do wymiany” lub
setApprovalForAll „dla wpisu NFT”. - Parametry podpisu zawierają spender/operator, który nie należy do prawdziwej usługi.
- Kompromis w oficjalnych kanałach
- Link jest publikowany w Discord, Telegram lub X w imieniu projektu lub moderatora.
- Stosowane są wyzwalacze pilności: „błąd w umowie”, „migracja mennicy”, „ostatnia szansa”.
- Link prowadzi do strony, która żąda approve/permit o podanie adresu atakującego.
- Inżynieria społeczna poprzez „wsparcie”
- Osoba atakująca wysyła prywatną wiadomość podszywającą się pod pomoc techniczną.
- Podpis jest wymagany pod pretekstem „anulowania zablokowanej transakcji”.
- W praktyce użytkownik podpisuje permit lub nadaje approve na adres strony trzeciej.
- Zastąpienie znaczenia podpisu
- Okno portfela wyświetla wezwanie techniczne bez jasnego wyjaśnienia z interfejsu.
- Użytkownik potwierdza bez sprawdzania adresu spender/operator i limitu.
- Ryzyko jest największe, gdy interfejs nie wyświetla spender, typu limitu lub uprawnienia.
Przykład: użytkownik łączy portfel ze stroną „zrzutu”, klika „Odbierz” i podpisuje nieograniczoną liczbę approve dla monety stablecoin. Saldo się nie zmienia, ale później, gdy środki napłyną, spender wypłaca tokeny za pośrednictwem
Ataki te nie wymagają natychmiastowego wycofania się. Osoba atakująca może poczekać, aż saldo wzrośnie lub nadejdzie płynność, a następnie skorzystać z aktywnego pozwolenia.
Typowe schematy phishingu polegające na zatwierdzeniu maskują przyznanie praw jako znane działania. Dopóki status allowance lub operator jest aktywny, atakujący może z niego skorzystać w dowolnym momencie bez konieczności potwierdzania przez nowego właściciela.
Zasiłek i
Typowe błędy użytkowników: dlaczego atesty kumulują się i stają się zagrożeniem
Niebezpieczeństwo zatwierdzeń rzadko jest odczuwalne w momencie podpisywania, ponieważ approve zwykle nie zmienia salda. Ryzyko pojawia się później, gdy do wydatków wykorzystywane jest aktywne zezwolenie, i staje się większe, jeśli takie uprawnienia pozostają w kilku sieciach i kilku tokenach.
Najczęstszy błąd: nieograniczone zezwolenia na monety typu stablecoin i płynne tokeny. W momencie podpisywania wygląda to na mniej kroków, ale technicznie oznacza to duży allowance, który pozwala spender wydawać tokeny
Ta sama logika dotyczy
Osobną klasą błędów jest zaufanie do marki i oprawy wizualnej. Użytkownik skupia się na domenie, logo czy układzie, ale pozwolenie zawsze udzielane jest na konkretny adres — spender lub operator. W przypadku podmiany interfejsu projekt nie zmienia adresu w parametrach podpisu.
Innym częstym błędem jest uznanie problemu za zamknięty po revoke w jednej sieci. Zatwierdzenia są izolowane według sieci: allowance w Ethereum i allowance w Arbitrum to różne rekordy w różnych kontraktach, więc uprawnienie może pozostać aktywne w innej sieci.
Jeśli przenosisz płynność między sieciami, sprawdź zatwierdzenia po operacjach między łańcuchami: mosty i routery często wymagają approve dla oddzielnego spender w każdej sieci. Mosty kryptograficzne: jak działają i które są bezpieczniejsze.
Sygnatury bezgazowe powodują dodatkowe zamieszanie. Zezwolenia i podobne mechanizmy są postrzegane jako „miękkie” potwierdzenia, ale efekt jest ten sam: aplikacja otrzymuje możliwość zainstalowania pozwolenia, które następnie służy do dokonywania wydatków.
Błędy stają się bardziej niebezpieczne, gdy jeden portfel jest używany jednocześnie do przechowywania, aktywnego handlu i eksperymentów. W tym trybie jedno niepotrzebne spender/operator umożliwia dostęp do zasobów, które nie były częścią pierwotnej operacji.
Głównym zagrożeniem związanym z zatwierdzeniami są aktywne uprawnienia, które pozostają w umowach po zakończeniu zadania. Nieograniczone allowance, włączone NFT operator i uprawnienia w kilku sieciach zwiększają ilość zasobów dostępnych do wydania bez nowych potwierdzeń.
Uprawnienia należy sprawdzić osobno dla każdej sieci: Listy allowance i operator w Ethereum nie są zgodne z Arbitrum, Optimism, Polygon lub BSC, ponieważ rekordy uprawnień są przechowywane w kontraktach w konkretnej sieci.
Gdzie sprawdzić uprawnienia: co dokładnie sprawdzać i w jakiej kolejności
Przegląd uprawnień to sekwencja kroków według sieci i typu zasobu. Tokeny ERC-20 i NFTs wykorzystują inną mechanikę dostępu, dlatego należy je analizować osobno i zamykać w kolejności priorytetów: najpierw nieznane adresy i szerokie limity, a następnie pozostałe działające uprawnienia.
- Zidentyfikuj sieć o największej aktywności
- Uprawnienia nie są „globalne”: Ethereum, Arbitrum, Optimism, Polygon i BSC mają osobne listy zatwierdzeń.
- Zacznij od sieci, w której koncentruje się płynność i gdzie miały miejsce ostatnie transakcje.
- Sprawdź atesty ERC-20 i ogranicz to, co niepotrzebne
- Priorytet mają nieznane spender i nieograniczone allowance na stablecoinach i płynnych tokenach.
- Usuń niewykorzystane uprawnienia i zmniejsz limity do kwoty potrzebnej do bieżącej operacji.
- Sprawdź oddzielnie atesty NFT
- Zwróć szczególną uwagę na
setApprovalForAll dla rynków i gier dApps. - Utrzymuj operator aktywny tylko przez okres, kiedy jest naprawdę potrzebny.
- Zwróć szczególną uwagę na
- Sprawdź adresy, które pozostawiłeś aktywne
- Dopasuj adresy spender/operator do zaufanych usług na podstawie adresu w sygnaturze lub eksploratorze.
- Jeśli adres nie jest rozpoznawalny, zresetuj allowance lub wyłącz operator i przyznaj nowe uprawnienia tylko wtedy, gdy jest to konieczne.
| Podejście | Co sprawdza | Mocna strona | Ograniczenie |
|---|---|---|---|
| Sieciowy skaner blockchain | Certyfikaty ERC-20 allowance i często NFT | Dane sieciowe bez zaufania do interfejsu dApp | Musisz zmienić sieć i przeanalizować adresy |
| Usługi Revoke | Token i uprawnienia NFT w wybranej sieci | Lista + przycisk do resetowania allowance/wyłączania operator | Zasięg zależy od sieci i integracji |
| Portfele z symulacją | Spender, limity, ostrzeżenia przed podpisaniem | Pokazuje, który adres otrzyma uprawnienia przed potwierdzeniem | Różna głębokość wyświetlania zatwierdzenia |
Czego szukać na liście uprawnień
- Nieznany spender lub operator. Jeśli adres nie jest rozpoznawalny, jest to kandydat revoke.
- Nielimitowany allowance na aktywa płynne. Duży allowance zwiększa dostępną kwotę wydatków.
- Uprawnienia w L2s i łańcuchach bocznych. Zatwierdzenia mogą pozostać aktywne w sieciach, w których nie dokonywałeś transakcji przez dłuższy czas.
- NFT operator bez bieżącej potrzeby. Aktywny operator może przesłać NFTs bez nowych potwierdzeń.
- Umowy proxy i aktualizacje. Approve jest powiązane z adresem spender, więc stare uprawnienie pozostaje aktywne nawet jeśli logika ulegnie zmianie w wyniku aktualizacji.
Przejrzyj logikę: najpierw zresetuj allowance dla nieznanych adresów i usuń nieograniczone uprawnienia na wrażliwych tokenach, a następnie zmniejsz pozostałe limity do kwoty potrzebnej do bieżących operacji.
Przegląd uprawnień powinien odpowiadać sposobowi przechowywania uprawnień: oddzielne sieci, oddzielne tokeny, oddzielne spender/operator. Nadanie priorytetu nieznanym i nieograniczonym uprawnieniom zamyka główne scenariusze wydatków bez nowych potwierdzeń.
Revoke to transakcja ustawiająca allowance na 0 dla właściciela → spender → pary tokenów lub przełączników
Jak poprawnie nadać uprawnienia revoke: tokeny, NFTs i typowe błędy
Revoke to transakcja w łańcuchu, która zmienia allowance lub wyłącza NFT operator. W rezultacie umowa rejestruje nowy stan: konkretny adres nie ma już prawa do zarządzania Twoim majątkiem. Revoke zatrzymuje przyszłe wydatki, ale nie odwraca transakcji, które zostały już wykonane.
Algorytm revoke krok po kroku dla ERC-20
- Zidentyfikuj sieć. Zatwierdzenia są izolowane według sieci: Ethereum, Arbitrum, Optimism i inne L2s mają osobne listy uprawnień.
- Znajdź token i spender. Sprawdź adres umowy tokena, nazwę tokena i aktualny limit allowance, szczególnie w przypadku monet stabilnych i aktywów płynnych.
- Wykonaj revoke. Standardową opcją jest ustawienie allowance na 0 do approve(spender, 0) lub użycie przycisku revoke w usłudze.
- Sprawdź wynik. Upewnij się, że allowance ma wartość 0 i uprawnienie nie jest już wyświetlane jako aktywne.
Algorytm revoke krok po kroku dla NFTs
- Otwórz listę operator kolekcji. Szukaj aktywnych
setApprovalForAll wpisy i powiązane adresy operator. - Wyłącz operator. Status należy zmienić na false.
- Powtórz tę czynność dla kolekcji kluczy. Najpierw sprawdź kolekcje o najwyższej wartości i płynności.
Częsty błąd: revoke jest wykonywany w jednej sieci, podczas gdy status allowance lub operator pozostaje aktywny w innej. Jeśli korzystałeś z mostów, agregatorów i wielosieci dApps, sprawdź atesty w każdej sieci osobno.
Niuans ERC-20: niektóre tokeny wymagają sekwencji approve(spender, 0) przed ustawieniem nowego allowance. W takich przypadkach revoke rozpoczyna się od zresetowania limitu.
Revoke zmienia zapis praw w umowie: allowance przyjmuje wartość 0 lub operator jest wyłączony. Aby revoke rzeczywiście zamknął dostęp należy go wykonać w odpowiedniej sieci i dla właściwej pary tokena → spender lub kolekcji → operator.
Jeśli nadałeś approve/permit lub
Jeśli przyznałeś już niebezpieczny approve: szybki plan redukcji obrażeń
W tej sytuacji kolejność działań ma znaczenie: najpierw odsuń zasoby od aktywnych uprawnień, następnie zresetuj allowance i wyłącz operator, a dopiero potem zbadaj źródło podpisu.
Jeśli
- Przenieś zasoby na „czysty” adres. Nowy portfel z nową frazą początkową zrywa połączenie z bieżącymi zatwierdzeniami, ponieważ allowance i operator są powiązane ze starym adresem właściciela.
- Uprawnienia Revoke do przejętego adresu. Zresetuj allowance najpierw dla monet stabilnych i tokenów płynnych, a następnie dla pozostałych tokenów.
- Sprawdź uprawnienia NFT. Wyłącz
setApprovalForAll dla operator, które nie są potrzebne. - Odłącz sesje dApp w portfelu. Nie zmienia to allowance, ale usuwa aktywne sesje lokacji, które mogą żądać innego podpisu.
- Izoluj środowisko. Jeśli istnieje ryzyko zastąpienia złośliwego rozszerzenia lub witryny, użyj innej przeglądarki lub urządzenia.
Nie zgadzaj się na „przelewy testowe”, „kontrole bezpieczeństwa” lub „odzyskiwanie środków” sugerowane przez nieznajomych. Takie prośby często wykorzystywane są w celu uzyskania nowego podpisu lub bezpośredniego przelewu.
Po udzieleniu niebezpiecznego pozwolenia priorytetem jest zmniejszenie ilości zasobów osiągalnych poprzez allowance/operator, a następnie zresetowanie tych praw za pomocą transakcji revoke. Dopóki prawa pozostają aktywne, wydatki mogą nastąpić bez nowych potwierdzeń.
Zapobieganie phishingowi zatwierdzającemu sprowadza się do kontrolowania dwóch parametrów: kto otrzymuje prawo (spender/operator) oraz jak duże lub szerokie jest to prawo (allowance lub
Zapobieganie: jak udzielać uprawnień, nie stając się łatwym celem
Zapobieganie wyłudzaniu informacji przez zatwierdzanie opiera się na zarządzaniu uprawnieniami: oddzielaniu ról portfela, ograniczaniu allowance i wyłączaniu operator po zakończeniu zadania.
Większość strat jest związana z aktywnymi uprawnieniami, które pozostają w umowach po zakończeniu operacji: nieograniczone allowance, włączone NFT operator oraz nawyk potwierdzania podpisów bez sprawdzania adresu. Te rekordy praw pozwalają na wydatki bez nowych potwierdzeń do revoke.
Oddzielenie ról portfela
Używanie jednego adresu do przechowywania, handlu i eksperymentów sprawia, że każdy approve ma kluczowe znaczenie dla całego salda pod tym adresem. Oddzielenie adresów ogranicza ilość zasobów udostępnionych poprzez allowance lub operator. Jeśli wybierzesz portfel „przechowujący” na dłuższą metę, zacznij od a recenzja sprzętowego portfela kryptowalutowego i skonfiguruj chłodnię przed aktywną pracą DeFi.
🧩 Podstawowa konfiguracja trzech adresów
- Przechowywanie (długoterminowe): kapitał główny, minimum interakcji dApp, brak aktywnych zatwierdzeń.
- Adres operacyjny: regularna aktywność DeFi, ograniczone saldo, zaplanowany przegląd allowance i operator.
- Adres eksperymentalny: zrzuty, NFTs, nowe projekty; ryzyko jest ograniczone do przechowywanej na nim kwoty.
Ograniczenie zakresu każdego zezwolenia
Nawet podczas pracy z zaufanymi usługami należy rozważyć scenariusz błędu lub kompromisu spender/operator. Dla ERC-20 zakres prawa jest zdefiniowany przez allowance; dla NFTs zakres jest zdefiniowany przez
- Użyj dokładnych limitów. Limit określa maksymalną liczbę tokenów, które spender może wydać.
- Po zakończeniu zadania zresetuj allowance. To kończy wydatki
transferFrom . - Sprawdź adres spender. Zezwolenie udzielane jest na adres podany w parametrach podpisu, a nie na „stronę”.
- Wyłącz setApprovalForAll po zadaniu. Operator nie powinien pozostawać aktywny po wystawieniu aukcji lub sesji gry.
- Nie potwierdzaj ze względu na pilność. Często stosuje się tryb pilny, aby podpis nie był sprawdzany.
Tryb przeglądu: kiedy sprawdzać zatwierdzenia
- Po jednorazowej operacji. Jeśli usługa nie jest używana regularnie, po zakończeniu operacji zresetuj allowance lub wyłącz operator.
- Dla adresu operacyjnego DeFi. Przy ciągłej aktywności przeglądaj zatwierdzenia raz na jeden do dwóch tygodni i usuwaj niepotrzebne uprawnienia.
- Dla adresu eksperymentalnego. W przypadku nowego dApps i zrzutów sprawdzaj i zamykaj uprawnienia po każdej sesji.
Model roboczy: approve/permit przyznaje prawo do określonego adresu, allowance definiuje limit, revoke zmienia limit na 0 lub wyłącza operator.
Zapobieganie zatwierdzeniom polega na aktywnym zarządzaniu uprawnieniami: separacja adresów, dokładne limity allowance i wyłączenie operator po wykonaniu zadania zmniejszają ilość zasobów dostępnych do wydania bez nowych potwierdzeń.
Approve umożliwia wywoływanie protokołów
Approve jako mechanizm: mocne strony i wbudowane ryzyko
Approve stanowi podstawę infrastruktury DeFi: umożliwia protokołom wykonywanie operacji poprzez
Mechanizm approve stanowi kompromis pomiędzy przechowywaniem zasobów pod własnym adresem a automatyzacją działań protokołu. Aktywa pozostają na Twoim adresie, ale kontrakt otrzymuje prawo do ich wydatkowania w ramach allowance ustawionego w approve.
✅ Mocne strony approve
- Aktywa pozostają pod adresem właściciela do czasu ich wydania
transferFrom . - Protokoły mogą wykonywać operacje bez podpisu na każdym kroku, używając allowance.
- Ulga umożliwia ograniczenie maksymalnej kwoty wydatków dla konkretnego spender.
- Uprawnienia można weryfikować w łańcuchu i można je zresetować za pomocą transakcji revoke.
❌ Wbudowane ryzyko zatwierdzeń
- Uprawnienie pozostaje aktywne do revoke i nie jest uzależnione od zamknięcia witryny lub odłączenia portfela.
- Nieograniczony allowance zwiększa ilość tokenów dostępnych do wydania, jeśli spender zostanie naruszony.
- Jeśli approve zostanie podpisany bez sprawdzenia spender i limitu, prawo może zostać przyznane na zły adres.
UstawZatwierdzenieDlaWszystkich dla NFTs daje operator prawo do przeniesienia całej kolekcji jedną akcją.
Approve to mechanizm infrastrukturalny do zarządzania uprawnieniami. Jest to wygodne, ponieważ transfer jest wykonywany przez allowance bez powtarzających się podpisów i ryzykowne, ponieważ aktywne uprawnienie działa do revoke i można je wykorzystać do późniejszych wydatków.
Przypadki i wnioski: dlaczego „właściwa umowa” może nadal stanowić problem
Nawet podczas pracy z legalnymi usługami aktywne zatwierdzenia stwarzają ryzyko: luka w zabezpieczeniach, aktualizacja lub zamiana frontendu stają się niebezpieczne, jeśli allowance jest już zarejestrowany lub w umowie włączono operator.
Kluczową właściwością atestów jest brak „dożywotniego okresu”. Jeśli zezwolenie zostało udzielone, umowa nie musi ponownie żądać approve: korzysta z już zarejestrowanych praw. Dlatego ryzyko zależy nie tylko od aktualnej usługi, ale także od listy atestów zgromadzonych pod adresem.
🔓Przypadek 1: luka w legalnym protokole + nieograniczone zgody
Użytkownik przyznaje nieograniczoną liczbę approve do protokołu, a później zostaje znaleziony błąd w logice wydatków dzięki temu kontrakt może wydać więcej tokenów, niż oczekiwano.
- Kontrakt obejmuje już wydatki do allowance, więc atak nie wymaga podpisu nowego właściciela.
- Nieograniczony allowance zwiększa kwotę wydatków do salda tokena na adresie właściciela.
- Użytkownicy, którzy nie dokonują nowych transakcji, pozostają bezbronni do czasu zresetowania allowance.
Nieograniczony approve zamienia błąd protokołu w ryzyko dla całego salda tokena na adresie. Exact allowance ogranicza maksymalne wydatki, a revoke kończy prawo do wydatków.
🧩 Przypadek 2: aktualizacja umowy proxy zmienia zachowanie dostępu
Umowy z możliwością aktualizacji zachowują ten sam adres, ale kod pod tym adresem może ulec zmianie po uaktualnieniu lub naruszeniu zasad zarządzania.
- Approve jest powiązany z adresem spender, a nie z konkretną wersją kodu.
- Po aktualizacji nowy kod może używać allowance inaczej niż oczekiwał właściciel.
- Stary allowance pozostaje aktywny, dopóki nie zostanie zresetowany przez transakcję.
Podczas aktualizacji protokołów należy przejrzeć stare zatwierdzenia, ponieważ allowance pozostaje aktywny pod tym samym adresem spender.
🧠 Przypadek 3: substytucja frontendu, podczas gdy marka pozostaje znana
Użytkownik odwiedza znaną witrynę, ale interfejs zostaje zastąpiony przez DNS, reklamy, CDN lub złośliwe rozszerzenia.
- Wygląd interfejsu jest zgodny z oczekiwaniami użytkownika.
- Approve lub permit jest przydzielany adresowi, który nie jest umową o świadczenie usług.
- Sprawdzenie spender/operator w podpisie ujawnia podstawienie; marka i projekt nie.
Polegaj na adresie spender/operator i limicie allowance w podpisie, a nie na projekcie domeny i strony.
🛰️Przypadek 4: agregatory i routery jako brama szerokiego dostępu
Agregatory i routery korzystają z jednego spender dla wielu tras i protokołów.
- Jeden adres spender obsługuje wiele scenariuszy i wiele tokenów.
- Jeśli spender zostanie naruszony, ryzyko przechodzi na wszystkich, którzy przyznali mu allowance.
- Nielimitowany allowance zwiększa kwotę, którą można wydać za pośrednictwem tego adresu.
W przypadku routerów limit allowance określa maksymalną kwotę wydatków, a zwykłe revoke usuwa stare uprawnienia, które nie są już potrzebne.
🖼️ Przypadek 5: setApprovalForAll dla NFTs pozostaje aktywny przez lata
- To jest status operator, a nie limit liczby NFTs.
- Nawet bez aktywności operator pozostaje włączony w umowie odbioru.
- Kompromis z operator umożliwia transfer NFTs bez podpisu nowego właściciela.
Wyłączanie
Zdarzenie staje się możliwe, gdy allowance jest już zarejestrowany lub w umowie włączono operator. W tym momencie można dokonać wydatków bez podpisu nowego właściciela.
W praktyce incydenty zdarzają się, ponieważ po zakończonych operacjach pozostają uprawnienia. Regularny przegląd i wyłączanie niepotrzebnych allowance i operator ograniczają ilość zasobów dostępne do wydawania bez nowego podpisu.
Często zadawane pytania pomagają wyjaśnić, które podpisy przyznają prawa i jak działa revoke i dlaczego wydatki mogą mieć miejsce bez ponownego potwierdzenia.
Często zadawane pytania dotyczące phishingu zatwierdzającego, approve i revoke
Dlaczego ludzie mówią „osunięty bez podpisu”, jeśli coś podpisałem?
Podpis miał na celu nadanie praw, a nie przekazanie środków. Po approve, permit lub
Czy nielimitowany approve zawsze jest błędem?
Nieograniczony approve rejestruje bardzo dużą wartość w allowance. Zwiększa to maksymalną liczbę tokenów, za pośrednictwem których spender może wydać
Czy revoke może zwrócić skradzione środki?
Nie. Revoke zmienia stan kontraktu tylko na przyszłość: allowance przyjmuje wartość 0 lub operator jest wyłączone. Transakcje, które zostały już zrealizowane, nie są cofane.
Czy usunięcie portfela lub „odłączenie witryny” powoduje usunięcie zatwierdzeń?
Nie. Uprawnienia są przechowywane w łańcuchu wewnątrz tokena i kontraktów NFT. Odłączenie witryny lub usunięcie aplikacji nie powoduje zmiany statusu allowance lub operator w umowie.
Gdzie dokładnie jest przechowywany approve?
W stanie inteligentnego kontraktu. Dla ERC-20 jest to rekord allowance(właściciel, spender); w przypadku NFTs są to zgody i operator w umowie odbioru.
Czy approve można ograniczyć do określonej kwoty?
Tak. Wywołanie approve przekazuje parametr kwoty, a ta wartość definiuje allowance. spender nie może wydać więcej niż bieżące allowance permit.
Co jest bardziej niebezpieczne: approve dla tokena czy setApprovalForAll dla NFT?
Zwykle
Czy należy sprawdzić zatwierdzenia w L2s i łańcuchach bocznych?
Tak. Każda sieć przechowuje swoje własne zapisy dotyczące praw w swoich własnych umowach. Zezwolenie w Ethereum i allowance w Arbitrum mają różne wartości, więc sprawdzenie tylko jednej sieci nie pokazuje uprawnień w innych sieciach.
Czy portfel sprzętowy chroni przed phishingiem zatwierdzającym?
Portfel sprzętowy chroni klucz prywatny i proces podpisywania przed kradzieżą na urządzeniu, nie zmienia to jednak znaczenia podpisywanej akcji. Niebezpieczny approve/permit lub
FAQ sprowadza się do jednej weryfikowalnej różnicy: podpis może przyznawać uprawnienia (approve/permit/
Jeden błędny approve/permit lub
Jak chronić się przed phishingiem zatwierdzającym i kontrolować uprawnienia
Uprawnienia są podstawą mechaniki DeFi, ale statusy allowance i operator pozwalają na wycofanie aktywów bez ponownego podpisu, jeśli uprawnienie zostało przyznane na niepotrzebny adres.
Phishing zatwierdzający jest nadużyciem słusznych praw. Jeden approve/permit lub
Aby uniknąć pozostawiania aktywnych praw do adresu, zachowaj kontrolę poprzez konkretne działania:
- Sprawdź adres dostępu. Ważną częścią w podpisie i liście zatwierdzeń jest spender/operator, a nie marka lub projekt.
- Limit allowance. Ustaw limit specyficzny dla zadania zamiast nieograniczonego i zresetuj allowance, gdy uprawnienie nie jest już potrzebne.
- Wyłącz operator dla NFTs. Nie odchodź
setApprovalForAll włączone po zakończeniu akcji. - Sprawdź wszystkie sieci. Limit i operator są przechowywane oddzielnie w każdej sieci, dlatego należy sprawdzić każdą sieć, w której zastosowano dApp.
- Oddziel adresy według roli. Saldo na adresie określa maksymalną kwotę, jaką można wydać w ramach aktywnych uprawnień na tym adresie.
Traktuj zatwierdzenia jako aktywne prawa dostępu zapisane w umowach. Minimalne limity allowance, wyłączone operator i przeglądanie we wszystkich sieciach zmniejszają ilość zasobów dostępnych do wydania bez nowego podpisu.