وضعیت امنیت قراردادهای هوشمند اتریوم: آسیب پذیری ها، اقدامات متقابل و پشتیبانی ابزار

قراردادهای هوشمند برنامه هایی هستند که خوداجرا می شوند و بر روی بلاک چین اجرا می شوند و امکان اجرای توافق نامه ها را بدون ضمانت شخص ثالث برای همتایان فراهم می کنند. قرارداد هوشمند اتریوم عنصر اساسی تامین مالی غیرمتمرکز با میلیاردها دلار ارزش است. قراردادهای هوشمند را نمی توان پس از استقرار تغییر داد و از این رو کد باید برای آسیب پذیری های احتمالی تأیید شود. با این حال، قراردادهای هوشمند از امن بودن فاصله زیادی دارند و حملاتی با سوء استفاده از آسیب پذیری هایی که منجر به زیان های میلیونی شده است. در این کار، ما وضعیت فعلی امنیت قراردادهای هوشمند، آسیب پذیری های رایج و پشتیبانی از ابزار تحلیل امنیتی را از طریق بررسی آخرین پیشرفت ها و تحقیقات منتشر شده در پنج سال گذشته بررسی می کنیم. ما ۱۳ آسیب پذیری در قراردادهای هوشمند اتریوم و اقدامات متقابل آن ها را مطالعه می کنیم و ۹ ابزار تحلیل امنیتی را بررسی می کنیم. یافته های ما نشان می دهد که مجموعه ای یکسان از تعاریف آسیب پذیری قرارداد هوشمند در کارهای تحقیقاتی وجود ندارد و اشکالات مربوط به مکانیسم های مشابه گاهی با نام های متفاوت ظاهر می شوند. این ناهماهنگی شناسایی، دسته بندی و تجزیه و تحلیل آسیب پذیری ها را دشوار می کند. ما برخی از رویکردهای حفاظتی و بهترین شیوه ها را توضیح می دهیم. با این حال، با بهبود فناوری، آسیب پذیری های جدیدی ممکن است ظاهر شوند. با توجه به پشتیبانی ابزار، ابزارهای SmartCheck، DefectChecker، contractWard و sFuzz از نظر پوشش بیشتر آسیب پذیری ها، انتخاب های بهتری هستند. با این حال، ابزارهایی مانند NPChecker، MadMax، Osiris و Sereum در صورت نیاز، دسته بندی خاصی از آسیب پذیری ها را هدف قرار می دهند. در حالی که contractWard نسبتاً سریع و دقیق تر است، فقط می تواند آسیب پذیری های از پیش تعریف شده را شناسایی کند. NPChecker کندتر است، با این حال، می تواند الگوهای آسیب پذیری جدیدی پیدا کند.

1. معرفی

ارزهای رمزنگاری شده و مالی غیرمتمرکز (DEFI) استفاده از blockchain برای انتقال وجوه در بین همسالان در شبکه های بدون واسطه را نشان می دهد. DEFI مدلی را پیشنهاد می کند که در آن شرکت کنندگان از طریق اجرای خودکار قراردادهای هوشمند مبتنی بر blockchain [1] معاملات انجام می دهند ، و حول برنامه های غیر متمرکز (DAPP) می چرخد که عملکردهای مالی را بر روی دفترچه های تغییر ناپذیر و قابل مشاهده به نام blockchain انجام می دهند. قراردادهای هوشمند برنامه هایی هستند که دستورالعمل ها را به صورت خودکار انجام می دهند. بیشتر DAPP ها قراردادهای هوشمندانه ای هستند که در یک شبکه blockchain اجرا می شوند و از پروتکل های اجماع آن برای ذخیره کدهای منبع خود استفاده می کنند و بندهایی را تحت قوانین از پیش تعریف شده برای ارائه خدمات قابل اعتماد اجرا می کنند [2].

Ethereum [3] اولین و برجسته ترین بستر است که از اجرای قراردادهای هوشمند در یک زبان برنامه نویسی سطح بالا ، مانند استحکام پشتیبانی می کند [4]. Ethereum دومین بستر بزرگ blockchain با سرمایه گذاری در بازار 317. 3 میلیارد دلار از ژوئن 2021 [5] است و یک محیط زمان اجرا را برای بیش از 95 ٪ برنامه های DEFI فراهم می کند [6،7]. بیت کوین [8] از توسعه و اجرای قراردادهای هوشمند نیز پشتیبانی می کند ، اما زبان اسکریپت که از آن استفاده می کند محدودیت هایی دارد ، مانند پشتیبانی از معاملات به سختی فراتر از تأیید امضاها [2]. در حالی که بیت کوین فقط یک سیستم رمزنگاری و پرداخت است که فرآیندهای پرداخت را تسهیل می کند ، Ethereum یک بستر محاسباتی است [9] که توسط دستگاه مجازی Ethereum (EVM) پشتیبانی می شود ، که یک دستگاه دولتی است که برای اجرای مخاطبین هوشمند که دولت در آن به آن اشاره می کند ، ایجاد می کندبه دفترچه

قرارداد هوشمند یک عنصر اساسی Defi است و از این رو امنیت آن از اهمیت بالایی برخوردار است. قراردادهای هوشمند پس از استقرار قابل تغییر نیست و بنابراین برای آسیب پذیری های احتمالی باید کد تأیید شود. حملات موفقیت آمیز به قراردادهای هوشمند باعث ضرر مالی قابل توجهی مانند حمله مشهور سازمان خودمختار مشهور (DAO) شده است که میلیون ها دلار تبخیر کرده و چنگال سخت اتریوم را مجبور کرده است [10]. تغییر ناپذیری ، عدم تمرکز و ویژگی های قابل مشاهده در تماس های هوشمند نه تنها منجر به پذیرش گسترده آنها می شود بلکه باعث ایجاد مشکلات می شود که از پذیرش بیشتر جلوگیری می کند. علاوه بر این ، زبان برنامه نویسی سطح بالا برای نوشتن قراردادهای هوشمند در مراحل اولیه است. سوء تفاهم از بهترین شیوه ها و سوء استفاده از برنامه نویسی نشان دهنده عدم آگاهی در مورد مسائل امنیتی در بین توسعه دهندگان قراردادهای هوشمند است.

در این مقاله ، ما با بررسی آخرین کارهایی که از سال 2018 منتشر شده است برای تکمیل مطالعات قبلی و پرداختن به سؤالات تحقیق زیر ، آسیب پذیری هایی را که مربوط به قراردادهای هوشمند است ، بررسی می کنیم:

RQ3: دقت ، کارآیی و محدودیت ابزارهای تحلیل امنیتی موجود برای قراردادهای هوشمند چیست؟

1. 1روش شناسی

ما مقالاتی را در مورد مجموعه مقالات کنفرانس ، مجلات ، پیش نویس ها ، پایان نامه ها و محتوای آنلاین برای پرداختن به سؤالات تحقیق خود مطالعه می کنیم. از آنجا که اتریوم رایج ترین بستر برای اجرای قراردادهای هوشمند است ، این مطالعه بر آسیب پذیری های اتریوم ، اقدامات متقابل و پشتیبانی از ابزار متمرکز است. ما Google Scholar ، کتابخانه دیجیتال ACM ، کتابخانه دیجیتال IEEE XPLORE ، کتابخانه آنلاین Springer و Arxiv را جستجو کردیم تا ادبیات مربوط به امنیت قرارداد هوشمند Ethereum را پیدا کنیم. این پایگاه داده ها شایع ترین مخازن برای مقالات مربوط به قراردادهای هوشمند هستند. در ابتدا حدود 100 مقاله تحقیقاتی مورد بازیابی و مورد مطالعه قرار گرفتند که از این تعداد حدود 50 مقاله برای بررسی نهایی بر اساس معیارهای محرومیت ما انتخاب شدند. ما مقالاتی را که به زبان های غیر از انگلیسی به زبان های غیر انگلیسی نوشته شده است ، مستثنی کردیم و آن را به قراردادهای هوشمند یا اتریوم بی ارتباط نداریم. سپس ارتباط اسناد جمع آوری شده را به سؤالات تحقیق خود از طریق عناوین و خلاصه های آنها بررسی کردیم. در مرحله بعد ، ما به لیست منابع مقالات منتخب خود اشاره کردیم و همان فرایند فیلتر را انجام دادیم. ما همچنین تأیید می کنیم که برخی از آسیب پذیری ها ، حملات یا ابزارهای اخیر ممکن است در نشریات دانشگاهی گزارش نشده باشد و از این رو با جستجوی گزارش ها و مقالات آنلاین از طریق جستجوی Google ، ادبیات خود را گسترش داده ایم.

1. 2مشارکت

در این کار ، ما آخرین کارهای پیشرفت و تحقیقاتی را که از سال 2018 منتشر شده است ، برای تکمیل مطالعاتی مانند [11،12،13] بررسی می کنیم. نظرسنجی ما همچنین شامل تجزیه و تحلیل مفقود شده از نظرسنجی های اخیر در مورد آسیب پذیری های امنیتی Smart-Contrount Smart ، حملات ، پیشگیری و ابزارها است [14،15،16،17،18،19]. ما 13 آسیب پذیری را در قرارداد هوشمند Ethereum و اقدامات متقابل آنها مطالعه کردیم و نه ابزار تجزیه و تحلیل امنیتی را بررسی کردیم. یافته های ما نشان می دهد که یک مجموعه یکنواخت از تعاریف آسیب پذیری قرارداد هوشمند در کار تحقیقاتی وجود ندارد و اشکالات مربوط به مکانیسم های یکسان گاهی اوقات با نام های مختلف ظاهر می شود. این ناسازگاری شناسایی ، طبقه بندی و تجزیه و تحلیل آسیب پذیری ها را دشوار می کند. ما برخی از رویکردهای محافظت کننده و بهترین روشها را توضیح می دهیم. با این حال ، با افزایش فناوری آسیب پذیری های جدید ممکن است پدیدار شود. با توجه به پشتیبانی ابزار ، SmartCheck ، FaintChecker ، Contractward و SFUZZ ابزارهای انتخابی بهتر از نظر پوشش بیشتر آسیب پذیری ها هستند. با این حال ، ابزارهایی مانند NPChecker ، Madmax ، Osiris و Sereum برخی از دسته های خاص از آسیب پذیری ها را در صورت لزوم هدف قرار می دهند. در حالی که Contractward از دقت و زمان فرایند سریع برخوردار است ، فقط می تواند آسیب پذیری های از پیش تعریف شده را بطور خاص تشخیص دهد. NPChecker زمان پردازش کندتر دارد ، اما ممکن است الگوهای جدیدی برای هر آسیب پذیری پیدا کند.

1. 3سازمان

بقیه این مقاله به شرح زیر است. بخش 2 پیشینه فنی قرارداد هوشمند را برای بحث بعدی معرفی می کند. بخش 3 ادبیات مربوط به این موضوع را مرور می کند و آنچه را که انجام شده است خلاصه می کند. بخش 4 آسیب پذیری های قرارداد هوشمند و دلایل آنها را توصیف می کند. بخش 5 نتایج مقایسه های ما را در مورد ابزارهای تجزیه و تحلیل امنیتی و به روزرسانی در مورد وضعیت ابزارهای امنیتی ارائه می دهد. بخش 6 در مورد محدودیت ها و سؤالات تحقیق بحث می کند. سرانجام ، بخش 7 نتیجه گیری می کند و آثار آینده را پیشنهاد می کند.

2. پس زمینه

برای درک بهتر قراردادهای Ethereum و Smart ، ما حساب های Ethereum ، چرخه زندگی یک قرارداد هوشمند را توضیح می دهیم و به مکانیسم کار آن عمیق تر نگاه می کنیم.

2. 1حساب های اتریوم

عنصر اصلی اتریوم حساب هاست که به آن وضعیت حساب نیز گفته می شود و هر حساب دارای چهار زمینه است: یادداشت ، تعادل ، ذخیره و کد. Nonce یک پیشخوان معامله است ، که برای هر معامله جدیدی که توسط این حساب ارسال می شود ، غیرقانونی توسط یک افزایش می یابد و در ساختار داده های معامله ضمیمه می شود. ترازو مقدار اتر (ارز مورد استفاده در بستر اتریوم) است. ذخیره سازی فضای حافظه برای کد و اجرای آن است. کد جایی است که کد قرارداد هوشمند ذخیره می شود [20].

دو نوع حساب وجود دارد: حساب های خارجی و حساب های قرارداد. تفاوت عمده بین این دو در این است که آیا قسمت کد خالی است یا خیر. حساب های خارجی توسط جفت های کلیدی دولتی و خصوصی (متعلق به دارندگان حساب انسانی) کنترل می شوند در حالی که حساب های قرارداد توسط کد آنها کنترل می شوند [20،21]. هر دو حساب هشدار داده شده و در ساختار داده ای به نام یک درخت اصلاح شده Patricia Tree [21] ذخیره می شوند ، که دارای ریشه های ریشه ای آن در هر بلوک است. حساب های خارجی می تواند عملی را آغاز کند که وضعیت EVM را تغییر دهد ، که به آن معامله گفته می شود. معاملات به کل شبکه پخش می شود. یک معدنچی بعداً معاملات را انتخاب و اجرا می کند و تغییر وضعیت حاصل را به بقیه شبکه پخش می کند. اجرای معاملات رایگان نیست زیرا اجرای معاملات و تغییر دولت همراه که باید به صورت جهانی پذیرفته شود ، به منابع محاسباتی که انرژی زیادی مصرف می کنند نیاز دارد. این گاز برای اجرای معامله و تعامل با قرارداد هوشمند ایجاد شده است. گاز واحدهایی است که مبتکر برای اعدام معاملات باید بپردازد. حد گاز حداکثر گاز بنزینی است که آغازگر مایل به پرداخت آن است. آغازگر همچنین قیمت گاز را تعیین می کند ، که نشان می دهد میزان اتر که آغازگر مایل به پرداخت هر واحد گاز است. معمولاً هرچه قیمت یک کاربر مایل به پرداخت آن باشد ، احتمال بیشتری برای معاملات کاربر برای اجرای توسط معدنچیان انتخاب می شود. قرارداد هوشمند برنامه ای است که در یک حساب قرارداد ساکن است و رفتار حساب قرارداد را کنترل می کند.

2. 2چرخه زندگی قراردادهای هوشمند

نویسندگان در [22] چهار مرحله مختلف قرارداد هوشمند را بیان می کنند: ایجاد ، استقرار ، اجرای و تکمیل.

ایجاد . در مرحله ایجاد خود ، EVM می تواند توسط چندین زبان سطح بالا ، مانند استحکام [4] ، مار [23] یا بامبو [24] هدف قرار گیرد. متداول ترین مورد استفاده استحکام است. این یک زبان مانند جاوا اسکریپت و تورینگ است. EVM نمی تواند کدهای استحکام را به طور مستقیم اجرا کند ، بنابراین آنها به Opcodes (دستورالعمل های سطح پایین استفاده شده توسط EVM) و به دلایل ذخیره سازی به Bytecodes وارد می شوند.

گسترش . پروتکل Ethereum دو نوع معاملات را تشریح می کند: یکی که از تماس های پیام فراخوانی می کند ، و دیگری که منجر به استقرار قرارداد می شود [21]. توسعه دهنده معامله ای را آغاز می کند که حاوی bytecodes (ذخیره شده در زمینه ای به نام init در ساختار معامله) باشد ، و این عمل قطعه دیگری از کدی را باز می گرداند که در محیط اجرا EVM ذخیره می شود و بعداً اجرا می شود.

اجرا . در حالی که در مرحله اجرای ، یک قرارداد هوشمند یک برنامه در حال اجرا است ، مانند یک فرآیند یا موضوع در یک رایانه مستقل. این معاملات (نوع اول) و داده هایی که به عنوان پارامترها به قرارداد منتقل می شوند ، دریافت می کند. سپس ، EVM دستورالعمل ها را یک به یک اجرا می کند تا به پایان برسد یا محدودیت گاز حاصل شود. این روند در زمان استخراج بلوک جدید اتفاق می افتد.

تکمیل . پس از اجرای ، ایالت ها به روز شده و در blockchains به همراه معاملات ذخیره می شوند. این چرخه زندگی قرارداد هوشمند را تکمیل می کند.

2. 3محیط در حال اجرا اتریوم

کدهای بلوک ، EVM و تماس با هوشمند با هم محیط در حال اجرا اتریوم را تشکیل می دهند. فرایند معدن بلوک اساساً معاملات قانونی را به رسمیت می شناسد و تبدیل دولت مربوطه را به یک بلوک جدید جمع می کند. برای دستیابی به این هدف ، ماینر معاملات را انتخاب می کند ، کدهای موجود در قرارداد هوشمند را اجرا می کند ، حالت را تغییر می دهد ، عدم کار (اثبات کار) را محاسبه می کند و بلوک تازه استخراج شده را به blockchain قبلی وصل می کند. حساب های Ethereum در یک ساختار داده به نام یک درخت Merkle Patricia اصلاح شده (اصلاح شده MPT) [21] ذخیره شده و ذخیره می شوند و این ریشه اصلاح شده MPT در هر بلوک ذخیره می شود و ذخیره می شود. برای درک بهتر قرارداد هوشمند ، ما ساختار بلوک اتریوم را توضیح می دهیم ، همانطور که در شکل 1 نشان داده شده است.

مسدود کردن . یک بلوک در Ethereum دارای سه بخش است: هدر ، لیست معاملات و لیست ommers. این هدر حاوی سه گره ریشه MPT اصلاح شده (stateroot ، TransactionRoot و ReceiptsRoot) و سایر اطلاعات در مورد بلوک است. این سه MPT اصلاح شده ، Trie State World ، Transage Trie و رسیدها هستند. در آن تلاش ها ، هر حساب ، وضعیت و معاملات آن ذخیره می شود. یک MPT اصلاح شده دیگر ، محتوای ذخیره سازی حساب وجود دارد ، و گره ریشه آن در حالت Trie State State State ذخیره می شود. این دو لیست زیر معاملات واقعی و OMMERS هستند که در طی مراحل معدن توسط معدنچی انتخاب می شوند. OMMers بلوک هایی هستند که والدین برابر با والدین والدین بلوک فعلی هستند [21].

Trie State World. هر گره برگ این تری یک نقشه برداری بین وضعیت حساب و آدرس آن دارد. بنابراین ، تمام حسابها ، از جمله حساب خارجی و حساب قرارداد در این توری به هم گره خورده اند. هر بلوک فقط یک کشور جهانی دارد.

محتوای ذخیره سازی حساب Trie. همانطور که قبلاً بحث کردیم ، وضعیت حساب چهار زمینه دارد. گره ریشه Trie محتوای ذخیره سازی حساب در فضای ذخیره سازی ذخیره می شود. بنابراین ، این تری به جای اینکه در این بلوک به عنوان بخشی از Trie State World قرار بگیرد ، به طور مستقیم در هدر بلوک ذخیره نمی شود. تمام داده های قرارداد در این تریله ذخیره می شوند.

TRIE TREATIC. این تری جایی است که هش کلیه معاملات موجود در یک بلوک ذخیره می شود. پس از استخراج بلوک ، این لیست و لیست معاملات در بلوک هرگز تغییر نخواهد کرد.

رسیدها Trie. هر رسید حاوی نتایج اجرای معاملات ، مقدار انباشته گاز مورد استفاده ، سیاهههای مربوط و کد وضعیت معامله است. سریال سازی این اطلاعات همراه با کلیدها در TRIE RECIPTS ذخیره می شود.

3. کار مرتبط

در سالهای اخیر ، محققان بیشتری امنیت قراردادهای هوشمند Blockchains و Ethereum را مورد مطالعه قرار داده اند [13،15،16،17،18،19]. با توجه به امنیت blockchains به طور کلی ، سعد و همکاران.[18] و لی و همکاران.[16] حملات به blockchain و اقدامات متقابل آنها را مورد بررسی قرار داد. به همین ترتیب ، ژو و همکاران.[17] آسیب پذیری ها و دفاع های مربوط به blockchain بیت کوین را مورد مطالعه قرار داد.

3. 1آسیب پذیری های قراردادهای هوشمند

لو و همکاران.[13] آسیب پذیری های قراردادهای هوشمند Ethereum را با استفاده از ابزار تأیید رسمی پیشنهادی خود ، به نام Oyente ، بدون توضیح روش های دفاعی بررسی کنید. Dika [11] ابزارهای تحلیل امنیتی را برای قرارداد هوشمند مطالعه می کند و بینشی در مورد اثربخشی ، دقت و قوام آنها ارائه می دهد. با این حال ، مجموعه داده های وی نسبتاً اندک است و بیشتر ابزارهای ارزیابی شده در آن زمان در نسخه بتا بودند. الحربی و موورل [12] یک مطالعه نقشه برداری منظم در مورد قراردادهای هوشمند در مورد مقالات منتشر شده قبل از سال 2018 برای شناسایی و نقشه برداری از زمینه های تحقیق مربوط به قراردادهای هوشمند انجام می دهند و در مورد کدگذاری ، امنیت ، حفظ حریم خصوصی و مشکلات مربوط به برنامه ریزی می کنند. نویسندگان همچنین چند شکاف تحقیقاتی را در تحقیقات قرارداد هوشمند مانند عدم مطالعه در مورد مقیاس پذیری ، عملکرد و مسائل مربوط به استقرار ارائه می دهند. آتزی و همکاران.[25] در مورد آسیب پذیری ها و حملات اساسی در زمینه موضوعات برنامه نویسی مشترک بحث کنید ، و استناد ترین طبقه بندی آسیب پذیری قراردادهای هوشمند Ethereum را در سه لایه ارائه دهید: استحکام ، EVM و blockchain. این طبقه بندی از ساختار در حال اجرا قراردادهای هوشمند Ethereum گرفته شده است و بیشتر آسیب پذیری ها در این سه کلاس قرار می گیرند. طبقه بندی آنها محدود به آسیب پذیری های قراردادهای هوشمند Ethereum است. در این کار ، ما آخرین کارهای پیشرفت و تحقیقاتی را که از سال 2018 منتشر شده است ، مرور می کنیم.

Dingman [26] کدهای قرارداد هوشمند را با چارچوب NIST بررسی می کند و 49 اشکال طبقه بندی شده در 10 کلاس را گزارش می کند. طبقه بندی آنها بر روی کدگذاری اشکالات و شیرجه زدن به سمت فنی برنامه نویسی متمرکز است. گریشچنکو و همکاران.[27] تعریف رسمی از خصوصیات امنیتی قراردادهای هوشمند را ارائه دهید: یکپارچگی ، اتمی ، استقلال و صحت زمان اجرا را فراخوانی کنید. دی آنجلو و سالزر [19] مطالعه 27 ابزار سنجش امنیت-سازگار با قراردادهای هوشمند Ethereum را مطالعه کرده و آنها را به هدف خود و همچنین 18 آسیب پذیری ترسیم کنید. Praithehesan و همکاران.[28] 16 آسیب پذیری قرارداد هوشمند را بررسی کنید ، آنها را بر روی نقص های امنیتی نرم افزار نقشه برداری کنید ، و بحث و طبقه بندی هفت ابزار تجزیه و تحلیل امنیتی را مورد بحث و طبقه بندی کنید. هوانگ و همکاران.[29] آسیب پذیری های مشترک قرارداد هوشمند را مطالعه کرده و ابزارهای مختلفی را که برای کاهش خطرات ناشی از آن آسیب پذیری ها ایجاد شده است ، بررسی کنید. آنها این روشها را به چهار مرحله از چرخه توسعه نرم افزار طبقه بندی کردند: طراحی ، آزمایش ، اجرای و حسابرسی. سید و همکاران.[30] روی اشکالات برنامه در قرارداد هوشمند تمرکز کنید و در مورد هفت نوع آسیب پذیری و 10 ابزار تحلیل امنیتی برای قراردادهای هوشمند بحث کنید. Durieux و همکاران.[31] ارزیابی و مقایسه 9 ابزار تجزیه و تحلیل امنیت با قرارداد هوشمند در یک مجموعه داده بزرگ از قراردادهای هوشمند Ethereum. Tantikul و Ngamsuriyaroj [32] ابزارهای آسیب پذیری آسیب پذیری Ethereum Smart-Contracts را مقایسه کنید. آنها تجزیه و تحلیل همبستگی را در مورد آسیب پذیری های شناسایی شده در دنیای واقعی انجام می دهند. چن و همکاران.[14] یک نظرسنجی کامل در مورد آسیب پذیری ها و دفاع های سیستم اتریوم انجام دهید. آنها 40 آسیب پذیری ، 29 حمله و 51 دفاع را شناسایی می کنند. نویسندگان حملات به آسیب پذیری هایی را که باعث ایجاد آنها شده است نقشه می کشند. با این حال ، آنها چیزهای زیادی در مورد ابزارهای تشخیص پوشش نمی دهند. تانگ و همکاران.[15] ابزارهای شناسایی آسیب پذیری های قرارداد هوشمند Ethereum را در سه دسته بررسی کنید: تجزیه و تحلیل استاتیک ، تجزیه و تحلیل پویا و تجزیه و تحلیل رسمی. آنها 15 آسیب پذیری امنیتی مختلف و ابزارهای تشخیص مرتبط را در نظر می گیرند. آنها پیشنهاد می کنند از روشهای یادگیری ماشین برای تجزیه و تحلیل قراردادهای هوشمند استفاده کنند. آنها فقط 15 آسیب پذیری امنیتی را مورد بحث قرار می دهند و چندین آسیب پذیری مهم دیگر را از دست نمی دهند. Rameder [33] یک ادبیات جامع و بررسی ابزار از مطالعات منتشر شده مربوطه در زمینه آسیب پذیری های قرارداد هوشمند Ethereum ، روش های تشخیص و ابزارهای تجزیه و تحلیل ارائه می دهد. نویسنده همچنین طبقه بندی آسیب پذیری های قرارداد هوشمند و طبقه بندی ابزارهای تجزیه و تحلیل را ارائه می دهد. با این حال،

اقدامات متقابل و مقایسه ابزار با توجه به صحت و کارآیی و همچنین نقشه برداری آسیب پذیری در CWE ها از دست رفته است.

نظرسنجی های قبلی تمام جنبه های آسیب پذیری های امنیتی Smart-Contrount Ethereum ، اقدامات متقابل و پشتیبانی از ابزار را پوشش نمی دهد و ممکن است جزئیات مربوط به ابزارها یا مکانیسم های دفاعی را از دست بدهد. به عنوان مثال ، در حالی که [14،33] یک نظرسنجی گسترده را انجام می دهد ، آنها با توجه به صحت و کارآیی آنها ، ابزارهایی را ارائه نمی دهند ، و همچنین آسیب پذیری های نقشه را در شاخص های CWE ارائه نمی دهند. یک کار بسیار اخیر [34] یک بررسی منظم از آسیب پذیری ها در قراردادهای هوشمند Ethereum را انجام می دهد ، که با مطالعه ما همپوشانی اساسی دارد. در حالی که نویسندگان همان موضوع را به عنوان ما مطالعه می کنند و آسیب پذیری های بیشتری را پوشش می دهند ، آنها مقایسه ابزارها با توجه به صحت و کارآیی آنها را در نظر نمی گیرند.

در جدول 1 مقایسه ای بین مطالعه ما و بررسی های موجود در مورد آسیب پذیری های قرارداد هوشمند ارائه شده است. در این کار ، ما هدف ما تکمیل مطالعات فوق با در نظر گرفتن ادبیات اخیر و مقایسه صحت و کارآیی برخی از ابزارهای موجود است.

3. 2ابزارها و روشهای تحلیل امنیتی

به تازگی ، غالب و پتابیرامان [35] ابزاری خودکار به نام SolidiFi را برای ارزیابی چندین ابزار تجزیه و تحلیل استاتیک ، از جمله Oyente [13] ، Securify [36] ، Mythril [37] ، Smartcheck [38] ، Manticore [39] و Slither [40] پیشنهاد می کنند.]. SolidiFi هفت نوع اشکالات را به قراردادهای هوشمند تزریق می کند ، سپس از ابزارهای تحلیل امنیتی برای تشخیص این اشکالات استفاده می شود. نتیجه نشان دهنده اثربخشی آن ابزارهای امنیتی است. اشکالات متمرکز عبارتند از وابستگی Timestamp ، استثنائات نامشخص ، سرریز عدد صحیح/Underflow ، tx. origin ، ورود مجدد ، ارسال بدون بررسی و وابستگی به سفارش معامله. SolidiFI می تواند سایر ابزارهای تجزیه و تحلیل استاتیک را ارزیابی کند ، با این حال ، ارزیابی برای تجزیه و تحلیل پویا و ابزارهای تأیید رسمی را نشان نمی دهد.

به دنبال رویکرد نظرسنجی Praitheheshan و همکاران.[28] ، ما روشهای تجزیه و تحلیل امنیت با قرارداد هوشمند را در سه دسته از تأیید استاتیک ، پویا و رسمی برای ابزارهای تجزیه و تحلیل امنیتی تازه پیشنهادی مطالعه می کنیم.

3. 2. 1. تجزیه و تحلیل استاتیک

گرچ و همکاران.[41] از تجزیه و تحلیل استاتیک برای تشخیص آسیب پذیری های مرتبط با گاز استفاده کنید. آنها با استفاده از Vandal [42] با استفاده از Vandal [42] با استفاده از Vandal [42] تجزیه و تحلیل می کنند تا الگوهای مانند حلقه ها ، متغیرهای القایی و جریان داده را تشخیص دهند. چن و همکاران.[43] یک ابزار مبتنی بر اجرای نمادین برای تشخیص هشت نقص قرارداد ارائه می دهد. این دستگاه های بایت های قرارداد هوشمند را در Opcodes جدا می کند و ضمن نظارت بر الگوهای مانند تماس با پول ، حلقه یا عملکرد قابل پرداخت ، به طور نمادین دستورالعمل ها را اجرا می کند. وانگ و همکاران.[44] یادگیری ماشین را برای تشخیص شش آسیب پذیری اعمال می کند: سرریز عدد صحیح/جریان ، وابستگی به سفارش معامله ، محدودیت پشته ، وابستگی به زمان و ورود مجدد. تورس و همکاران. ابزاری به نام OSIRIS ایجاد کنید که تجزیه و تحلیل نمادین و تجزیه و تحلیل رنگ آمیزی را برای شناسایی اشکالات متمرکز با عدد صحیح [45] ایجاد می کند. وانگ و همکاران.[46] با تجزیه و تحلیل Bytecodes EVM و بررسی متغیرهای جهانی و محلی پرچم دار ، بر تشخیص اشکالات غیر قطعی در قراردادهای هوشمند تمرکز کنید. Tikhomirov و همکاران. ابزاری به نام SmartCheck را برای تشخیص آسیب پذیری ها در قراردادهای هوشمند Ethereum [38] اجرا کنید ، که یک درخت تجزیه XML را به عنوان یک بازنمایی میانی (IR) ایجاد می کند و از پرس و جوهای XPath در IR برای ردیابی الگوهای آسیب پذیری استفاده می کند. وانگ و همکاران.[47] ابزاری به نام Artemis را بر اساس چارچوب Oyente [13] بسازید و آن را برای تشخیص آسیب پذیری هایی مانند اتر از دست رفته در انتقال و تماس تفویض شده گسترش دهید. ژانگ و همکاران. MPRO [48] موجود ، که مبتنی بر Slither [40] و Mythril [37] است ، که اجرای نمادین را بهینه می کند.

3. 2. 2. تجزیه و تحلیل پویا

جیانگ و همکاران. مشخصات ABI توابع قراردادهای هوشمند را تجزیه و تحلیل کرده و ورودی های فازی را تولید کنید [49]. اشرف و همکاران.[50] یک فازر به نام Gasfuzzer را بر اساس ContractFuzzer [49] بسازید ، که بر مصرف گاز اعدام ها و آسیب پذیری های ناشی از گاز متمرکز است. او و همکاران.[51] اجرای نمادین قراردادهای دنیای واقعی را برای تولید هزاران دنباله معاملات به عنوان فازر ILF خود اجرا کنید. نگوین و همکاران.[52] برای تشخیص آسیب پذیری های با قراردادهای هوشمند ، که بسیاری از معاملات را ایجاد می کند که توابع را در قرارداد فراخوانی می کنند ، بر اجرای معاملات نظارت می کند و بازخورد را از اجرای آن جمع می کند. رودلر و همکاران. EVM ها را با اجرای یک مشتری جدید Ethereum بر اساس مشتری گسترده اتخاذ شده گسترش دهید: Go-Ethereum [53]. آنها یک موتور لکه دار و آشکارساز حمله می کنند تا بتوانند وضعیت زمان اجرای EVM را برای آسیب پذیری مجدد وارد و تشخیص دهند [54]. محیط های شبیه ساز [55] همچنین می توانند برای اجرای پویا آشکارسازهای آسیب پذیری قرارداد هوشمند بر اساس الگوهای شناخته شده یا استفاده از منابع مورد استفاده قرار گیرند.

3. 2. 3. تأیید رسمی

موری و آنسی نظرسنجی را در مورد روشهای تأیید رسمی در قراردادهای هوشمند انجام می دهند [56]. تحقیقات آنها نشان می دهد که انواع بررسی مدل یا روشهای ارائه دهنده قضیه در قراردادهای ساده موفق هستند ، نه قراردادهای پیچیده یا نحو قرارداد پیشرفته. گارفاتا و همکاران.[57] تعدادی از ابزارها از جمله fsolidm [58] ، verisolid [59] ، Zeus [60] ، Oyente [13] و Osiris [45] را مقایسه و بحث کنید و نشان دهید که تعداد محدودی از آسیب پذیری ها ، مانند اشکالات حسابی، TSD ، TOD ، ورود مجدد و خود تخریب ، با استفاده از روشهای تأیید رسمی توسط ابزارهایی پوشانده می شوند.

4- آسیب پذیری ها و اقدامات متقابل Smart-Contracts

به طور معمول ، فن آوری blockchain و کاربردهای ساخته شده بر روی آن ، به طور معمول از نظر رمزنگاری امن ، غیرقابل تغییر و ناشناس تلقی می شود ، لزوماً ایمن نیستند. مسائل امنیتی ، آسیب پذیری ها و حملات با اتخاذ گسترده تر قراردادهای هوشمند به وجود می آید. حملات دائو [10] و هک کیف پول برابری [61] بدنام ترین حملات است که از آسیب پذیری های قرارداد هوشمند بهره می برد. در این بخش ، ما آسیب پذیری ها را در قراردادهای هوشمند اتریوم که در استحکام نوشته شده اند برای پاسخ به RQ1 (آسیب پذیری ها) و RQ2 (اقدامات متقابل برای کاهش) مطالعه می کنیم. ما ابتدا طبقه بندی آسیب پذیری های قرارداد هوشمند را در بخش 4. 1 ارائه می دهیم و سپس هر آسیب پذیری و اقدامات متقابل آن را در بخش 4. 2 توضیح می دهیم.

4. 1طبقه بندی پیشنهادی

ما طبقه بندی ساختار سه لایه [25] را تطبیق می دهیم و طبقه بندی به روز شده امنیت قرارداد هوشمند را در جدول 2 با طبقه بندی آسیب پذیری هایی که در [25] تحت پوشش قرار نمی گیرند و برخی از مواردی را که از قبیل محدودیت اندازه پشته استفاده شده اند ، ارائه می دهیم. رجیستری طبقه بندی ضعف قرارداد هوشمند [62] ضعف های قرارداد هوشمند را جمع می کند و آنها را به شمارش ضعف رایج (CWE) می رساند [63]. ما همچنین شناسه های شناخته شده CWE را به آسیب پذیری های قرارداد هوشمند مشخص شده در جدول 2 اضافه می کنیم تا به همبستگی طبقه بندی خود با طبقه بندی های خارجی کمک کنیم. توجه داشته باشید که برای آسیب پذیری ها "ارجاع قرارداد خارجی" ، "مسائل مربوط به آدرس کوتاه/پارامتر" و "انجماد اتر" ، شاخص CWE در وب سایت رجیستری گنجانده نشده است ، و ما با مرور وب سایت CWE آن را نقشه برداری کردیم.

4. 2آسیب پذیری و اقدامات متقابل

4. 2. 1. بازپرداخت

مجدداً وضعیتی را توصیف می کند که یک قرارداد با قرارداد B تماس می گیرد ، که می تواند با یک عقب تماس بگیرد و دوباره تماس A را اجرا کند. مکانیسم بازگشت استحکام باعث این وضعیت می شود. عملکرد f a l l b a c k هنگامی که تماس های سایر قراردادها نتوانند عملکرد تطبیق پیدا کنند ، اجرا می شود. هنگامی که تماس گیرنده از عملکرد C a l l بدون ارائه امضای عملکرد استفاده می کند ، عملکرد C Callee f a l l b a c k فعال می شود. این عملکرد می تواند عملکرد تماس گیرنده را برای ورود مجدد به تماس گیرنده فراخواند. این مکانیسم می تواند انتقال غیر منتظره و کنترل نشده اتر را در برخی شرایط مجبور کند.Aدر بخش زیر گزیده ای که در لیست 1 نشان داده شده است (اصلاح شده بر اساس [73]) ، از c a l l برای ارسال اتر به تماس گیرنده استفاده می شود. در ابتدا ، مهاجم عملکرد W I T H D R A W () را در قرارداد صدا می کندAبرای درخواست یک خروج یک اتر. قراردادAاز c a l l برای ارسال اتر استفاده می کند و هیچ امضای عملکردی را ضمیمه نمی کند. عملکرد F A L L B A C K Attracking با تماس با این تماس به این تماس پاسخ می دهدAعملکرد عقب نشینی دوبارهتماس دوم به عنوان یک تماس "تو در تو" در تماس قبلی عقب نشینی در نظر گرفته می شود زیرا شماره قبلی هنوز تمام نشده است. این زمانی است که یک تماس بازگشتی شروع به شکل گیری می کند. به طور معمول ، تماس گیرنده یک اتر دریافت می کند ، و تعادل تماس گیرنده به عنوان اجرای دستورالعمل b a l a n c e s [m s g. s e n d e r] - = _ a m o u n t ؛بشربا این حال ، در یک وضعیت ورود مجدد ، این دستورالعمل هرگز اجرا نمی شود زیرا عملکرد تماس بالای این خط منجر به فراخوانی مجدد عملکرد w i t h d r a w () تا زمان تعادل کل قرارداد خواهد شد.