امنیت قرارداد هوشمند: یک رویکرد چابک SDLC 

وقت خواندن: 10 دقیقه

بلاک چین به عنوان یک دفتر کل غیرمتمرکز و ضد دستکاری ذکر شده است. اما این دفتر کل ضد دستکاری در برابر هک ها و سوء استفاده ها آسیب پذیر است. عدم تمرکز که یکی از قوی ترین مزیت های بلاک چین است، یکی از معایب آن است. 

خوب، خوب است، اما SDLC چطور؟ 

رویکرد چرخه عمر نرم افزار که در مورد آن بحث می کنیم بر اساس طبقه بندی آسیب پذیری های امنیتی در قراردادهای هوشمند به چند فاز است. 

در بخش اول، مسائل امنیتی در قراردادهای هوشمند را بیان کردیم. و در بخش بعدی راه حل های آن را که به چهار مرحله تقسیم می شود، مورد بحث قرار می دهیم. طراحی امنیتی، پیاده سازی امنیت، تست قبل از استقرار، و آخرین مورد، نظارت و تجزیه و تحلیل. 

تجزیه و تحلیل مسائل امنیتی در قراردادهای هوشمند 

قراردادهای هوشمند در برابر هک ها و سوء استفاده های مختلف آسیب پذیر هستند. این قراردادها که مترادف با توافق نامه های حقوقی دنیای واقعی هستند، به طور مستقل بر اساس شرایط بلاک چین های بومی اجرا می شوند. 

اما آیا فکر کرده اید که حتی آن بلاک چین های بومی نیز می توانند مسئول تهدیدات امنیتی احتمالی در قراردادهای هوشمند باشند؟ در زیر، ما برخی از ویژگی های بلاک چین را برای همین موارد ارائه می دهیم:

عدم تمرکز: یکی از مزایای پروتکل های مبتنی بر بلاک چین محسوب می شود. اما مهاجمان راهی برای تبدیل این ویژگی مثبت به ویژگی منفی ابداع کرده اند. 

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

کد منبع باز: این ممکن است شما را شگفت زده کند، اما بله، به طور کلی، اکثر کدهای قرارداد هوشمند تا حدودی منبع باز هستند. 

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

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

این ناهماهنگی بر قراردادهای هوشمند به دلیل عدم هماهنگی تأثیر می گذارد. نقص‌های پلتفرم بلاک چین به دلیل تکامل مداوم آن مورد توجه قرار نمی‌گیرد. 

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

راه حل های امنیتی قراردادهای هوشمند

اکنون، با پیشبرد امنیت قراردادهای هوشمند، می‌توانیم تمام مراحل لازم برای ایمن کردن یک قرارداد هوشمند را با تکامل آن مقایسه کنیم. همانطور که در توسعه نرم افزار سنتی، ما تمایل داریم یک چرخه عمر توسعه را دنبال کنیم. به طور مشابه، ما می توانیم چرخه عمر توسعه قرارداد را طبقه بندی کنیم. 

چرخه عمر توسعه قرارداد هوشمند را می توان به چهار مرحله تقسیم کرد: طراحی امنیتی، پیاده سازی امنیتی، آزمایش قبل از استقرار، و نظارت و تجزیه و تحلیل.

1. طراحی امنیتی 

این مرحله اول شامل سه موضوع است. اصل طراحی، الگوی طراحی و مدل سازی امنیتی (همانطور که در شکل بالا نشان داده شده است). تمرکز اصلی این موضوعات بر طراحی قرارداد و چگونگی جلوگیری از تهدیدات امنیتی است. 

اصل طراحی

اصول طراحی ایده های اساسی برای طراحی قراردادهای هوشمند ایمن در بلاک چین هستند. پنج اصل اساسی طراحی برای قراردادها وجود دارد: آماده شدن برای شکست، عرضه با دقت، ساده نگه داشتن قراردادها، به روز ماندن، و دانستن ویژگی های بلاک چین. 

اکنون، ممکن است فکر کنید، آنها چگونه به ایجاد یک قرارداد هوشمند ایمن کمک خواهند کرد؟ 

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

الگوی طراحی

در طراحی نرم‌افزار، الگوهای طراحی راه‌حل‌هایی هستند که می‌توان از آنها برای حل یک مشکل استفاده مجدد کرد. 

اگر نمونه ای از اتریوم را در نظر بگیریم، شش الگوی امنیتی وجود دارد. بررسی اثرات-تعامل، توقف اضطراری، Mutex، سرعت گیر، محدودیت نرخ، و حد تعادل.  

ما می‌توانیم از این الگوهای امنیتی برای رسیدگی به مسائل امنیتی در بلاک چین استفاده کنیم، مانند آسیب‌پذیری ورود مجدد که با الگوی Mutex قابل کنترل است. 

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

مدل سازی امنیتی

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

شکل بالا نشان می دهد که این فاز فرعی دو فاز را پوشش می دهد. طراحی و پیاده سازی امنیتی 

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

2. پیاده سازی امنیتی

در این بخش به دو موضوع از سه موضوع خواهیم پرداخت. امنیت

توسعه و الگوی امنیتی، همانطور که قبلاً در مرحله آخر به مدل سازی امنیت پرداختیم.

توسعه امنیت

در این بخش نحوه جلوگیری از آسیب‌پذیری‌ها در طول فرآیند اجرای قرارداد مشاهده می‌شود. 

در پلتفرم اتریوم، ما EIP های امنیتی (پیشنهادات بهبود اتریوم) داریم - توصیه هایی برای مبارزه با مسائل امنیتی در Ethereum سکو. بنابراین، این EIP ها برای اجرای ایمن قراردادهای هوشمند قابل توجه هستند. 

الگوی امنیتی

الگوها به عنوان مبدأ اسناد جدید هستند. الگوهای قرارداد هوشمند با پارامترهای عملیاتی یک توافقنامه قانونی را به یک کد اجرایی متصل می کند. 

در زمینه امنیت قرارداد هوشمند، امکان استخراج الگوهای قرارداد استاندارد با پارامترهای امنیتی ارتقا یافته، مانند الگوهای امنیتی و کتابخانه های امنیتی وجود دارد. این امر احتمال خطا در کدنویسی دستی را کاهش می دهد. 

3. تست قبل از استقرار

مجدداً، الزام این مرحله از یکی از مزایای قراردادهای هوشمند - "تغییر ناپذیری" ناشی می شود. 

پس از ایجاد قراردادهای هوشمند، هیچ راهی برای تغییر آنها وجود ندارد. بنابراین، انجام تست های کافی برای اطمینان از امنیت قراردادهای هوشمند قبل از استقرار الزامی است.

این مرحله شامل سه پارامتر امنیتی است که باید قبل از استقرار یک قرارداد هوشمند دنبال شود. تأیید رسمی دقیق، ابزارهای تجزیه و تحلیل کد، و ممیزی امنیتی. 

تأیید رسمی دقیق

تأیید رسمی یک فرآیند کاملاً تعریف شده است که از استدلال ریاضی و اثبات ریاضی برای تأیید ویژگی‌های مورد نظر سیستم استفاده می‌کند. 

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

ابزارهای تجزیه و تحلیل کد

تجزیه و تحلیل کد بدون اجرای برنامه ها انجام می شود. برای این منظور از ابزارهایی به نام ابزارهای Static Application Security Testing (SAST) استفاده می کنیم. این ابزارها به کشف نقص های امنیتی در کد منبع کمک می کنند. 

تجزیه و تحلیل انجام شده توسط این ابزار ممکن است شامل یک یا همه مراحل زیر باشد:

(I) یک نمایش میانی (IR)، مانند درخت نحو انتزاعی (AST)، برای تجزیه و تحلیل دقیق ایجاد کنید. 

(II) IR را با اطلاعات کافی به دست آمده از کنترل استاتیک یا تجزیه و تحلیل جریان تاریخ و تکنیک های تأیید رسمی تکمیل کنید. این تکنیک ها عبارتند از: اجرای نمادین، تفسیر انتزاعی و بررسی مدل نمادین. 

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

اگرچه ابزارهای زیادی وجود دارد که می‌توان از آن برای انجام تحلیل امنیتی استفاده کرد، اما Oyente محبوب‌ترین آنهاست. 

اوینته می تواند برای انجام تجزیه و تحلیل امنیتی برای قراردادهای هوشمند EVM استفاده شود. از "اجرای نمادین" برای کشف چهار اشکال رایج استفاده می کند. وابستگی سفارش تراکنش، وابستگی به مهر زمانی، استثنائات نادرست و ورود مجدد. 

معماری Oyente نشان می دهد که بایت کد می گیرد و حالت جهانی اتریوم را به عنوان ورودی ارائه می دهد. 

یکی از جنبه های دیگر Oyente این است که فقط آسیب پذیری های امنیتی را شناسایی می کند. تکنیک اجرای نمادین مورد استفاده توسط Oyente همه مسیرهای ممکن را بررسی نمی کند. بنابراین، نیاز به ابزارهای دیگری مانند امنیت و ممیزی دستی ایجاد می شود. 

حسابرسی امنیتی

ما این بخش را از جایی شروع می کنیم که آخرین مورد را ترک کردیم. ممیزی های دستی 

اما ابتدا، بیایید نیاز به ممیزی امنیتی را درک کنیم. چه هک Ronin Network یا هک Poly Network باشد، کدهای ممیزی نشده بیشترین آسیب پذیری را در برابر هک ها و سوء استفاده ها دارند. 

آنها منجر به خسارات مالی هنگفتی می شوند. نه تنها ممیزی پروژه Web3 شما، بلکه ممیزی آن توسط متخصصان متخصص نیز مهم است، زیرا این امر به توانایی حرفه ای حسابرسان برای انجام ممیزی های امنیتی بستگی دارد. 

باز هم، کجا می توان آن کارشناسان حرفه ای را پیدا کرد؟ لازم نیست جایی به دنبال حسابرسان قابل اعتماد بروید. کلیک https://t.me/quillhash برای تماس با یکی از آنها! 

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

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

4. نظارت و تجزیه و تحلیل

اصل همیشه در حال تحول بلاک چین را که در ابتدا در مورد آن صحبت کردیم را به خاطر دارید؟ 

این مرحله بر اساس همین موضوع است. پس از استقرار و اجرای قرارداد، برخی از آسیب‌پذیری‌ها که در مراحل قبلی مورد توجه قرار نگرفته بودند، ممکن است به دلیل نسخه‌های جدید و به‌روزرسانی‌های مکرر رخ دهند که بعداً قراردادها را کارآمدتر می‌کنند. 

ما می توانیم انجام دهیم؛ برای غلبه بر این موانع، پاداش اشکال، نظارت بر امنیت، و تجزیه و تحلیل post hoc. 

BUG BOUNTY

همانطور که ما در حال بررسی مسائل امنیتی پس از استقرار در قراردادها هستیم، Bug Bounties می تواند مفید باشد. روش تأیید رسمی که قبلاً مورد بحث قرار گرفت، یک تکنیک تجزیه و تحلیل ایستا است. از طرف دیگر، باگ بونتی یک تکنیک تحلیل پویا است. 

مفهوم باگ Bounty ساده است. هکرها باگ ها را کشف می کنند و در ازای آن، مقداری پاداش مالی به آنها پرداخت می شود. به نظر یک موقعیت برد-برد است، درست است؟ اما اینطور نیست!

شکار اینجاست. که ارزش باگ‌ها ممکن است بالاتر از جایزه در بازارهای خاکستری باشد، و این احتمال وجود دارد که هکرها برای بدست آوردن قیمت بالا از اشکالات سوء استفاده کنند یا بفروشند. 

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

برای غلبه بر این، یک چارچوب پاداش اشکال پیشنهاد شد که به عنوان "Hydra" شناخته می شود. 

Hydra از یک فناوری شکاف بهره برداری به نام برنامه نویسی نسخه N (NNVP) به عنوان یک سیستم پاداش باگ در بلاک چین استفاده می کند. 

مانیتورینگ امنیتی

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

اما برای یافتن باگ‌ها و آسیب‌پذیری‌های احتمالی در زمان واقعی، باید داده‌های تراکنش‌ها را روی بلاک چین نظارت و تجزیه و تحلیل کنیم. 

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

(I) قراردادهای حریص (قراردادهایی که زنده می مانند و اتر را به طور نامحدود قفل می کنند).

(II) قراردادهای اسراف (قراردادهایی که وجوه را با بی دقتی به کاربران خودسر نشت می کند) و

(iii) قراردادهای خودکشی (قراردادهایی که هر کاربر خودسری می تواند آن را بکشد). 

حتی مفهومی از اشیاء به طور موثر بدون پاسخ به تماس (ECF) برای شناسایی آسیب‌پذیری‌ها با نظارت بر اشیاء ECF پیشنهاد شد. 

در زمینه این، یک الگوریتم آنلاین نیز ارائه شد. به کشف آسیب پذیری های ناشناخته کمک کرد. در همین پیشنهاد، پیشنهاد شد قبل از استقرار در Mainnet، قراردادهای هوشمند در Testnet اجرا شود. 

Monitoring UI یک پلت فرم نظارت بر بلاک چین است که از React.js استفاده می کند. از این پلتفرم می توان برای انجام تراکنش ها، بررسی دارایی ها و پرس و جو در مورد وضعیت بلاک چین استفاده کرد. 

ما نمی‌توانیم برای نظارت ایمن بر قراردادهای هوشمند به این پلتفرم اعتماد کنیم، اما از آنجایی که بیشتر داده‌های تراکنش‌های مربوط به قراردادهای هوشمند را می‌توان یافت، می‌توانیم با ردیابی انتقال دارایی‌ها، بهره‌برداری‌ها را در زمان واقعی شناسایی کنیم. 

تجزیه و تحلیل پس از پایان کار

تجزیه و تحلیل Post Hoc از داده های تراکنش بلاک چین برای تجزیه و تحلیل، کشف یا ردیابی تهدیدهای بالقوه در بلاک چین به زبان ساده استفاده می کند. 

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

با کمک این داده ها سه نمودار تهیه کردند. 

(I) نمودار جریان پول (MFG)

(II) نمودار ایجاد قرارداد (CCG) و

(iii) نمودار فراخوان قرارداد (CIG)

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

طرح پونزی یکی از طرح‌های کلاهبرداری کلاسیک است که از طریق آن می‌توان تعداد زیادی سرمایه به دست آورد و روی بلاک چین بومی تأثیر گذاشت. برای مبارزه با این تقلب، مکانیزم طبقه‌بندی کننده برای شناسایی طرح‌های Ponzi در اتریوم پیشنهاد شد. 

این مکانیسم از داده کاوی و یادگیری ماشینی برای شناسایی قراردادهای پونزی استفاده می کند. این فرآیند حتی اگر کد منبع قراردادهای هوشمند در دسترس نباشد، کار می کند. 

غذای اصلی

همین است، بله، فعلا همین است!

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

ما سعی کرده ایم امنیت قراردادهای هوشمند را از منظر چرخه عمر نرم افزار بشکنیم. 

ما ابتدا در مورد ویژگی های کلیدی بلاک چین که مسئول آن هستند بحث کرده ایم مسائل امنیتی در قراردادهای هوشمند. ما راه حل های امنیتی برای قراردادهای هوشمند را به چهار مرحله طبقه بندی کردیم. ما امیدواریم که پست های بیشتری ارائه دهیم تا شما را از چالش های موجود در اکوسیستم رو به رشد Web3 جلوتر نگه داریم. 

نظر شما در مورد این رویکرد چابک SDLC برای امنیت قراردادهای هوشمند چیست؟ نظرات خود را در نظرات زیر به اشتراک بگذارید!

پست امنیت قرارداد هوشمند: یک رویکرد چابک SDLC  به نظر می رسد برای اولین بار در Blog.quillhash.

• Coinsmart. بهترین صرافی بیت کوین و کریپتو اروپا.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی رایگان.
• CryptoHawk. رادار آلت کوین امتحان رایگان.
• منبع: https://blog.quillhash.com/2022/04/22/smart-contract-security-an-agile-sdlc-approach/