
Kötü onayları iptal etmenin ve sızıntıyı kapatmanın yolu
Kötü niyetli onayları iptal etmek, genellikle bir token'ın harcayıcı için transferFrom çağrısı yapabileceği izni 0 olarak ayarlayan bir on-chain işlemi göndermeyi gerektirir. Bir cüzdanı bir dApp'ten ayırmak yalnızca bir UI eylemidir, bu nedenle token onaylarını kaldırmaz veya zaten harcama iznine sahip bir cüzdanın harcamasını durdurmaz.
Ana Noktalar
- Bir token onayı token sözleşmesinde sürekli bir izindir ve on-chain'de değiştirilene kadar devam eder.
- Onayı iptal etmek, harcayıcının iznini 0 veya daha küçük bir miktara ayarlayan bir işlem gönderirsiniz ve gas ödersiniz.
- Sınırsız onaylar, harcamaların o izin miktarına kadar token bakiyesini boşaltabileceği için izinlerin patlama versiyonudur.
- Permit2İmzaların arkasında riski gizleyebilirsiniz: Permit2 için yalnızca bir on-chain onayı görebilirsiniz, oysa gerçek tehlike kötü niyetli bir EIP-712 yetkilendirmesini imzalamaktır.
Token onaylarının neden tehlikeli olabileceği
Kötü niyetli bir onay “birdApp“bağlantı.” Bu, belirli bir harcayıcının transferFrom ile tokenlerinizi hareket ettirebileceğini belirten bir token sözleşmesinde canlı bir izin durumudur.ERC-20delege edilmiş transferler üç işlev üzerinde çalışır: approve(spender, amount), allowance(owner, spender) ve transferFrom(from, to, amount). Bu izin mevcut olduğunda, harcayıcı cüzdanınıza tekrar ihtiyaç duymaz. Tek ihtiyacı olan, iznin hala sıfır olmamasıdır.
Bu ısrarcılık tüm sorunun kaynağıdır. Harçlar açıkça değiştirilene kadar aktif kalır, bu yüzden "cüzdanı bağlantıyı kes" butonları ve cüzdan bağlantı listeleri sahte bir güvenlik hissi yaratır. Bağlantıyı kesmek, bir sitenin cüzdanınızı isteme yeteneğini ortadan kaldırır. Bu, harcama yetkisini gerçekten veren token sözleşmesinin durumuna hiçbir şey yapmaz.
Bu yüzdenonay phishingçalışır: saldırganın amacı bir token onayı (veya bir izin tarzı imza) almak, ardından kurban dikkatini kaybettiğinde bunu kullanmaktır.
Sonsuz onaylar, kuyruk riskinin bulunduğu yerdir. Birçok kullanıcı arayüzü, gelecekteki sürtünmeyi azaltmak için varsayılan olarak 'sonsuz' seçeneğini sunar, ancak maksimum uint256 miktarını onaylamak, harcayıcıya o token için boş bir çek vermek anlamına gelir. Eğer harcayıcı sözleşmesi bugün kötü niyetliyse veya daha sonra istismar edilirse, izin akış yolu olur.
Tüccarlar için geçerli olan zihinsel model 'devam eden kredi limiti'dir. Her token onayı bir satır öğesidir: token → harcayıcı → limit. Okuyucu, transferFrom çağrısı yapma iznine sahip olan tam sözleşmeyi (ya doğrudan ya da Permit2 aracılığıyla) gösteremiyorsa, gerçek maruziyet bilinmemektedir. Bu, kripto cüzdan dolandırıcılıklarının arkasındaki temel mekaniklerden biridir ve bunlardan nasıl kaçınılacağıdır.
Bir onayın nasıl iptal edileceği
İptal etmek, bir ayar geçişi değildir. Bu, zincir üzerinde bir durum değişikliği anlamına gelir, bu da gaz maliyeti olduğu ve bir işlem kaydı bıraktığı anlamına gelir. Mekanik olarak, bir onayı iptal etmek, harcayıcının izninin 0 (veya uygulamayı sınırlı bir limit ile kullanmaya devam etmek amacıyla daha küçük bir sayı) olmasını sağlamak için token sözleşmesindeki izin haritasını yeniden yazmaktır.
İki operasyonel detay, çoğu kılavuzun kabul ettiğinden daha önemlidir.
Biri, 'token onayını kaldır' ifadesinin token'a özgü olmasıdır. Bir harcayıcı için USDC'yi iptal etmek, aynı harcayıcıya yönelik WETH onayları için hiçbir şey yapmaz. İzin defteri her token sözleşmesi için geçerlidir.
Diğeri, izin güncellemelerinin, sıfır olmayan bir izin N'yi başka bir sıfır olmayan izin M'ye değiştirirken bir yarış durumu kenar durumu olabileceğidir. Daha güvenli olan desen, Speedrun'dır.Ethereum“sıfıra-onayla-sonra-belirle” olarak adlandırır. Fikir basit: önce izin miktarını 0 olarak ayarlayın, onay bekleyin, ardından yeni miktarı ayarlayın. Bu, harcayıcının hem eski hem de yeni izin değerlerini kullanabileceği pencereyi ortadan kaldırır.
Bir cüzdan veya dApp “Sıfıra onaylama başarısız oldu” veya “Yeni miktara onaylama başarısız oldu” gibi hatalar veriyorsa, bu genellikle iptal etmenin imkansız olduğu anlamına gelmez. Bu, token’ın onay davranışının tuhaf olduğu veya UI'nın token’ın kurallarını düzgün bir şekilde yönetmediği anlamına gelir.
Çözüm, farklı bir izin aracı veya bir block explorerın token onay arayüzünü kullanmak ve ardından aynı zincir içi değişikliği tekrar denemektir.
Ana çerçeve tutarlı kalır: iptal etmek, zincir üzerinde izni yeniden yazmaktır. Okuyucu, izni elinde bulunduran harcayıcıyı tanımlayamıyorsa, iptal doğru bir şekilde hedeflenemez.
Revoke.cash kullanarak adım adım iptal
Revoke.cash, onayları tek bir gösterge panelinde ortaya çıkardığı ve kullanıcının aynı ekrandan zincir içi iptal işlemini göndermesine izin verdiği için yaygın bir iş akışıdır. Aşağıdaki adımlar, Bifrost Wallet belgelerindeki cüzdan içi akışı yansıtır, ancak sıra genel olarak cüzdanlar arasında aynıdır.
1. Güvenilir bir cüzdan tarayıcısını açın ve Revoke.cash'a gidin. Cüzdan içi bir tarayıcı kullanmak, reklamlardan veya DM'lerden benzer bir alan adına yönelme şansını azaltır. 2. Cüzdanı bağlayın ve doğru ağı seçin. Onaylar zincir spesifik olduğundan, bir Ethereum onayı Flare, Base veya başka bir EVM zinciri ayarlandığında görünmeyecektir. 3. Token onayları görünümünü açın ve riske göre sıralayın.
Sınırsız izinler ve anlamlı bakiyelere sahip token'lar ile başlayın, çünkü bunlar en yüksek etki alanı olan boşaltma yollarıdır. 4. Her riskli satır için harcayıcıyı tanımlayın. Harcayıcı, transferFrom çağrısı yapabilen sözleşmedir. Harcayıcı adı tanıdık gelmiyorsa, aksi kanıtlanana kadar düşmanca olarak kabul edin. 5. Seçilen onaylar için iptal et'e tıklayın. Bu, o token ve harcayıcı için izin miktarını 0 olarak ayarlayan bir işlem gönderir. 6.
Cüzdanda işlemi onaylayın ve gaz ödeyin. Gaz yüksekse, en büyük izinleri önce iptal etmek hala mantıklı bir “sigorta primi” ticareti olacaktır. 7. Onay listesini onaydan sonra tekrar kontrol edin. İzin artık 0 olarak görüntülenmeli veya satır, aracın UI'sine bağlı olarak kaybolmalıdır.
Onayları geri alma konusunda temel cevap şudur: kullanıcı hiçbir şeyi “bağlantısını kesmiyor”. Kullanıcı, token sözleşmesindeki izinleri değiştiriyor. Eğer cüzdan boşaltıcı zaten onay aldıysa, bu, yolu kapatan eylemdir.
Permit ve Permit2 onaylarını kontrol et
2022'nin sonları, çoğu kullanıcının kaçırdığı dönüm noktasıdır. Uniswap’ın Evrensel Yönlendiricisi, Permit2'yi varsayılan onay yolu haline getirdi ve bu, birçok “onay riski”ni belirgin approve() işlemlerinden uzaklaştırarak EIP-712 imzalarına kaydırdı.
Permit2, Uniswap Labs'ın tekil onay sözleşmesidir: kullanıcılar, her token için bir kez Permit2'yi onaylar, ardından uygulamalar harcayıcı, miktar, son tarih ve nonce içeren imzalı yetkilendirmeler talep eder.
Bu, denetim için iki defter oluşturur.
Birinci defter klasik ERC-20 izinleridir: token → harcayıcı. Bu, çoğu “token onay” panosunun gösterdiği şeydir ve genellikle rastgele sözleşmelere sınırsız onayların bulunduğu yerdir.
İkinci defter Permit2'dir: on-chain'deki token → Permit2 izni, artı uygulamaların talep ettiği off-chain imzalı yetkilendirmeler. Permit2, hem sürekli izin modu hem de tek seferlik transfer modunu destekler ve yetkilendirmeleri son tarih ile sınırlıdır. Son tarihler, yetkilendirmelerin otomatik olarak sona erebileceği için pasif izinlerden kaynaklanan riski azaltabilir, ancak imza hırsızlığını çözmez.
Onay phishing kampanyaları, tek bir imzalı mesajın fonları hareket ettirmek için yeterli olabileceği için giderek daha fazla permit ve Permit2 imzalama istemlerini hedef alıyor.
Pratik sonuç rahatsız edici ama nettir: “Hiçbir şeyi onayladığımı hatırlamıyorum” bir güvenlik sinyali değildir. Kullanıcı, geçmişinde asla approve() işlemi gibi görünmeyen yazılı verileri imzaladıktan sonra maruz kalabilir.
Bir korkudan sonra temizlik yaparken, denetim her token için bir soruyu yanıtlamalıdır: bu cüzdandan bu tokenin transferFrom'ını şu an hangi sözleşme gerçekleştirebilir? Bazen bu doğrudan bir harcayıcıdır. Bazen bu, tokenin tekil onaya sahip olduğu ve kullanıcının körü körüne imza istemlerini imzalamaya devam ettiği için Permit2'dir.
Tekrar eden olayları önleyen alışkanlık, imzalamadan önce bir işlemi nasıl doğrulayacağınız konusunda ele alınan aynı alışkanlıktır: her imza talebini harcama yetkisi olarak değerlendirin, aksi kanıtlanana kadar.
Geri alma işleminden sonra önleme kontrol listesi
Geri alma işlemleri onaylandıktan sonra, hedef, bir takas, köprü veya staking UI'sının izin istemesi durumunda aynı maruziyeti yeniden yaratmayı durdurmaktır. Temiz tutum, onayları pozisyon boyutlandırma gibi ele almaktır: limit, amaçlanan eylemi yansıtmalıdır, maksimum mümkün olanı değil.
1. Kullanıcı arayüzü izin veriyorsa, tam miktar onaylarını tercih edin. Sınırsız onaylar kullanışlıdır, ancak harcayan kişi tehlikeye girerse en yüksek etkiyle başarısızlık modu haline gelir. 2. Bir izin, bir sıfırdan farklı değerden başka bir değere değiştirilmesi gerekiyorsa, 'sıfıra onayla, sonra ayarla' yöntemini kullanın. Bu, bilinen bir yarış durumu riskini azaltan küçük bir operasyonel alışkanlıktır. 3.
İzinleri periyodik olarak bir izin izleyici ile gözden geçirin. Kullanıcı güvenliği kılavuzunda adı geçen araçlar arasında Etherscan Token Approvals, Revoke.cash, Debank ve Unrekt bulunmaktadır. 4. Permit ve Permit2 istemlerini yüksek riskli anlar olarak değerlendirin. Permit2, son tarihler ve nonce'lar ile EIP-712 imzaları kullanır, ancak imza oltalama hala kullanıcıların zarar görmesinin ana yoludur. 5.
Masada 'iki defter' modelini tutun: klasik izinler ve Permit2. Rastgele bir harcayanı iptal etmek, token hala Permit2'ye onaylıysa ve cüzdan doğrulanmamış bir siteden yetkilendirmeleri imzalamaya devam ediyorsa yardımcı olmaz.
Burada kripto cüzdan dolandırıcılıkları ve bunlardan nasıl kaçınılacağı konusundaki daha geniş disiplinin operasyonel hale geldiği yer: mevcut izinleri azaltın, imzalanan şeyi doğrulayın ve eski hatları kapatmak için gaz ödeyin, kullanışlı olmadıklarında.
Alıntı
Bu temizliğin pahalı versiyonunu yapan insanları izledim: cüzdanlarında bir siteyi bağlantısını kesiyorlar, güvende hissediyorlar ve ardından token sözleşmesindeki izin hiç değişmediği için tekrar saldırıya uğruyorlar. Önemli olan tek soru, bir harcayanın hala o token üzerinde transferFrom çağrısı yapıp yapamayacağıdır. Cevap 'evet' ise, drain yolu hala açıktır.
Bu işlemi ucuz tutan alışkanlık, onayları marj hatları gibi ele almaktır. Ticaret için boyutlandırın ve bir şey yanlış hissedildiğinde, gaz kötü olsa bile önce sınırsız olanları iptal edin. Eğer Permit2, 2022'nin sonlarından beri akışta ise, ikinci alışkanlık, okuyamadığınız EIP-712 istemlerini imzalamayı reddetmektir. Onay oltalaması şimdi burada yaşıyor.
Kaynaklar
Sıkça Sorulan Sorular
Cüzdanımı bir dApp'ten ayırmak token onaylarını iptal eder mi?
Hayır. Ayrılma, bir UI düzeyinde bir eylemdir ve token sözleşmesinde saklanan izinleri değiştirmez. Harcayan, onaylı miktara kadar transferFrom kullanmaya devam edebilir, ta ki onu zincir üzerinde iptal edene veya azaltana kadar.
Hangi token onaylarının en tehlikeli olduğunu nasıl anlarım?
Sınırsız onaylar en yüksek etkiye sahiptir çünkü kötü niyetli veya tehlikeye girmişse harcayanın sahip olduğunuz kadar token çekmesine izin verir. Artık kullanmadığınız sözleşmelere verilen eski onaylar da yaygın saldırı yüzeyidir çünkü değiştirilmeye kadar devam eder.
Onayları iptal etmek ücretsiz mi?
Hayır. İptal etme, izin durumunu güncelleyen bir zincir üzeri işlemdir, bu nedenle onayın bulunduğu ağda gaz maliyeti vardır. Bu maliyet, birçok cüzdanın zamanla uyku halindeki onayları biriktirmesinin nedenidir.
Permit2 nedir ve neden approve() işlemini göremeyebilirim?
Permit2, son tarihler ve nonce'lar ile harcamayı yetkilendirmek için EIP-712 imzalarını kullanan Uniswap Labs tekil onay sözleşmesidir. Bir token için Permit2'ye yalnızca bir kez zincir üzerinde onay görebilirsiniz, sonraki yetkilendirmeler ise ayrı approve() işlemleri yerine imzalı tip verisi mesajları aracılığıyla gerçekleşir.
Bir onayı tamamen iptal etmek yerine azaltabilir miyim?
Evet. İzni azaltmak, iptal etmekle aynı mekanizmadır, sadece 0 yerine daha küçük bir sayıya ayarlamaktır. Sıfır olmayan bir izni başka bir sıfır olmayan değere değiştirirken, daha güvenli operasyonel model “sıfıra onayla, sonra ayarla”dır.