A cracked red padlock with a broken shackle, set

چگونه تأییدهای مخرب را لغو کرده و مسیر نشت را ببندیم

By AI News Crypto Editorial Team8 دقیقه مطالعه

لغو تأییدیه‌های مخرب به معنای ارسال یک تراکنش زنجیره‌ای است که مجوز یک توکن را بازنویسی می‌کند و معمولاً آن را برای خرج‌کننده‌ای که می‌تواند از موجودی شما با transferFrom استفاده کند، به 0 تنظیم می‌کند. قطع اتصال یک کیف پول از یک dApp تنها یک عمل رابط کاربری است، بنابراین تأییدیه‌های توکن را حذف نمی‌کند یا مانع از فعالیت یک کیف پول خالی‌کننده که قبلاً مجوز خرج کردن دارد، نمی‌شود.

نکات کلیدی

  • یک تأییدیه توکن یک مجوز دائمی در قرارداد توکن است و تا زمانی که آن را در زنجیره تغییر ندهید، باقی می‌ماند.
  • برای لغو تأییدیه، شما یک تراکنش ارسال می‌کنید که مجوز خرج‌کننده را به 0 یا به مقدار کمتری تنظیم می‌کند و شما هزینه گاز را پرداخت می‌کنید.تأییدیه‌های نامحدود نسخه انفجاری مجوزها هستند زیرا یک خرج‌کننده آسیب‌پذیر می‌تواند موجودی توکن را تا حد مجوز خالی کند.Permit2 می‌تواند خطر را پشت امضاها پنهان کند: شما ممکن است تنها یک تأییدیه زنجیره‌ای برای Permit2 ببینید در حالی که خطر واقعی امضای یک مجوز مخرب EIP-712 است.
  • چرا تأییدیه‌های توکن می‌توانند خطرناک باشند
  • یک تأییدیه مخرب به معنای "اتصال dApp" نیست. این یک مجوز زنده است که در یک قرارداد توکن نشسته است و می‌گوید یک خرج‌کننده خاص می‌تواند توکن‌های شما را با transferFrom جابجا کند.

ERC-20

انتقال‌های نمایندگی بر روی سه تابع اجرا می‌شوند: approve(spender, amount)، allowance(owner, spender) و transferFrom(from, to, amount). هنگامی که آن مجوز وجود دارد، خرج‌کننده دیگر نیازی به کیف پول شما ندارد.

او فقط به این نیاز دارد که مجوز هنوز غیرصفر باشد.این پایداری کل مشکل است. مجوزها تا زمانی که به‌طور صریح تغییر نکنند، فعال باقی می‌مانند، به همین دلیل است که دکمه‌های "قطع اتصال کیف پول" و لیست‌های اتصال کیف پول حس کاذب ایمنی ایجاد می‌کنند. قطع اتصال توانایی یک سایت را برای درخواست کیف پول شما حذف می‌کند. این هیچ تأثیری بر وضعیت قرارداد توکن که واقعاً مجوز خرج کردن را تأیید می‌کند، ندارد. به همین دلیل است کهفیشینگ تأییدیه

عمل می‌کند: هدف حمله‌کننده این است که یک تأییدیه توکن (یا یک امضای سبک مجوز) را یک بار بگیرد و سپس از آن در زمانی که قربانی دیگر توجهی ندارد، استفاده کند.تأییدیه‌های نامحدود جایی هستند که خطر دنباله‌ای وجود دارد. بسیاری از رابط‌های کاربری به‌طور پیش‌فرض به "بی‌نهایت" تنظیم می‌شوند زیرا این کار اصطکاک آینده را کاهش می‌دهد، اما تأیید حداکثر مقدار uint256 به‌طور مؤثر به خرج‌کننده یک چک سفید برای آن توکن می‌دهد. اگر قرارداد خرج‌کننده امروز مخرب باشد یا بعداً مورد سوءاستفاده قرار گیرد، مجوز مسیر خالی کردن است.برای معامله‌گران، مدل ذهنی که کار می‌کند "خط اعتباری دائمی" است. هر تأییدیه توکن یک مورد خطی است: توکن → خرج‌کننده → حد. اگر خواننده نتواند به قرارداد دقیقی که در حال حاضر مجوز فراخوانی transferFrom را دارد (یا به‌طور مستقیم یا از طریق Permit2) اشاره کند، خطر واقعی ناشناخته است. این یکی از مکانیک‌های اصلی پشت کلاهبرداری‌های کیف پول رمزنگاری و چگونگی اجتناب از آن‌ها است.

چگونه لغو یک تأییدیه کار می‌کند

لغو یک تغییر تنظیمات نیست. این یک تغییر وضعیت در زنجیره است، به این معنی که هزینه گاز دارد و یک رکورد تراکنش باقی می‌گذارد. به‌طور مکانیکی، یک تأییدیه لغو فقط بازنویسی نقشه مجوز در قرارداد توکن است تا مجوز خرج‌کننده به 0 (یا یک عدد کوچکتر اگر هدف ادامه استفاده از برنامه با یک حد محدود باشد) تبدیل شود.

دو جزئیات عملی بیشتر از آنچه اکثر راهنماها اعتراف می‌کنند، اهمیت دارند.

یکی این است که "حذف تأییدیه توکن" خاص توکن است. لغو USDC برای یک خرج‌کننده هیچ تأثیری بر تأییدیه‌های WETH برای همان خرج‌کننده ندارد. دفترچه مجوز به ازای هر قرارداد توکن است.

دیگری این است که به‌روزرسانی‌های مجوز می‌توانند در هنگام تغییر یک مجوز غیرصفر N به یک مجوز غیرصفر دیگر M دارای یک حالت رقابتی باشند. الگوی ایمن‌تر همان چیزی است که Speedrun

Ethereum

به آن "تأیید به صفر سپس تنظیم" می‌گوید. ایده ساده است: ابتدا مجوز را به 0 تنظیم کنید، منتظر تأیید بمانید، سپس مقدار جدید را تنظیم کنید.

این پنجره‌ای را که یک خرج‌کننده می‌تواند به‌طور بالقوه از هر دو مقدار مجوز قدیمی و جدید استفاده کند، حذف می‌کند.اگر یک کیف پول یا dApp خطاهایی مانند "تأیید به صفر ناموفق بود" یا "تأیید به مقدار جدید ناموفق بود" را نشان دهد، معمولاً نشانه‌ای نیست که لغو غیرممکن است. این نشانه‌ای است که رفتار تأییدیه توکن عجیب است یا رابط کاربری به‌درستی قوانین توکن را مدیریت نمی‌کند. راه‌حل این است که از یک ابزار مجوز متفاوت یا رابط تأییدیه توکن یک کاوشگر بلاک استفاده کنید، سپس همان تغییر زنجیره‌ای را دوباره امتحان کنید.چارچوب کلیدی ثابت می‌ماند: لغو به سادگی بازنویسی مجوز در زنجیره است. اگر خواننده نتواند خرج‌کننده‌ای که مجوز را در اختیار دارد شناسایی کند، لغو نمی‌تواند به‌درستی هدف قرار گیرد.

لغو مرحله به مرحله با استفاده از Revoke.cash

Revoke.cash یک جریان کاری رایج است زیرا تأییدیه‌ها را در یک داشبورد واحد نمایش می‌دهد و به کاربر اجازه می‌دهد تراکنش لغو زنجیره‌ای را از همان صفحه ارسال کند. مراحل زیر جریان در کیف پول را که Bifrost Wallet مستند کرده است، منعکس می‌کند، اما توالی به‌طور کلی در تمام کیف پول‌ها یکسان است.

1. یک مرورگر کیف پول معتبر باز کنید و به Revoke.cash بروید. استفاده از یک مرورگر در کیف پول شانس فرود بر روی یک دامنه مشابه از تبلیغات یا پیام‌های مستقیم را کاهش می‌دهد. 2. کیف پول را متصل کنید و شبکه صحیح را انتخاب کنید. تأییدیه‌ها خاص زنجیره هستند، بنابراین یک تأییدیه Ethereum زمانی که ابزار به Flare، Base یا زنجیره EVM دیگری تنظیم شده باشد، نمایش داده نمی‌شود. 3. نمای تأییدیه‌های توکن را باز کنید و بر اساس خطر مرتب کنید. با مجوزهای نامحدود و توکن‌هایی با موجودی‌های معنادار شروع کنید، زیرا این‌ها بالاترین مسیرهای خالی کردن تأثیر را دارند. 4. خرج‌کننده را برای هر ردیف پرخطر شناسایی کنید. خرج‌کننده قراردادی است که می‌تواند transferFrom را فراخوانی کند. اگر نام خرج‌کننده آشنا به نظر نمی‌رسد، تا زمانی که خلاف آن ثابت نشود، آن را به‌عنوان خصمانه در نظر بگیرید. 5. برای تأییدیه‌های انتخاب شده روی لغو کلیک کنید. این یک تراکنش ارسال می‌کند که مجوز را برای آن توکن و خرج‌کننده به 0 تنظیم می‌کند. 6. تراکنش را در کیف پول تأیید کنید و هزینه گاز را پرداخت کنید. اگر هزینه گاز بالا است، لغو بزرگ‌ترین مجوزها در ابتدا هنوز یک معامله "حق بیمه" منطقی است. 7. پس از تأیید، لیست تأییدیه را دوباره بررسی کنید. مجوز اکنون باید به‌عنوان 0 نمایش داده شود، یا ردیف باید بسته به رابط کاربری ابزار ناپدید شود.

این پاسخ اصلی به چگونگی لغو تأییدیه‌ها است: کاربر هیچ چیزی را "غیرمتصل" نمی‌کند. کاربر در حال تغییر مجوز در قرارداد توکن است. اگر

کیف پول خالی‌کننده

قبلاً تأییدیه داشته باشد، این اقدام مسیری را که بسته می‌شود، می‌بندد.تأییدیه‌های Permit و Permit2 برای بررسیاواخر 2022 نقطه عطفی است که اکثر کاربران آن را از دست دادند.

Uniswap

روتر جهانی خود را به عنوان مسیر تأییدیه پیش‌فرض قرار داد، که بسیاری از "خطر تأییدیه" را از تراکنش‌های واضح approve() به سمت امضاهای EIP-712 منتقل کرد. Permit2 یک قرارداد تأییدیه تک‌تایی Uniswap Labs است: کاربران یک بار برای هر توکن Permit2 را تأیید می‌کنند، سپس برنامه‌ها درخواست مجوزهای امضا شده‌ای می‌کنند که شامل خرج‌کننده، مقدار، مهلت و nonce است.این دو دفترچه را ایجاد می‌کند تاحسابرسی

.دفترچه اول مجوزهای کلاسیک ERC-20 است: توکن → خرج‌کننده. این چیزی است که بیشتر داشبوردهای "تأییدیه توکن" نشان می‌دهند و جایی است که تأییدیه‌های نامحدود به قراردادهای تصادفی معمولاً زندگی می‌کنند.دفترچه دوم Permit2 است: توکن → مجوز Permit2 در زنجیره، به علاوه مجوزهای امضا شده خارج از زنجیره که برنامه‌ها درخواست می‌کنند. Permit2 از هر دو حالت مجوز دائمی و حالت انتقال یک‌بار پشتیبانی می‌کند و مجوزهای آن محدود به مهلت هستند.

مهلت‌ها می‌توانند خطر ناشی از مجوزهای غیرفعال را کاهش دهند زیرا مجوزها می‌توانند به‌طور خودکار منقضی شوند، اما آن‌ها دزدی امضا را حل نمی‌کنند. کمپین‌های فیشینگ تأییدیه به‌طور فزاینده‌ای به درخواست‌های امضای Permit و Permit2 هدف قرار می‌دهند زیرا یک پیام امضا شده واحد می‌تواند برای جابجایی وجوه کافی باشد.

پیامد عملی ناراحت‌کننده اما واضح است: "من هیچ چیزی را تأیید نمی‌کنم" یک سیگنال ایمنی نیست. یک کاربر می‌تواند پس از امضای داده‌های تایپ شده که هرگز شبیه یک تراکنش approve() در تاریخچه‌اش به نظر نمی‌رسد، در معرض خطر قرار گیرد.

هنگام پاکسازی پس از یک ترس، حسابرسی باید به یک سوال برای هر توکن پاسخ دهد: کدام قرارداد می‌تواند در حال حاضر یک transferFrom از این توکن از این کیف پول ایجاد کند؟ گاهی اوقات این یک خرج‌کننده مستقیم است. گاهی اوقات این Permit2 است زیرا توکن به تک‌تایی تأیید شده و کاربر به‌طور کورکورانه درخواست‌های امضا را ادامه می‌دهد.

عادت جلوگیری از حوادث تکراری همان عادت است که در مورد چگونگی تأیید یک تراکنش قبل از امضا پوشش داده شده است: هر درخواست امضا را به‌عنوان مجوز خرج کردن در نظر بگیرید تا خلاف آن ثابت شود.

چک لیست پیشگیری پس از لغو شما

پس از تأیید تراکنش‌های لغو، هدف این است که از بازتولید همان خطر در دفعه بعدی که یک رابط کاربری مبادله، پل یا استیکینگ درخواست مجوز می‌کند، جلوگیری شود. وضعیت تمیز این است که تأییدیه‌ها را مانند اندازه‌گیری موقعیت در نظر بگیرید: حد باید با عمل مورد نظر مطابقت داشته باشد، نه حداکثر ممکن.

1. در صورت امکان تأییدیه‌های مقدار دقیق را ترجیح دهید. تأییدیه‌های نامحدود راحت هستند، اما همچنین بالاترین حالت شکست تأثیرگذار هستند اگر خرج‌کننده آسیب‌پذیر باشد. 2. اگر یک مجوز باید از یک مقدار غیرصفر به مقدار غیرصفر دیگری تغییر کند، از "تأیید به صفر سپس تنظیم" استفاده کنید. این یک عادت عملی کوچک است که خطر حالت رقابتی شناخته شده را کاهش می‌دهد. 3. تأییدیه‌ها را به‌طور دوره‌ای با یک ردیاب مجوز مرور کنید. ابزارهایی که در راهنمای امنیت کاربر نام برده شده‌اند شامل Etherscan Token Approvals، Revoke.cash، Debank و Unrekt هستند. 4. درخواست‌های Permit و Permit2 را به‌عنوان لحظات با ریسک بالا در نظر بگیرید. Permit2 از امضاهای EIP-712 با مهلت و nonce استفاده می‌کند، اما فیشینگ امضا هنوز راه اصلی است که کاربران خالی می‌شوند. 5. مدل "دو دفترچه" را روی میز نگه دارید: مجوزهای کلاسیک و Permit2. لغو یک خرج‌کننده تصادفی کمکی نمی‌کند اگر توکن هنوز به Permit2 تأیید شده باشد و کیف پول همچنان از یک سایت تأیید نشده مجوزهای امضا را امضا کند.

این جایی است که دیسیپلین وسیع‌تر کلاهبرداری‌های کیف پول رمزنگاری و چگونگی اجتناب از آن‌ها عملی می‌شود: کاهش مجوزهای دائمی، تأیید آنچه امضا می‌شود و پرداخت هزینه گاز برای بستن خطوط قدیمی زمانی که دیگر مفید نیستند.

نتیجه

من شاهد بوده‌ام که مردم نسخه پرهزینه این پاکسازی را انجام می‌دهند: آن‌ها یک سایت را در کیف پول خود قطع می‌کنند، احساس امنیت می‌کنند و سپس دوباره مورد حمله قرار می‌گیرند زیرا مجوز در قرارداد توکن هرگز تغییر نکرده است. تنها سوالی که اهمیت دارد این است که آیا یک خرج‌کننده هنوز می‌تواند transferFrom را بر روی آن توکن فراخوانی کند. اگر پاسخ "بله" باشد، مسیر خالی کردن هنوز باز است.

عادت که این را ارزان نگه می‌دارد، این است که تأییدیه‌ها را مانند خطوط حاشیه در نظر بگیرید. آن‌ها را به معامله اندازه‌گیری کنید و وقتی چیزی احساس غیرعادی می‌کند، حتی اگر هزینه گاز زشت باشد، ابتدا تأییدیه‌های نامحدود را لغو کنید. اگر Permit2 از اواخر 2022 در جریان بوده است، عادت دوم این است که از امضای درخواست‌های EIP-712 که نمی‌توانید بخوانید، خودداری کنید. این جایی است که فیشینگ تأییدیه اکنون زندگی می‌کند.

منابع

اسپیدران اتریوم

پشتیبانی کیف پول بیفراست

  • پشتیبانی اکوسیستم
  • [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
  • [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

پرسش‌های متداول

آیا قطع اتصال کیف پول من از یک dApp تأییدیه‌های توکن را باطل می‌کند؟

خیر. قطع اتصال یک عمل در سطح رابط کاربری است و تأسیساتی که در قرارداد توکن ذخیره شده‌اند را تغییر نمی‌دهد. مصرف‌کننده هنوز می‌تواند تا مقدار تأیید شده از transferFrom استفاده کند تا زمانی که شما آن تأسیسات را در زنجیره باطل یا کاهش دهید.

چطور می‌توانم بفهمم کدام تأییدیه‌های توکن خطرناک‌ترین هستند؟

تأییدیه‌های نامحدود بیشترین تأثیر را دارند زیرا به یک مصرف‌کننده اجازه می‌دهند تا به اندازه توکن‌هایی که دارید، در صورت مخرب یا آسیب‌پذیر بودن، توکن‌ها را برداشت کند. تأییدیه‌های قدیمی به قراردادهایی که دیگر استفاده نمی‌کنید نیز سطح حمله رایجی هستند زیرا تا زمانی که تغییر نکنند، باقی می‌مانند.

آیا باطل کردن تأییدیه‌ها رایگان است؟

خیر. باطل کردن یک تراکنش در زنجیره است که وضعیت تأسیسات را به‌روزرسانی می‌کند، بنابراین هزینه گاز در شبکه‌ای که تأییدیه وجود دارد را دارد. این هزینه دلیل انباشت تأییدیه‌های غیرفعال در طول زمان در بسیاری از کیف پول‌ها است.

Permit2 چیست و چرا ممکن است من یک تراکنش approve() نبینم؟

Permit2 یک قرارداد تأییدیه تک‌نمونه از Uniswap Labs است که از امضاهای EIP-712 برای مجاز کردن هزینه‌کرد با مهلت‌ها و نانس‌ها استفاده می‌کند. شما ممکن است تنها یک تأییدیه یک‌باره در زنجیره برای Permit2 برای یک توکن ببینید، در حالی که مجوزهای بعدی از طریق پیام‌های داده‌نوع امضا شده به جای تراکنش‌های جداگانه approve() انجام می‌شود.

آیا می‌توانم تأییدیه را کاهش دهم به جای اینکه کاملاً باطل کنم؟

بله. کاهش تأسیسات همان مکانیزم باطل کردن است، فقط آن را به عدد کوچکتری به جای 0 تنظیم می‌کند. هنگام تغییر یک تأسیس غیرصفر به یک مقدار غیرصفر دیگر، الگوی عملی ایمن‌تر "approve-to-zero-then-set" است.