A cracked red padlock with a broken shackle, set

दुष्ट अनुमतियों को रद्द कर रास्ता बंद करने के तरीके

By AI News Crypto Editorial Team8 मिनट का पठन

दुष्ट अनुमतियों को रद्द करना एक ऑन-चेन लेनदेन प्रस्तुत करने का मतलब है जो एक टोकन की अनुमति को फिर से लिखता है, आमतौर पर इसे उस खर्च करने वाले के लिए 0 पर सेट करना जो आपके बैलेंस पर transferFrom को कॉल कर सकता है। एक वॉलेट को dApp से डिस्कनेक्ट करना केवल एक UI क्रिया है, इसलिए यह टोकन अनुमतियों को नहीं हटाता है या पहले से खर्च करने की अनुमति वाले वॉलेट ड्रेनर को रोकता है।

मुख्य निष्कर्ष

  • एक टोकन अनुमति एक स्थायी अनुमति है जो टोकन अनुबंध पर होती है, और यह तब तक बनी रहती है जब तक आप इसे ऑन-चेन नहीं बदलते।
  • अनुमति को रद्द करने के लिए, आप एक लेनदेन भेजते हैं जो खर्च करने वाले की अनुमति को 0 या छोटे मात्रा में सेट करता है, और आप गैस का भुगतान करते हैं।
  • अनलिमिटेड अनुमतियाँ भत्तों का एक विस्फोटक संस्करण हैं क्योंकि एक समझौता किया हुआ खर्च करने वाला उस टोकन संतुलन को भत्ते तक समाप्त कर सकता है।
  • परमिट2आप हस्ताक्षरों के पीछे जोखिम छिपा सकते हैं: आप केवल Permit2 के लिए एक ऑन-चेन स्वीकृति देख सकते हैं जबकि असली खतरा एक दुर्भावनापूर्ण EIP-712 अधिकरण पर हस्ताक्षर करना है।

टोकन अनुमतियाँ क्यों खतरनाक हो सकती हैं

एक दुर्भावनापूर्ण स्वीकृति "एकडीएपीपी"संयोग।" यह एक टोकन अनुबंध पर एक सक्रिय अनुमति है जो कहती है कि एक विशेष व्ययकर्ता आपके टोकन को transferFrom के साथ स्थानांतरित कर सकता है।ईआरसी-20डेलीगेटेड ट्रांसफर तीन कार्यों पर चलते हैं: approve(spender, amount), allowance(owner, spender), और transferFrom(from, to, amount)। एक बार जब वह अलाउंस मौजूद होता है, तो स्पेंडर को फिर से आपके वॉलेट की आवश्यकता नहीं होती। इसे बस यह सुनिश्चित करना होता है कि अलाउंस अभी भी गैर-शून्य हो।

वही स्थिरता पूरी समस्या है। भत्ते तब तक सक्रिय रहते हैं जब तक कि उन्हें स्पष्ट रूप से नहीं बदला जाता, यही कारण है कि "वॉलेट डिस्कनेक्ट करें" बटन और वॉलेट कनेक्शन सूचियाँ सुरक्षा का झूठा एहसास देती हैं। डिस्कनेक्ट करने से एक साइट की आपके वॉलेट को प्रॉम्प्ट करने की क्षमता समाप्त हो जाती है। यह वास्तव में खर्च करने के लिए अधिकृत टोकन अनुबंध की स्थिति पर कुछ नहीं करता। यही कारण हैअनुमति फ़िशिंगकाम करता है: हमलावर का लक्ष्य एक टोकन अनुमोदन (या अनुमति-शैली हस्ताक्षर) प्राप्त करना है एक बार, फिर इसका उपयोग करना जब पीड़ित अब ध्यान नहीं दे रहा हो।

असीमित अनुमतियाँ वह जगह हैं जहाँ पूंछ का जोखिम होता है। कई यूआई डिफ़ॉल्ट रूप से "असीमित" होते हैं क्योंकि यह भविष्य की बाधाओं को कम करता है, लेकिन अधिकतम uint256 राशि को अनुमोदित करना प्रभावी रूप से खर्च करने वाले को उस टोकन के लिए एक खाली चेक सौंपता है। यदि खर्च करने वाला अनुबंध आज दुर्भावनापूर्ण है, या बाद में इसका शोषण किया जाता है, तो अनुमति निकासी का रास्ता है।

व्यापारियों के लिए, मानसिक मॉडल जो कायम रहता है वह है "स्थायी क्रेडिट लाइन।" प्रत्येक टोकन अनुमोदन एक लाइन आइटम है: टोकन → खर्च करने वाला → सीमा। यदि पाठक उस सटीक अनुबंध की ओर इशारा नहीं कर सकता है जिसे वर्तमान में transferFrom कॉल करने की अनुमति है (या तो सीधे, या Permit2 के माध्यम से), तो वास्तविक जोखिम अज्ञात है। यह क्रिप्टो वॉलेट धोखाधड़ी के पीछे के मुख्य तंत्रों में से एक है और उनसे कैसे बचें।

अनुमति को रद्द करने का तरीका

रद्द करना सेटिंग्स टॉगल नहीं है। यह ऑन-चेन पर एक स्थिति परिवर्तन है, जिसका अर्थ है कि यह गैस की लागत है और यह एक लेनदेन रिकॉर्ड छोड़ता है। यांत्रिक रूप से, एक रद्द अनुमोदन बस टोकन अनुबंध पर अनुमति मैपिंग को फिर से लिखना है ताकि खर्च करने वाले की अनुमति 0 (या एक छोटे संख्या यदि लक्ष्य ऐप का उपयोग करना जारी रखना है एक सीमित सीमा के साथ) हो जाए।

दो परिचालन विवरण अधिकांश मार्गदर्शिकाओं की तुलना में अधिक महत्वपूर्ण हैं।

एक यह है कि "टोकन अनुमोदन हटाएँ" टोकन-विशिष्ट है। एक खर्च करने वाले के लिए USDC को रद्द करना उसी खर्च करने वाले के लिए WETH अनुमतियों के लिए कुछ नहीं करता है। अनुमति खाता प्रति टोकन अनुबंध है।

दूसरा यह है कि अनुमति अपडेट करते समय एक गैर-शून्य अनुमति N को एक अन्य गैर-शून्य अनुमति M में बदलने पर एक दौड़-स्थिति किनारे का मामला हो सकता है। सुरक्षित पैटर्न वह है जो Speedrunएथेरियमको कहते हैं “approve-to-zero-then-set।” विचार सरल है: पहले भत्ता 0 पर सेट करें, पुष्टि का इंतजार करें, फिर नया राशि सेट करें। इससे वह विंडो हट जाती है जहां एक खर्च करने वाला संभावित रूप से पुराने और नए भत्ता मूल्यों दोनों का उपयोग कर सकता है।

यदि एक वॉलेट या dApp त्रुटियाँ फेंकता है जैसे “Approve to zero failed” या “Approve to new amount failed,” तो यह आमतौर पर इस बात का संकेत नहीं है कि रद्द करना असंभव है। यह इस बात का संकेत है कि टोकन की स्वीकृति व्यवहार अजीब है या UI टोकन के नियमों को साफ-सुथरे तरीके से संभाल नहीं रहा है। समाधान यह है कि एक अलग भत्ता उपकरण या एक block explorer के टोकन स्वीकृति इंटरफेस का उपयोग करें, फिर उसी ऑन-चेन परिवर्तन को फिर से प्रयास करें।

मुख्य ढांचा स्थिर रहता है: रद्द करना बस ऑन-चेन अनुमति को फिर से लिखना है। यदि पाठक उस खर्च करने वाले की पहचान नहीं कर सकता जो अनुमति रखता है, तो रद्द करना सही तरीके से लक्षित नहीं किया जा सकता।

Revoke.cash का उपयोग करके चरण-दर-चरण रद्दीकरण

Revoke.cash एक सामान्य कार्यप्रवाह है क्योंकि यह एक ही डैशबोर्ड में अनुमतियों को प्रदर्शित करता है और उपयोगकर्ता को उसी स्क्रीन से ऑन-चेन रद्दीकरण लेनदेन सबमिट करने की अनुमति देता है। नीचे दिए गए चरण Bifrost Wallet दस्तावेज़ों के इन-वॉलेट प्रवाह को दर्शाते हैं, लेकिन अनुक्रम वॉलेट के बीच में व्यापक रूप से समान है।

1. एक विश्वसनीय वॉलेट ब्राउज़र खोलें और Revoke.cash पर जाएं। इन-वॉलेट ब्राउज़र का उपयोग करने से विज्ञापनों या DMs से समान डोमेन पर पहुंचने की संभावना कम हो जाती है। 2. वॉलेट को कनेक्ट करें और सही नेटवर्क का चयन करें। अनुमतियाँ श्रृंखला-विशिष्ट होती हैं, इसलिए एक एथेरियम स्वीकृति तब नहीं दिखेगी जब उपकरण Flare, Base, या अन्य EVM श्रृंखला पर सेट हो। 3.

टोकन अनुमतियों का दृश्य खोलें और जोखिम के अनुसार क्रमबद्ध करें। अनलिमिटेड भत्तों और महत्वपूर्ण संतुलन वाले टोकनों के साथ शुरू करें, क्योंकि ये उच्चतम प्रभाव वाले ड्रेन पथ हैं। 4. प्रत्येक जोखिम भरे पंक्ति के लिए खर्च करने वाले की पहचान करें। खर्च करने वाला वह अनुबंध है जो transferFrom को कॉल कर सकता है। यदि खर्च करने वाले का नाम अपरिचित लगता है, तो इसे शत्रुतापूर्ण समझें जब तक कि अन्यथा साबित न हो। 5.

चयनित अनुमतियों के लिए रद्द करें पर क्लिक करें। यह एक लेनदेन सबमिट करता है जो उस टोकन और खर्च करने वाले के लिए भत्ते को 0 पर सेट करता है। 6. वॉलेट में लेनदेन की पुष्टि करें और गैस का भुगतान करें। यदि गैस उच्च है, तो सबसे बड़े भत्तों को पहले रद्द करना अभी भी एक तार्किक “बीमा प्रीमियम” व्यापार है। 7. पुष्टि के बाद अनुमति सूची को फिर से जांचें। भत्ता अब 0 के रूप में प्रदर्शित होना चाहिए, या पंक्ति उपकरण के UI के आधार पर गायब हो जानी चाहिए।

यह उस प्रश्न का मूल उत्तर है कि अनुमतियों को कैसे रद्द किया जाए: उपयोगकर्ता कुछ भी "अनलिंक" नहीं कर रहा है। उपयोगकर्ता टोकन अनुबंध पर अनुमति को बदल रहा है। यदि वॉलेट ड्रेनर के पास पहले से ही अनुमोदन है, तो यह कार्रवाई उस पथ को बंद करती है।

पर्मिट और Permit2 अनुमतियों की जांच करने के लिए

देर 2022 वह मोड़ है जिसे अधिकांश उपयोगकर्ता चूक गए। Uniswap का यूनिवर्सल राउटर Permit2 को डिफ़ॉल्ट अनुमोदन पथ बना दिया, जिसने बहुत सारे "अनुमोदन जोखिम" को स्पष्ट approve() लेनदेन से हटा दिया और EIP-712 हस्ताक्षरों की ओर स्थानांतरित कर दिया। Permit2 एक Uniswap लैब्स सिंगलटन अनुमोदन अनुबंध है: उपयोगकर्ता प्रत्येक टोकन के लिए एक बार Permit2 को अनुमोदित करते हैं, फिर ऐप्स हस्ताक्षरित प्राधिकरणों का अनुरोध करते हैं जिसमें व्ययकर्ता, राशि, समय सीमा और नॉनस शामिल होते हैं।

यह ऑडिट करने के लिए दो लेजर बनाता है।

लेजर एक क्लासिक ERC-20 अनुमतियाँ हैं: टोकन → व्ययकर्ता। यही वह है जो अधिकांश "टोकन अनुमोदन" डैशबोर्ड दिखाते हैं, और यही वह जगह है जहाँ यादृच्छिक अनुबंधों के लिए अनलिमिटेड अनुमतियाँ आमतौर पर रहती हैं।

लेजर दो Permit2 है: ऑन-चेन पर टोकन → Permit2 अनुमति, साथ ही ऑफ-चेन हस्ताक्षरित प्राधिकरण जो ऐप्स अनुरोध करते हैं। Permit2 दोनों स्थायी अनुमति मोड और एक-बार ट्रांसफर मोड का समर्थन करता है, और इसके प्राधिकरण समय सीमा-बंधन होते हैं। समय सीमाएँ निष्क्रिय अनुमतियों से जोखिम को कम कर सकती हैं क्योंकि प्राधिकरण स्वचालित रूप से समाप्त हो सकते हैं, लेकिन वे हस्ताक्षर चोरी को हल नहीं करते। अनुमोदन फ़िशिंग अभियानों का लक्ष्य अधिक से अधिक Permit और Permit2 हस्ताक्षर संकेतों को लक्षित करना है क्योंकि एक एकल हस्ताक्षरित संदेश फंड को स्थानांतरित करने के लिए पर्याप्त हो सकता है।

व्यावहारिक निहितार्थ असुविधाजनक लेकिन स्पष्ट है: "मुझे कुछ भी अनुमोदित करने की याद नहीं है" एक सुरक्षा संकेत नहीं है। एक उपयोगकर्ता उस टाइप की गई डेटा पर हस्ताक्षर करने के बाद उजागर हो सकता है जो उनके इतिहास में कभी भी approve() लेनदेन की तरह नहीं दिखा।

एक डरावनी स्थिति के बाद सफाई करते समय, ऑडिट को प्रत्येक टोकन के लिए एक प्रश्न का उत्तर देना चाहिए: कौन सा अनुबंध वर्तमान में इस वॉलेट से इस टोकन का transferFrom कर सकता है?

कभी-कभी यह एक सीधा व्ययकर्ता होता है। कभी-कभी यह Permit2 होता है क्योंकि टोकन सिंगलटन के लिए अनुमोदित है और उपयोगकर्ता अंधाधुंध संकेतों पर हस्ताक्षर करना जारी रखता है। वह आदत जो दोहराए गए घटनाओं को रोकती है, उसी पर आधारित है जो हस्ताक्षर करने से पहले लेनदेन को सत्यापित करने के तरीके में कवर किया गया है: हर हस्ताक्षर अनुरोध को व्यय प्राधिकरण के रूप में मानें जब तक कि अन्यथा साबित न हो।

आपके रद्द करने के बाद रोकथाम चेकलिस्ट

रद्द करने के लेनदेन की पुष्टि के बाद, लक्ष्य यह है कि अगली बार जब स्वैप, ब्रिज या स्टेकिंग UI अनुमति मांगता है, तो वही जोखिम फिर से न बनाएं। साफ स्थिति यह है कि अनुमतियों को स्थिति आकार के रूप में मानें: सीमा को इच्छित कार्रवाई से मेल खाना चाहिए, अधिकतम संभव नहीं।

1. UI की अनुमति देने पर सटीक-राशि अनुमोदनों को प्राथमिकता दें। अनलिमिटेड अनुमोदन सुविधाजनक होते हैं, लेकिन यदि खर्च करने वाला समझौता किया गया है, तो वे सबसे उच्च-प्रभाव विफलता मोड भी होते हैं। 2. यदि एक गैर-शून्य मान से दूसरे में अनुमति बदलनी है, तो "शून्य पर अनुमोदित करें फिर सेट करें" का उपयोग करें। यह एक छोटा संचालनात्मक आदत है जो एक ज्ञात रेस-स्थिति जोखिम को कम करता है। 3.

अनुमोदनों की नियमित रूप से समीक्षा करें एक अनुमति ट्रैकर के साथ। उपयोगकर्ता-सुरक्षा मार्गदर्शन में नामित उपकरणों में Etherscan टोकन अनुमोदन, Revoke.cash, Debank, और Unrekt शामिल हैं। 4. परमिट और परमिट2 संकेतों को उच्च-जोखिम क्षणों के रूप में मानें। Permit2 EIP-712 हस्ताक्षरों का उपयोग करता है जिनमें समय सीमा और नॉनस होते हैं, लेकिन हस्ताक्षर फ़िशिंग अभी भी मुख्य तरीका है जिससे उपयोगकर्ता drained होते हैं। 5.

डेस्क पर "दो लेजर" मॉडल रखें: क्लासिक अनुमतियाँ और Permit2। एक यादृच्छिक खर्च करने वाले को रद्द करना मदद नहीं करता यदि टोकन अभी भी Permit2 के लिए अनुमोदित है और वॉलेट एक अप्रमाणित साइट से अनुमोदन पर हस्ताक्षर करता रहता है।

यहीं पर क्रिप्टो वॉलेट धोखाधड़ी और उन्हें कैसे टालें, का व्यापक अनुशासन कार्यात्मक हो जाता है: स्थायी अनुमतियों को कम करें, जो हस्ताक्षरित किया जा रहा है उसे सत्यापित करें, और जब वे उपयोगी नहीं रह जाएं तो पुराने लाइनों को बंद करने के लिए गैस का भुगतान करें।

लेना

मैंने लोगों को इस सफाई का महंगा संस्करण करते हुए देखा है: वे अपने वॉलेट में एक साइट को डिस्कनेक्ट करते हैं, सुरक्षित महसूस करते हैं, और फिर फिर से हिट होते हैं क्योंकि टोकन अनुबंध पर अनुमति कभी नहीं बदली। एकमात्र सवाल जो मायने रखता है वह यह है कि क्या एक खर्च करने वाला अभी भी उस टोकन पर transferFrom कॉल कर सकता है। यदि उत्तर "हाँ" है, तो ड्रेन पथ अभी भी खुला है।

जो आदत इसे सस्ता रखती है वह अनुमोदनों को मार्जिन लाइनों की तरह मानना है। उन्हें व्यापार के अनुसार आकार दें, और जब कुछ गलत लगता है, तो पहले अनलिमिटेड को रद्द करें भले ही गैस भद्दी हो। यदि Permit2 2022 के अंत से प्रवाह में है, तो दूसरी आदत उन EIP-712 संकेतों पर हस्ताक्षर करने से इनकार करना है जिन्हें आप नहीं पढ़ सकते। यही वह जगह है जहाँ अनुमोदन फ़िशिंग अब रहती है।

स्रोत

अक्सर पूछे जाने वाले प्रश्न

क्या dApp से मेरा वॉलेट डिस्कनेक्ट करने से टोकन अनुमतियाँ रद्द हो जाती हैं?

नहीं। डिस्कनेक्ट करना एक UI-स्तरीय क्रिया है और यह टोकन अनुबंध पर संग्रहीत अनुमति को नहीं बदलता। खर्च करने वाला अभी भी अनुमोदित राशि तक transferFrom का उपयोग कर सकता है जब तक कि आप उस अनुमति को ऑन-चेन रद्द या कम नहीं करते।

मैं कैसे जानूं कि कौन सी टोकन अनुमतियाँ सबसे खतरनाक हैं?

असीमित अनुमतियाँ सबसे अधिक प्रभाव डालती हैं क्योंकि वे खर्च करने वाले को उतने टोकन खींचने देती हैं जितने आपके पास हैं यदि यह दुर्भावनापूर्ण या समझौता किया गया हो। उन अनुबंधों के लिए पुरानी अनुमतियाँ जो आप अब उपयोग नहीं करते, भी सामान्य हमले की सतह हैं क्योंकि वे तब तक बनी रहती हैं जब तक कि उन्हें नहीं बदला जाता।

क्या अनुमतियाँ रद्द करना मुफ्त है?

नहीं। रद्द करना एक ऑन-चेन लेनदेन है जो अनुमति की स्थिति को अपडेट करता है, इसलिए यह उस नेटवर्क पर गैस की लागत लगाता है जहाँ अनुमोदन मौजूद है। यही लागत है कि कई वॉलेट समय के साथ निष्क्रिय अनुमतियाँ जमा करते हैं।

Permit2 क्या है और मैं approve() लेनदेन क्यों नहीं देख सकता?

Permit2 एक Uniswap Labs का सिंगलटन अनुमोदन अनुबंध है जो EIP-712 हस्ताक्षरों का उपयोग करके समय सीमा और नॉनस के साथ खर्च करने के लिए अधिकृत करता है। आप केवल एक बार के लिए ऑन-चेन अनुमोदन को Permit2 के लिए देख सकते हैं, जबकि बाद में प्राधिकरण हस्ताक्षरित टाइप-डेटा संदेशों के माध्यम से होते हैं न कि अलग-अलग approve() लेनदेन के माध्यम से।

क्या मैं अनुमोदन को पूरी तरह से रद्द करने के बजाय कम कर सकता हूँ?

हाँ। अनुमति को कम करना रद्द करने के समान तंत्र है, बस इसे 0 के बजाय छोटे संख्या पर सेट करना। जब एक गैर-शून्य अनुमति को दूसरे गैर-शून्य मान में बदलते हैं, तो सुरक्षित संचालन पैटर्न "approve-to-zero-then-set" है।