صفحه اصلی / بلاگدونی / وقتی منبع تأییدشده به ورودی حمله تبدیل می‌شود: دفاع از قراردادهای هوشمند در برابر اسکن آسیب‌پذیری مبتنی بر مدل‌های زبانی

وقتی منبع تأییدشده به ورودی حمله تبدیل می‌شود: دفاع از قراردادهای هوشمند در برابر اسکن آسیب‌پذیری مبتنی بر مدل‌های زبانی

وقتی منبع تأییدشده به ورودی حمله تبدیل می‌شود: دفاع از قراردادهای هوشمند در برابر اسکن آسیب‌پذیری مبتنی بر مدل‌های زبانی
بررسی هفتگی 1405/06/10 0 دیدگاه

خلاصه کاربردی

انتشار کد منبع قراردادهای هوشمند معمولاً بخشی از فرایند اعتمادسازی و ممیزی عمومی است؛ اما همین شفافیت می‌تواند به ورودی مناسبی برای ابزارهای خودکار کشف آسیب‌پذیری تبدیل شود. مقالهٔ When Verified Source Becomes Attack Input: Defending Smart Contracts Against LLM-Based Vulnerability Scanning چارچوب DeLLMGuard را برای پاسخ به این مسئله ارائه می‌کند.

ایدهٔ اصلی DeLLMGuard این است که کد قابل مشاهده برای کاربران و ممیزان، الزاماً همان کدی نباشد که مستقیماً منطق اجرایی قرارداد را در زمان اجرا تشکیل می‌دهد. این جداسازی با تکیه بر روابط proxy، delegate و factory انجام می‌شود تا تحلیل خودکار و گستردهٔ آسیب‌پذیری برای عامل‌های مبتنی بر مدل‌های زبانی دشوارتر شود، بدون آنکه اصل افشای عمومی کد کنار گذاشته شود.

نکته فنی مهم

در معماری‌های مبتنی بر proxy، قرارداد نماینده معمولاً درخواست‌ها را به قرارداد پیاده‌سازی منتقل می‌کند. در فراخوانی delegatecall نیز کد قرارداد مقصد در زمینهٔ ذخیره‌سازی و وضعیت قرارداد فراخواننده اجرا می‌شود. رابطه‌های factory هم می‌توانند مسیر ایجاد و ارتباط میان چندین قرارداد را پنهان یا پیچیده کنند. در نتیجه، بررسی یک فایل منبع منفرد لزوماً تصویر کاملی از منطق واقعی اجرا ارائه نمی‌دهد.

DeLLMGuard از همین ویژگی برای ایجاد فاصله میان «منبع افشاشده» و «مسیر اجرای واقعی» استفاده می‌کند. این روش به معنای حذف آسیب‌پذیری یا جایگزین شدن با ممیزی امنیتی نیست؛ بلکه هزینه و پیچیدگی تحلیل خودکار را افزایش می‌دهد. مقاله، این رویکرد را روی ۳۸۷ قرارداد آسیب‌پذیر و با سه عامل زبانی ارزیابی کرده است.

کاربرد برای توسعه‌دهندگان

  • اگر قرارداد شما به‌صورت عمومی تأیید و منتشر می‌شود، مسیر واقعی اجرای آن را نیز مستند کنید؛ از جمله آدرس proxy، قرارداد implementation و روابط ایجادشده توسط factory.
  • برای ارزیابی امنیتی، فقط فایل منبع تأییدشده را بررسی نکنید. گراف فراخوانی قراردادها، وضعیت ذخیره‌سازی، مجوزهای ارتقا و مسیرهای delegatecall باید هم‌زمان تحلیل شوند.
  • از جداسازی منبع و منطق اجرا به‌عنوان یک لایهٔ دفاعی استفاده کنید، نه جایگزین کنترل دسترسی، تست‌های واحد، fuzzing، ممیزی انسانی و پایش رخدادهای زنجیره‌ای.
  • در طراحی ابزارهای امنیتی داخلی، سناریوی استفادهٔ خصمانه از عامل‌های زبانی را در نظر بگیرید؛ یک عامل مهاجم می‌تواند کد، ABI، تراکنش‌ها و روابط میان قراردادها را در مقیاس بالا ترکیب کند.

منبع اصلی

عنوان: When Verified Source Becomes Attack Input: Defending Smart Contracts Against LLM-Based Vulnerability Scanning

نویسندگان: Mingyuan Huang؛ Zimo Ji؛ Yifan Mo؛ Shuai Wang

تاریخ انتشار: ۲۸ اوت ۲۰۲۶

arXiv: https://arxiv.org/abs/2608.28400

برداشت من

برداشت من از این مطلب این است که شفافیت در قراردادهای هوشمند دیگر فقط یک مزیت امنیتی نیست و می‌تواند سطح حملهٔ جدیدی برای ابزارهای خودکار ایجاد کند. راهکارهایی مانند DeLLMGuard نشان می‌دهند که آیندهٔ امنیت قراردادهای هوشمند احتمالاً به تعادل میان قابلیت ممیزی عمومی و دشوار کردن بهره‌برداری خودکار وابسته است. با این حال، این جداسازی باید به‌عنوان یک لایهٔ دفاعی مکمل دیده شود؛ زیرا مهاجم حرفه‌ای می‌تواند روابط proxy و delegate را نیز بازسازی کند و در نهایت، امنیت واقعی همچنان به طراحی صحیح، کنترل دسترسی و ممیزی عمیق وابسته است.

دیدگاه‌ها

0 دیدگاه تاییدشده

هنوز دیدگاهی تایید نشده است.

بازگشت به بلاگدونی