Bir cüzdan neden "imza olmadan" boşaltılabilir?
Bu kılavuzun amacı: izinlerin nasıl çalıştığını açıklayın
(onay, hakların verilmesi eylemidir, allowance kaydedilen harcama limitidir),
ana konuyu parçalamak
EVM aynı akıllı sözleşme yürütme kurallarını kullanan bir grup uyumlu blockchain ağıdır,
belirteç ve NFT yönetiminin bir izin sistemi etrafında oluşturulduğu yer.
Bu ağlarda approve, allowance ve
Buradaki temel güvenlik açığı, her harcamanın ayrı bir imza gerektireceği beklentisidir. Bir cüzdan arayüzünde imza sıradan bir adım gibi görünür (“izin ver”, “bağlan”, “takas için onayla”), böylece kullanıcı bir aktarımı değil, hakların verilmesini onaylar sözleşmede saklanır ve daha sonra başka bir onay penceresi olmadan kullanılır.
Gereksiz bir allowance
(kaç tokenin harcanabileceğini tanımlayan, sözleşmede kayıtlı bir limit)
bir stabilcoin veya aktif için
DeFi riskini onaylardan daha geniş bir şekilde değerlendirirseniz, kontrol listenize ayrı saldırı yüzeyleri ekleyin: dApp ön uçlar, köprüler, MEV, anahtarlar ve operasyonel hatalar. DeFi güvenlik kılavuzu: tehdit haritası ve kontrol listesi .
Onay kimlik avı, approve/permit aracılığıyla verilen izinleri kullanır
(bir allowance oluşturma veya değiştirme)
veya
Bir approve/permit imzası veya
Onay odaklı kimlik avı nedir ve "dürüstlüğü" neden sahtekârdır?
Bu bölümdeki anahtar terimler:
-
Harcama yapan sahibinin ERC-20 tokenlarını harcamasına izin verilen akıllı sözleşme adresidir
allowance aracılığıyla
transferFrom . -
Operatör sahibinin NFTs adresini aktarma hakkını almış bir adrestir.
setApprovalForAll , koleksiyon jetonlarının sayısında bir sınırlama olmaksızın. - Ödenek ERC-20 sözleşmesindeki maksimum jeton sayısını tanımlayan bir değerdir spender harcayabilir.
- Revoke allowance'yu sıfırlayan veya operator'yu devre dışı bırakan bir işlemdir, Varlıkları harcama veya devretme hakkının sona ermesi.
Onay kimlik avı normal izin mekanizmalarını kullanır: hakların verilmesi meşru görünür, anında fon kaybına neden olmaz ve bu nedenle genellikle imza anında bir risk olarak algılanmaz.
Onay kimlik avı Kullanıcının bir yetki vermeye ikna edildiği bir saldırıdır. izin (onay/allowance) veya NFTs'yu yönetirsiniz ve bu hak daha sonra varlıkları çekmek için kullanılır. Tehlikeli eylem, tanıdık bir arayüz adımı olarak gizlenmiştir: "takas için onayla", "darphaneye izin ver", "talep için imzala", "para yatırma için erişim izni ver".
Anahtar hırsızlığından farklı olarak saldırganın özel anahtara ve doğrudan para transferine ihtiyacı yoktur. Kullanıcının bunu yapması yeterli bir kez Belirli bir adrese varlıkları harcama hakkı verin: ERC-20 tokenleri için bir spender veya NFTs için bir operator. Bundan sonra para çekme işlemi, yeni cüzdan pencereleri olmadan ve sahibinin tekrarlanan onayları olmadan gerçekleştirilir.
Blockchain düzeyinde işlemler geçerli görünüyor: Kullanıcı gerçekten sözleşme durumunu değiştirdi ve belirli bir adrese haklar verdi. Bu nedenle cüzdan resmi olarak "saldırıya uğramaz": varlıklar, imzanın atlanması yoluyla değil, önceden verilen izinler yoluyla ayrılır.
Approve genellikle transfer etmiyor hemen fon sağlayın. Token sözleşmesine bir allowance limiti kaydeder, bundan sonra spender arayabilir
Denge değişmese de imza çoğu zaman güvenli olarak algılanıyor. ile sınırsız onay veya setApprovalForAllBir saldırgan, allowance sıfırlanana veya operator durumu devre dışı bırakılana kadar mevcut varlıkları ve gelecekteki yatırılan paraları çekebilir.
Basit bir ifadeyle: approve bir transfer değil, belirli bir adrese harcama hakkı verilmesidir. Onay kimlik avı, normal bir takas, darphane veya talep adımı olarak sunulurken, kullanıcının bu hakkı saldırgan tarafından kontrol edilen bir adrese vermesi için kandırılması anlamına gelir.
Onay kimlik avı, geçerli izinler aracılığıyla çalışır. Tehlike imzadan sonra, aktif harcama hakkının sahibinin katılımı olmadan kullanılmasıyla ortaya çıkar.
EVM'daki izinler, tek seferlik eylemlerin değil, sözleşmelerdeki hakların kayıtlarıdır; bu nedenle approve aylarca aktif kalabilir ve tekrarlanan bir imzaya gerek kalmadan kullanılabilir.
EVM'da izinler nasıl çalışır: allowance, spender ve "sonsuz approve"
EVM izni, adresinizi belirli bir spender/operator adresiyle bağlayan bir belirteç veya NFT sözleşmesindeki bir durum kaydıdır. Bu kayıt, jetonları kimlerin harcayabileceğini tanımlar
- ERC-20: approve → allowance → transferFrom
- Kullanıcı arar approve(spender, tutar) ve spender adresini belirtir.
- Token sözleşmesi şunları saklar: allowance limit — spender'nun harcayabileceği maksimum jeton sayısı.
- spender çağrıları transferFrom ve allowance 0 olana veya bitene kadar jetonları yeni imzalar olmadan harcar.
- Sözleşme sırasında allowance kontrol edilir.
transferFrom ; her harcama için sahibinin imzasını istemez.
- Ödenek sahibine bağlıdır → spender → jeton
- İzin yalnızca belirli bir belirteç ve belirli bir spender için mevcuttur.
- USDT için bir approve, USDC'ye erişim sağlamaz ve diğer sözleşmeleri kapsamaz.
- Her yeni token veya yeni spender, ayrı bir approve gerektirir.
- Sınırsız onay maksimum allowance değeridir
- Sınırsız approve ile allowance maksimum sayısal değeri saklar.
- spender, adrese gelecekte yapılacak para yatırma işlemleri de dahil olmak üzere, söz konusu sözleşmedeki tokenleri bu değer dahilinde harcama hakkını alır.
- Hizmet artık kullanılmasa bile izin, bir revoke işlemine kadar etkin kalır.
- NFT: setApprovalForAll, sınırı olmayan operator durumudur
- setApprovalForAll(operator, doğru) sahibinin tüm NFT koleksiyonu için operator durumunu etkinleştirir.
- Bu miktar veya değer açısından bir sınırlama değildir: hak, setApprovalForAll(operator, yanlış) gönderilir.
- operator ele geçirilirse, NFTs yeni sahibin onayı olmadan geri çekilebilir.
ERC-20 için sınırsız approve, harcanabilecek maksimum tutarı artırır
EVM izinleri, sözleşmelerdeki uzun ömürlü hak kayıtlarıdır. Bir approve aylarca çalışabilir, mevcut harcama limitini sınırsız artırır ve
Bir permit imzası (örneğin EIP-2612), uygulamaya imzalı bir mesaj yoluyla allowance ayarlama hakkını verir; uygulama daha sonra bu imzayı hakları veren bir işlemde kullanır ve eylemi tek bir çağrıda gerçekleştirir.
İzin, Permit2 ve mesaj imzaları: ayrı bir approve olmadan izinler nasıl verilir ve saldırganlar bunu neden kullanır?
Sıradan approve'ya ek olarak, EVM'nun ayrı bir işlem olmadan izin verme yolları vardır. Kullanıcı basitçe bir mesaj imzalıyorve uygulama bu imzayı kendi işleminde kullanır, hem harcama hakkını verir hem de takas, para yatırma veya talep etme eylemini gerçekleştirir. Bu mekanizmalara denir permit ve bunun gibi uzantılar Permit2.
UX açısından bakıldığında, bu daha az adım gibi görünüyor: ayrı bir approve işlemi yoktur ve ayrı bir approve çağrısı için gas gerekmez. Teknik sonuç aynıdır: Sözleşmede bir harcama hakkı belirir ve imza parametrelerinin geniş bir limit veya uzun bir süre sonu belirlemesi durumunda bu hak, tek bir işlem sonrasında da etkin kalabilir.
Kullanıcıların en sık karıştırdığı iki onay türü:
- İşlem (zincir üzerinde): approve / revoke / transfer — ağa gönderilir, gaz gerektirir ve sözleşme durumunu değiştirir.
- Mesaj imzası (zincir dışı): permit ve benzeri mekanizmalar — imzalama sırasında gaza gerek yoktur, ancak bir uygulamanın aynı erişim haklarını yüklemesine izin verirler.
| ⚙️ Mekanizma | 🧾 Verdiğin şey | 📍 Göründüğü yer | ⚠️ Anahtar risk |
|---|---|---|---|
| Approve (ERC-20) | spender için jeton harcama limiti | DEX, borç verme, çiftçilik, köprüler | Sınırsız allowance, revoke tarihine kadar aktif kalır |
| İzin (EIP-2612 ve analogları) | Ayrı bir approve olmadan imza yoluyla izin | "Tek tıklamayla" takaslar, toplayıcılar, DeFi arayüzleri | İmza "güvenli" görünüyor ancak gerçek hakları belirliyor |
| SetApprovalForAll (NFT) | Koleksiyonun tamamına küresel erişim | Pazar yerleri, darphaneler, kumar dApps | NFTs tekrarlanan onaylara gerek kalmadan aktarılabilir |
Anahtar nüans: approve ve permit aynı sonuca yol açar; belirli bir adres, sahibinin varlıklarını yönetme hakkını alır. Onay formu farklıdır: zincir üstü bir işlem veya daha sonra bir işlem içinde kullanılacak bir mesaj imzası.
İmza öncesi kontrol listesi (30 saniye): Bir imzanın harcama hakları verip vermediğini görmek için hızlı bir filtre.
- Ne doğrulanıyor? İzin veya approve erişim izni anlamına gelir.
- Kim erişim alır? Site tasarımına değil parametrelerdeki spender veya operator'ya bakın.
- Sınır nedir? Likit jetonların sınırsız olması mevcut harcama tutarını artırır.
- setApprovalForAll var mı? NFTs için bu, koleksiyondaki tam operator durumudur.
- Aciliyet var mı? Zaman baskısı genellikle insanların parametreleri kontrol etmeden imza atmasını sağlamak için kullanılır.
İzin ve “gazsız imzalar” yalnızca onay şeklini değiştirir. Bir mesaj imzası, tıpkı approve gibi belirteçlere veya NFTs'ya erişim hakları yükleyebilir, bu nedenle imza parametrelerinin izin verilenler olarak okunması gerekir.
Tipik onay amaçlı kimlik avı düzenlerinde, kullanıcı approve/permit veya permit imzalamaya yönlendirilir.
Tipik onay kimlik avı düzenleri: "doğru" imzaya nasıl yönlendirilirsiniz?
Bu şemalar tanıdık arayüzler ve standart iş akışları kullanıyor ve bu da izinlerin verilmesini sıradan bir hizmet adımı gibi gösteriyor.
Neredeyse tüm saldırılar aynı mantığı izliyor: Önce kullanıcı dApp arayüzüne benzeyen bir sayfaya getiriliyor, ardından sayfa harcama hakkı veya operator hakkı veren bir imza istiyor ve ardından aktif izin, yeni onaylar olmadan varlıkları çekmek için kullanılıyor.
En önemli özellik, transfer göndermek için doğrudan bir talebin olmamasıdır. Site, aktarım yerine approve/permit veya
- Popüler bir hizmetin klonu
- Sahte bir alan adı veya reklam bağlantısı, bir DEX'in veya pazar yerinin görsel olarak benzer bir kopyasına yönlendirir.
- Arayüz approve "takas için" ister veya
setApprovalForAll “NFT listesi için”. - İmza parametreleri, gerçek hizmete ait olmayan bir spender/operator içeriyor.
- Resmi kanalların uzlaşması
- Discord, Telegram veya X'te proje veya moderatör adına bir bağlantı yayınlanır.
- Aciliyet tetikleyicileri kullanılır: "sözleşme hatası", "nane geçişi", "son şans".
- Bağlantı, saldırganın adresi için approve/permit isteyen bir sayfaya yönlendiriyor.
- “Destek” yoluyla sosyal mühendislik
- Saldırgan, servis desteği gibi görünen özel bir mesaj gönderir.
- “Takılan işlemi iptal etme” bahanesiyle imza isteniyor.
- Pratikte kullanıcı bir permit imzalar veya üçüncü taraf bir adrese approve verir.
- İmza anlamının değiştirilmesi
- M-cüzdan penceresi, arayüzden net bir açıklama yapılmadan teknik bir çağrı görüntüler.
- Kullanıcı spender/operator adresini ve limiti kontrol etmeden onay verir.
- Arayüz spender, limit veya izin tipini göstermediğinde risk en yüksektir.
Örnek: bir kullanıcı bir cüzdanı bir "airdrop" sayfasına bağlar, Talep Et'e tıklar ve bir stabilcoin için sınırsız bir approve imzalar. Bakiye değişmez ancak daha sonra fonlar geldiğinde spender, tokenleri aracılığıyla çeker.
Bu saldırılar hemen geri çekilmeyi gerektirmez. Saldırgan, bakiyenin büyümesini veya likiditenin gelmesini bekleyebilir ve ardından aktif izni kullanabilir.
Tipik onay kimlik avı düzenleri, hakların verilmesini tanıdık eylemler olarak gizler. allowance veya operator durumu aktifken saldırgan, yeni sahibin onayı olmadan istediği an bunu kullanabilir.
Ödenek ve
Yaygın kullanıcı hataları: onaylar neden birikiyor ve bir tehdit haline geliyor?
Onay tehlikesi imzalama anında nadiren hissedilir çünkü approve genellikle dengeyi değiştirmez. Risk daha sonra harcama için etkin bir izin kullanıldığında ortaya çıkar ve bu tür izinlerin birkaç ağda ve birden fazla tokenda kalması durumunda daha da güçlenir.
En yaygın hata: stabilcoinler ve likit tokenler için sınırsız onay. İmzalama sırasında bu daha az adım gibi görünüyor, ancak teknik olarak bu, spender'nun tokenleri harcamasına olanak tanıyan büyük bir allowance anlamına geliyor.
için de aynı mantık geçerli
Markaya ve görsel tasarıma güvenmekten kaynaklanan ayrı bir hata sınıfı vardır. Kullanıcı etki alanına, logoya veya düzene odaklanır ancak izin her zaman belirli bir adrese verilir. spender veya operator. Arayüz değiştirilirse tasarım, imza parametrelerindeki adresi değiştirmez.
Diğer bir yaygın hata da sorunun bir ağda revoke sonrasında kapatıldığını düşünmektir. Onaylar ağ tarafından yalıtılmıştır: Ethereum'daki allowance ve Arbitrum'daki allowance, farklı sözleşmelerdeki farklı kayıtlardır, dolayısıyla bir izin başka bir ağda etkin kalabilir.
Likiditeyi ağlar arasında taşıyorsanız, zincirler arası işlemlerden sonra onayları kontrol edin: köprüler ve yönlendiriciler genellikle her ağda ayrı bir spender için approve gerektirir. Kripto köprüleri: nasıl çalışırlar ve hangisi daha güvenlidir.
Gazsız imzalar ek kafa karışıklığı yaratır. İzin ve benzeri mekanizmalar "yumuşak" onaylar olarak algılanır, ancak sonuç aynıdır: Uygulama, daha sonra harcama için kullanılacak bir izin yükleme yeteneği alır.
Bir cüzdan aynı anda depolama, aktif ticaret ve deneyler için kullanıldığında hatalar daha tehlikeli hale gelir. Bu modda, gereksiz bir spender/operator, orijinal operasyonun parçası olmayan varlıklara erişim sağlar.
Onayların ana tehdidi, bir görev tamamlandıktan sonra sözleşmelerde kalan aktif izinlerdir. Sınırsız allowance, etkin bir NFT operator ve çeşitli ağlardaki izinler, yeni onaylar olmadan harcanabilecek varlık miktarını artırır.
İzinler her ağ için ayrı ayrı kontrol edilmelidir: Ethereum'daki allowance ve operator listeleri Arbitrum, Optimism, Polygon veya BSC ile eşleşmiyor çünkü hak kayıtları belirli bir ağdaki sözleşmelerde saklanıyor.
İzinler nerede kontrol edilmeli: tam olarak ne kontrol edilmeli ve hangi sırayla
İzin incelemesi, ağ ve varlık türüne göre bir dizi adımdan oluşur. ERC-20 belirteçleri ve NFTs farklı erişim mekanizmaları kullanır, bu nedenle ayrı ayrı analiz edilmeli ve öncelik sırasına göre kapatılmalıdır: önce bilinmeyen adresler ve geniş sınırlar, ardından kalan çalışma izinleri.
- En fazla etkinliğe sahip ağı belirleyin
- İzinler "genel" değildir: Ethereum, Arbitrum, Optimism, Polygon ve BSC'nun ayrı onay listeleri vardır.
- Likiditenin yoğunlaştığı ve en son işlemlerin gerçekleştiği ağla başlayın.
- ERC-20 onaylarını kontrol edin ve gereksiz olanları azaltın
- Öncelik, stabilcoinler ve likit tokenlarda bilinmeyen spender'lara ve sınırsız allowance'ya verilir.
- Kullanılmayan izinleri kaldırın ve mevcut işlem için gereken miktara ilişkin limitleri azaltın.
- NFT onaylarını ayrı ayrı kontrol edin
- Özellikle dikkat edin
setApprovalForAll pazar yerleri ve oyunlar için dApps. - operator'yu yalnızca gerçekten ihtiyaç duyulduğu süre boyunca aktif tutun.
- Özellikle dikkat edin
- Etkin bıraktığınız adresleri doğrulayın
- İmzadaki veya gezgindeki adrese göre spender/operator adreslerini güvenilir hizmetlerle eşleştirin.
- Bir adres tanınamıyorsa allowance'yu sıfırlayın veya operator'yu devre dışı bırakın ve yalnızca gerektiğinde yeni bir izin verin.
| Yaklaşım | Neyi kontrol ediyor | Güçlü taraf | Sınırlama |
|---|---|---|---|
| Ağ blockchain tarayıcısı | ERC-20 allowance ve sıklıkla NFT onayları | dApp arayüzüne güvenmeden ağ verileri | Ağları değiştirmeniz ve adresleri analiz etmeniz gerekiyor |
| Revoke hizmetleri | Seçilen ağdaki belirteç ve NFT izinleri | allowance'yu sıfırlamak/operator'yu devre dışı bırakmak için Liste + düğmesi | Kapsam ağa ve entegrasyonlara bağlıdır |
| Simülasyonlu cüzdanlar | Harcama, limitler, imzalamadan önce uyarılar | Onaylanmadan önce hangi adresin hak alacağını gösterir | Farklı derinlikte onay ekranı |
İzin listesinde nelere dikkat edilmeli?
- Bilinmeyen spender veya operator. Adres tanınamıyorsa revoke adayıdır.
- Likit varlıklarda sınırsız allowance. Büyük bir allowance mevcut harcama tutarını artırır.
- L2s ve yan zincirlerdeki izinler. Uzun süre işlem yapmadığınız ağlarda onaylar aktif kalabilir.
- NFT operator'lar mevcut bir ihtiyaç olmadan. Etkin bir operator, yeni onaylar olmadan NFTs'yu aktarabilir.
- Proxy sözleşmeleri ve yükseltmeleri. Approve, spender adresine bağlıdır, dolayısıyla bir yükseltme yoluyla mantık değişse bile eski izin etkin kalır.
İnceleme mantığını: önce bilinmeyen adresler için allowance'ları sıfırlayın ve hassas belirteçler üzerindeki sınırsız izinleri kaldırın, ardından kalan sınırları mevcut işlemler için gereken miktara düşürün.
İzin incelemesi, izinlerin depolanma şekliyle eşleşmelidir: ayrı ağlar, ayrı belirteçler, ayrı spender'lar/operator'lar. Bilinmeyen ve sınırsız izinlere öncelik verilmesi, yeni onaylar olmadan harcamaya ilişkin ana senaryoları kapatır.
Revoke, sahip →spender→token çifti veya anahtarlar için allowance'yu 0'a ayarlayan bir işlemdir
revoke izinleri doğru şekilde nasıl yapılır: belirteçler, NFTs ve yaygın hatalar
Revoke, allowance'yu değiştiren veya bir NFT operator'yu devre dışı bırakan zincir içi bir işlemdir. Sonuç olarak, sözleşme yeni bir durumu kaydediyor: belirli bir adresin artık varlıklarınızı yönetme hakkı yok. Revoke gelecekteki harcamaları durdurur ancak halihazırda yürütülmüş olan işlemleri tersine çevirmez.
ERC-20 için adım adım revoke algoritması
- Ağı tanımlayın. Onaylar ağ tarafından yalıtılmıştır: Ethereum, Arbitrum, Optimism ve diğer L2s'nun ayrı izin listeleri vardır.
- Belirteci ve spender'yu bulun. Özellikle stabilcoinler ve likit varlıklar için token sözleşmesi adresini, token adını ve mevcut allowance limitini kontrol edin.
- revoke işlemini gerçekleştirin. Standart seçenek, allowance'yu approve(spender, 0) aracılığıyla 0'a ayarlamak veya bir hizmette bir revoke düğmesini kullanmaktır.
- Sonucu kontrol edin. allowance'nun 0 olduğundan ve iznin artık etkin olarak görüntülenmediğinden emin olun.
NFTs için adım adım revoke algoritması
- Koleksiyon operator listesini açın. Aktif ara
setApprovalForAll girişler ve ilgili operator adresleri. - operator'yu devre dışı bırakın. Durum false olarak değiştirilmelidir.
- Anahtar koleksiyonları için tekrarlayın. Önce en yüksek değere ve likiditeye sahip koleksiyonları kontrol edin.
Yaygın hata: revoke bir ağda yapılırken allowance veya operator durumu diğerinde etkin kalır. Köprüler, toplayıcılar ve çoklu ağ dApps kullandıysanız her ağdaki onayları ayrı ayrı kontrol edin.
ERC-20 nüansı: bazı belirteçler yeni bir allowance ayarlamadan önce approve(spender, 0) dizisini gerektirir. Bu durumlarda revoke limiti sıfırlayarak başlar.
Revoke, sözleşmedeki haklar kaydını değiştirir: allowance 0 olur veya operator devre dışı bırakılır. revoke'nun erişimi gerçekten kapatması için, bunun doğru ağda ve doğru token→spender veya koleksiyon→operator çifti için gerçekleştirilmesi gerekir.
approve/permit'yu verdiyseniz veya
Zaten tehlikeli bir approve verdiyseniz: hızlı bir hasar azaltma planı
Bu durumda eylemlerin sırası önemlidir: önce varlıkları etkin izinlerden uzaklaştırın, ardından allowance'yu sıfırlayın ve operator'yu devre dışı bırakın ve ancak bundan sonra imzanın kaynağını araştırın.
Eğer
- Varlıkları "temiz" bir adrese taşıyın. Yeni bir tohum ifadesine sahip yeni bir cüzdan, mevcut onaylarla bağlantıyı keser çünkü allowance ve operator eski sahibin adresine bağlıdır.
- Güvenliği ihlal edilen adrese ilişkin Revoke izinleri. Önce stabilcoinler ve likit tokenlar için, ardından kalan tokenlar için allowance'yu sıfırlayın.
- NFT izinlerini kontrol edin. Devre dışı bırak
setApprovalForAll gerekli olmayan operator'lar için. - M-cüzdandaki dApp oturumlarının bağlantısını kesin. Bu, allowance'yu değiştirmez ancak başka bir imza isteyebilecek etkin site oturumlarını kaldırır.
- Ortamı izole edin. Kötü amaçlı bir uzantı veya site değişikliği riski varsa başka bir tarayıcı veya cihaz kullanın.
Yabancılar tarafından önerilen "transferleri test etme", "güvenlik kontrolleri" veya "fon kurtarma" işlemlerini kabul etmeyin. Bu tür talepler genellikle yeni bir imza almak veya doğrudan transfer yapmak için kullanılır.
Tehlikeli bir izin verildikten sonra öncelik, allowance/operator aracılığıyla erişilebilen varlık miktarını azaltmak ve ardından revoke işlemleriyle bu hakları sıfırlamaktır. Haklar etkin kalsa da harcamalar yeni onaylar olmadan gerçekleşebilir.
Onay kimlik avının önlenmesi iki parametrenin kontrol edilmesine bağlıdır: hakkı kimin aldığı (spender/operator) ve bu hakkın ne kadar büyük veya kapsamlı olduğu (allowance veya
Önleme: Kolay bir hedef haline gelmeden nasıl izin verilir?
Onaylı kimlik avını önleme, izin yönetimi üzerine kuruludur: cüzdan rollerini ayırmak, allowance'yu sınırlamak ve görev tamamlandıktan sonra operator'yu devre dışı bırakmak.
Kayıpların çoğu, bir işlem tamamlandıktan sonra sözleşmelerde kalan etkin izinlere bağlıdır: sınırsız allowance, etkinleştirilmiş bir NFT operator ve adresi kontrol etmeden imzaları onaylama alışkanlığı. Bu hak kayıtları, revoke tarihine kadar yeni onay olmadan harcamaya izin verir.
Cüzdan rollerini ayırma
Depolama, ticaret ve deneyler için tek bir adres kullanmak, herhangi bir approve'yu o adresteki bakiyenin tamamı için kritik hale getirir. Adreslerin ayrılması, allowance veya operator yoluyla açığa çıkan varlıkların miktarını sınırlar. Uzun vadeli bir "depolama" cüzdanı seçerseniz, bir donanım kripto cüzdanı incelemesi ve aktif DeFi çalışmasından önce soğuk depoyu kurun.
🧩 Temel üç adresli kurulum
- Depolama (uzun vadeli): ana sermaye, minimum dApp etkileşimi, aktif onay yok.
- Operasyonel adres: düzenli DeFi etkinliği, sınırlı bakiye, planlanmış allowance ve operator incelemesi.
- Deneysel adres: airdrop'lar, NFTs, yeni projeler; risk, üzerinde depolanan miktarla sınırlıdır.
Her iznin kapsamının daraltılması
Güvenilir hizmetlerle çalışırken bile spender/operator hatası veya güvenlik ihlali senaryosunu göz önünde bulundurun. ERC-20 için hakkın kapsamı allowance ile tanımlanır; NFTs için kapsam şu şekilde tanımlanır:
- Kesin sınırları kullanın. Ödenek, bir spender'nun harcayabileceği maksimum jeton sayısını tanımlar.
- Görev tamamlandıktan sonra allowance'yu sıfırlayın. Bu, harcamaları doğrudan sona erdirir
transferFrom . - spender adresini kontrol edin. İzin bir “site”ye değil, imza parametrelerindeki adrese verilmektedir.
- Görevden sonra setApprovalForAll'yu devre dışı bırakın. Operatör, listeleme veya oyun oturumundan sonra aktif kalmamalıdır.
- Aciliyetten dolayı onaylamayınız. İmzanın denetlenmemesi için sıklıkla aciliyet kullanılır.
İnceleme modu: onaylar ne zaman kontrol edilmeli
- Tek seferlik bir operasyondan sonra. Hizmet düzenli olarak kullanılmıyorsa işlem tamamlandıktan sonra allowance'yu sıfırlayın veya operator'yu devre dışı bırakın.
- Operasyonel bir DeFi adresi için. Sürekli etkinlikle, onayları her bir ila iki haftada bir gözden geçirin ve gereksiz izinleri kaldırın.
- Deneysel bir adres için. Yeni dApps ve airdrop'lar için her oturumdan sonra izinleri kontrol edin ve kapatın.
Çalışma modeli: approve/permit belirli bir adrese erişim hakkı verir, allowance sınırı tanımlar, revoke sınırı 0 olarak değiştirir veya operator'yu devre dışı bırakır.
Onay önleme, aktif izin yönetimidir: adres ayırma, kesin allowance sınırları ve görevden sonra operator'nun devre dışı bırakılması, yeni onaylar olmadan harcanabilecek varlık miktarını azaltır.
Approve protokollerin çağrılmasını sağlar
Bir mekanizma olarak Approve: güçlü yönler ve yerleşik riskler
Approve, DeFi altyapısının temelidir: protokollerin,
approve mekanizması, varlıkları kendi adresinizde tutmak ile protokol eylemlerini otomatikleştirmek arasında bir dengedir. Varlıklar adresinizde kalır ancak sözleşme, bunları approve'da belirlenen allowance dahilinde harcama hakkını alır.
✅ approve'nun güçlü yönleri
- Varlıklar harcanıncaya kadar sahibinin adresinde kalır
transferFrom . - Protokoller allowance kullanarak her adımda imza olmadan işlem gerçekleştirebilir.
- Ödenek, belirli bir spender için maksimum harcama miktarını sınırlamayı mümkün kılar.
- İzinler zincir üzerinde doğrulanabilir ve bir revoke işlemiyle sıfırlanabilir.
❌ Onayların yerleşik riskleri
- İzin, revoke tarihine kadar etkin kalır ve bir sitenin kapatılmasına veya bir cüzdanın bağlantısının kesilmesine bağlı değildir.
- Sınırsız allowance, spender'nun ele geçirilmesi durumunda harcanabilecek token miktarını artırır.
- approve, spender ve limit kontrol edilmeden imzalanırsa yanlış adrese hak verilebilir.
SetApprovalForAll NFTs için operator'ya tüm koleksiyonu tek bir eylemle aktarma hakkı verir.
Approve, hakları yönetmeye yönelik bir altyapı mekanizmasıdır. Aktarım tekrarlanan imzalar olmadan allowance üzerinden yürütüldüğü için kullanışlıdır ve etkin bir izin revoke'ya kadar çalıştığı ve daha sonra harcama için kullanılabildiği için risklidir.
Vakalar ve dersler: Neden “doğru bir sözleşme” hala sorun olabiliyor?
Meşru hizmetlerle çalışırken bile etkin onaylar risk oluşturur: allowance zaten kayıtlıysa veya sözleşmede operator etkinleştirildiyse bir güvenlik açığı, yükseltme veya ön uç değişikliği tehlikeli hale gelir.
Onayların temel özelliği “ömür boyu” olmamasıdır. İzin verilmişse sözleşmenin tekrar approve talep etmesine gerek yoktur: önceden kaydedilmiş hakları kullanır. Bu nedenle risk yalnızca mevcut hizmete değil aynı zamanda adreste biriken onay listesine de bağlıdır.
🔓 Durum 1: meşru bir protokoldeki güvenlik açığı + sınırsız onay
Bir kullanıcı bir protokole sınırsız approve verir ve daha sonra harcama mantığında bir hata bulunur bu, sözleşmenin beklenenden daha fazla token harcamasına olanak tanır.
- Sözleşmede zaten allowance üzerinden harcama hakkı bulunuyor, dolayısıyla saldırı için yeni bir sahibin imzası gerekmiyor.
- Sınırsız allowance, harcama tutarını sahibinin adresindeki jeton bakiyesine kadar artırır.
- Yeni işlem yapmayan kullanıcılar, allowance sıfırlanana kadar savunmasız kalır.
Sınırsız approve, bir protokol hatasını adresteki tüm token bakiyesi için bir riske dönüştürür. Tam allowance maksimum harcamayı sınırlar ve revoke harcamayı doğru şekilde sonlandırır.
🧩 Durum 2: Proxy sözleşmesi yükseltmesi erişim davranışını değiştirir
Yükseltilebilir sözleşmeler aynı adresi korur ancak bu adresteki kod, bir yükseltme veya yönetim ihlali sonrasında değişebilir.
- Approve, belirli bir kod sürümüne değil, spender adresine bağlıdır.
- Yükseltme sonrasında yeni kod, allowance'yu sahibinin beklediğinden farklı şekilde kullanabilir.
- Eski allowance, bir işlem tarafından sıfırlanana kadar etkin kalır.
Protokoller yükseltildiğinde, allowance aynı spender adresinde aktif kaldığı için eski onaylar gözden geçirilmelidir.
🧠 Durum 3: Marka tanıdık kalırken kullanıcı arayüzünün değiştirilmesi
Kullanıcı tanıdık bir siteyi ziyaret eder, ancak arayüz DNS, reklamlar, CDN veya kötü amaçlı uzantılar aracılığıyla değiştirilir.
- Arayüzün görsel görünümü kullanıcının beklediğiyle eşleşiyor.
- Approve veya permit, hizmet sözleşmesi olmayan bir adrese verilir.
- İmzada spender/operator kontrol edildiğinde değişiklik ortaya çıkar; marka ve tasarım yoktur.
Alan adı ve sayfa tasarımına değil, imzadaki spender/operator adresine ve allowance sınırına güvenin.
🛰️ Durum 4: geniş erişim ağ geçidi olarak toplayıcılar ve yönlendiriciler
Toplayıcılar ve yönlendiriciler birçok rota ve protokol için tek bir spender kullanır.
- Bir spender adresi birçok senaryoya ve birçok belirtece hizmet eder.
- spender'nun güvenliği ihlal edilirse risk, allowance'yu veren herkese yayılır.
- Sınırsız allowance bu adres üzerinden harcanabilecek tutarı artırır.
Yönlendiriciler için allowance sınırı maksimum harcama tutarını tanımlar ve normal revoke artık gerekmeyen eski izinleri kaldırır.
🖼️ Durum 5: NFTs için setApprovalForAll yıllarca aktif kalır
- Bu operator durumudur, NFTs sayısına göre bir sınır değildir.
- Etkinlik olmasa bile operator tahsilat sözleşmesinde etkin durumda kalır.
- operator'nun güvenliğinin aşılması, NFTs'nun yeni bir sahibin imzası olmadan aktarılmasını mümkün kılar.
Devre dışı bırakılıyor
Bir allowance zaten kayıtlı olduğunda veya sözleşmede bir operator etkinleştirildiğinde bir olay mümkün olur. O anda harcamalar yeni sahibinin imzası olmadan gerçekleştirilebilir.
Uygulamada olaylar, işlemler tamamlandıktan sonra izinlerin kalması nedeniyle meydana gelir. Gereksiz allowance ve operator'ların düzenli olarak gözden geçirilmesi ve devre dışı bırakılması, varlık miktarını sınırlandırır yeni bir imza gerekmeden harcamaya müsaittir.
SSS, hangi imzaların hak verdiğini ve revoke'nun nasıl çalıştığını açıklığa kavuşturmaya yardımcı olur ve harcamaların neden tekrarlanan onay olmadan yapılabileceği.
Onay kimlik avı, approve ve revoke hakkında SSS
Bir şey imzaladıysam neden insanlar "imzasız tükendi" diyor?
İmza, fon aktarımı için değil, hakların verilmesi içindi. approve, permit veya sonra
Sınırsız approve her zaman bir hata mıdır?
Sınırsız approve, allowance'da çok büyük bir değer kaydeder. Bu, spender'nun harcayabileceği maksimum jeton sayısını artırır
revoke çalınan fonları iade edebilir mi?
Hayır. Revoke sözleşme durumunu yalnızca geleceğe yönelik olarak değiştirir: allowance 0 olur veya operator devre dışı bırakılır. Halihazırda yürütülmüş olan işlemler geri alınamaz.
Cüzdanı silmek veya "site bağlantısını kesmek" onayları kaldırır mı?
Hayır. İzinler zincir üzerinde token ve NFT sözleşmelerinin içinde saklanır. Bir sitenin bağlantısını kesmek veya bir uygulamayı silmek, sözleşmedeki allowance veya operator durumunu değiştirmez.
approve tam olarak nerede saklanıyor?
Akıllı sözleşme durumunda. ERC-20 için bu, allowance(sahip, spender) kaydıdır; NFTs için tahsilat sözleşmesindeki onaylar ve operator'lardır.
approve belirli bir miktarla sınırlandırılabilir mi?
Evet. approve çağrısı miktar parametresini iletir ve bu değer allowance'yu tanımlar. spender mevcut allowance permit'lardan daha fazlasını harcayamaz.
Hangisi daha tehlikeli: Bir jeton için approve mu yoksa NFT için setApprovalForAll mu?
Genellikle
Onayların L2s ve yan zincirlerde kontrol edilmesi gerekiyor mu?
Evet. Her ağ kendi hak kayıtlarını kendi sözleşmelerinde saklar. Ethereum'daki izin ve Arbitrum'daki allowance farklı değerlerdir; dolayısıyla yalnızca bir ağ kontrol edildiğinde diğer ağlardaki izinler gösterilmez.
Donanım cüzdanı onay kimlik avına karşı koruma sağlar mı?
Donanım cüzdanı, özel anahtarı ve imzalama sürecini cihazdaki hırsızlığa karşı korur ancak imzalanan eylemin anlamını değiştirmez. Tehlikeli bir approve/permit veya
SSS, doğrulanabilir bir farka dayanıyor: bir imza haklar verebilir (approve/permit/
Bir hatalı approve/permit veya
Kendinizi onay amaçlı kimlik avına karşı nasıl korursunuz ve izinleri kontrol altında nasıl tutabilirsiniz?
İzinler, DeFi mekaniğinin temelidir, ancak allowance ve operator durumu, hakkın gereksiz bir adrese verilmesi durumunda varlıkların tekrarlanan bir imza olmadan geri çekilmesine tam olarak izin veren şeydir.
Onay kimlik avı meşru hakların kötüye kullanılmasıdır. Bir approve/permit veya
Bir adres üzerinde aktif haklar bırakmaktan kaçınmak için somut eylemlerle kontrolü elinizde tutun:
- Erişim adresini kontrol edin. Önemli olan marka veya tasarım değil, imzadaki ve onay listesindeki spender/operator'dur.
- allowance'yu sınırlayın. Sınırsız yerine göreve özel bir sınır belirleyin ve hak artık gerekli olmadığında allowance'yu sıfırlayın.
- NFTs için operator'yu devre dışı bırakın. Ayrılma
setApprovalForAll eylem tamamlandıktan sonra etkinleştirilir. - Tüm ağları kontrol edin. İzin ve operator her ağda ayrı olarak depolanır; dolayısıyla dApp'nun kullanıldığı her ağı inceleyin.
- Adresleri role göre ayırın. Bir adresteki bakiye, o adres üzerindeki aktif haklar aracılığıyla harcanabilecek maksimum tutarı tanımlar.
Onayları, sözleşmelerde kayıtlı aktif erişim hakları olarak değerlendirin. Minimum allowance sınırları, devre dışı bırakılan operator'lar ve tüm ağlarda inceleme, yeni bir imza olmadan harcanabilecek varlık miktarını azaltır.