אבטחת חוזים חכמה: גישת SDLC זריזה 

זמן קריאה: 10 דקות

Blockchain מצוטט כפנקס חשבונות מבוזר ועמיד בפני חבלה. אבל ספר חשבונות זה חסין חבלה פגיע לפריצות וניצולים. הביזור, שהוא אחד היתרונות החזקים של בלוקצ'יין, הוא אחד החסרונות. 

ובכן, זה בסדר, אבל מה עם SDLC? 

גישת מחזור חיי התוכנה שאנו עומדים לדון בה מבוססת על סיווג פרצות אבטחה בחוזים חכמים למספר שלבים. 

בחלק הראשון, פירטנו את נושאי האבטחה בחוזים החכמים. ובחלק הבא, נדון בפתרונותיו המחולקים לארבעה שלבים; עיצוב אבטחה, הטמעת אבטחה, בדיקה לפני פריסה, והאחרון, ניטור וניתוח. 

ניתוח של בעיות אבטחה בחוזים חכמים 

חוזים חכמים פגיעים לפריצות וניצולים שונים. חוזים אלה שהם שם נרדף להסכמים משפטיים בעולם האמיתי פועלים באופן עצמאי בהתבסס על תנאי הבלוקצ'יין המקומיים. 

אבל האם חשבת שאפילו אותם בלוקצ'יין מקוריים יכולים להיות אחראים גם לאיומי אבטחה פוטנציאליים בחוזים חכמים? להלן, אנו מציגים כמה מהמאפיינים של בלוקצ'יין עבור אותו הדבר:

ביזור: זה נחשב לאחד היתרונות של פרוטוקולים מבוססי בלוקצ'יין. אבל התוקפים המציאו דרך להפוך את התכונה החיובית הזו לשלילה. 

שחקנים זדוניים יכולים ליצור זהות בדויה כדי לפתח ולפרוס חוזה חכם. לפעמים, קשה לזהות חוזה פגיע מכיוון שרק כתובת הציבור (או) המפתחות הציבוריים זמינים בבלוקצ'יין ציבוריים. 

קוד קוד פתוח: זה עשוי להפתיע אותך, אבל כן, באופן כללי, רוב קודי החוזים החכמים הם מעט קוד פתוח. 

נניח, במקרה של Ethereum Virtual Machine (EVM), קוד הביטים שלה הוא תמיד ציבורי. וכמה מפרקי Solidity יכולים לעזור לך לקבל כתובת חוזה חכמה וקוד Solidity. חשיפת קוד המקור הופכת את התכונה הזו ליתרון עבור תוקפים. 

פלטפורמות בלוקצ'יין לא מפותחות: עבור מפתח, זוהי דרישה עיקרית להכיר את פלטפורמת הפיתוח. יש הרבה פלטפורמות בלוקצ'יין לא מפותחות או חדשות, כך שמפתחים לא יכולים לפתח ידע מעמיק בפעולות בבלוקצ'יין. 

חוסר עקביות זה משפיע על החוזים החכמים עקב חוסר סנכרון. הפגמים בפלטפורמת הבלוקצ'יין נותרו ללא תשומת לב בשל ההתפתחות המתמשכת שלה. 

עסקאות לא ידועות: בנקודה הראשונה, דנו בזהות אנונימית; באופן דומה, העסקאות ב- blockchains אינן נחשפות. אי אפשר להתחקות אחר העסקאות, מה שמוביל לפעילויות בלתי חוקיות רבות. מכיוון שעסקאות פיננסיות מעורבות, כל בעיית אבטחה עלולה לגרום להפסד כספי עצום. 

פתרונות אבטחת חוזה חכמים

כעת, בהמשך לאבטחת החוזה החכם, אנו יכולים להשוות את כל השלבים הדרושים כדי להבטיח חוזה חכם עם האבולוציה שלו. כמו בפיתוח תוכנה מסורתי, אנו נוטים לעקוב אחר מחזור חיים של פיתוח; באופן דומה, אנו יכולים לסווג את מחזור החיים של פיתוח החוזה. 

ניתן לחלק את מחזור החיים של פיתוח החוזה החכם לארבעה שלבים: עיצוב אבטחה, הטמעת אבטחה, בדיקות לפני פריסה וניטור וניתוח.

1. עיצוב אבטחה 

שלב ראשון זה כולל שלושה נושאים; עיקרון עיצוב, דפוס עיצוב ומידול אבטחה (כפי שמוצג באיור לעיל). ההתמקדות העיקרית של נושאים אלה היא על עיצוב חוזה וכיצד ניתן למנוע איומי אבטחה. 

עיקרון עיצוב

עקרונות עיצוב הם רעיונות בסיסיים לעיצוב חוזים חכמים מאובטחים בבלוקצ'יין. ישנם חמישה עקרונות עיצוב חיוניים לחוזים: היכונו לכישלון, השקה בזהירות, שמור על חוזים פשוטים, הישאר מעודכן וחובה לדעת על מאפייני בלוקצ'יין. 

כעת, אתם עשויים לחשוב, כיצד הם יעזרו ליצור חוזה חכם מאובטח? 

בואו ניקח כל אחד מהעקרונות מלמעלה, נניח, "התכונן לכישלון" זה מסמל שבהיעדר תוכניות תיקון, החוזה אמור להיות מסוגל להגיב לבאגים. ואם מתרחשת התקפה כלשהי, החוזה אמור להיות מסוגל להשהות כדי למנוע כל אובדן נוסף. 

דפוס עיצוב

בעיצוב תוכנה, דפוסי העיצוב הם הפתרונות שניתן לעשות בהם שימוש חוזר כדי לפתור בעיה. 

אם ניקח דוגמה של Ethereum, ישנם שישה דפוסי אבטחה; בדיקת אפקטים-אינטראקציה, עצירת חירום, Mutex, ספיגה מהירות, מגבלת קצב ומגבלת איזון.  

אנו יכולים להשתמש בדפוסי אבטחה אלה כדי לטפל בבעיות אבטחה בבלוקצ'יין, כמו פגיעות הכניסה מחדש יכולה להיות מטופלת על ידי דפוס Mutex. 

יחד עם זאת, דפוס עצירת החירום יכול לעזור לנו לסיים את ביצוע החוזה אם הוא מושפע מפגיעות. 

מודל אבטחה

יתכן שיש הבדל בין הקוד שפותח לקוד הנדרש עבור חוזים מכיוון שסולידיטי משמש ליצירת חוזים; השפה הזו מספקת את השלמות של טיורינג, אבל היא נוטה לשגיאות. 

האיור שלמעלה מראה כי תת-שלב זה מכסה שני שלבים; עיצוב ויישום אבטחה. 

דוגמנות אבטחה קשורה ישירות להיגיון העסקי; מכיוון שמפרטים נגזרים מהעסק, ניתן לסווג את ההיגיון על ידי סמנטיקה נטולת שגיאות. זה עוזר מאוחר יותר במהלך תהליך האימות הפורמלי שבוצע כדי לצמצם נקודות תורפה. 

2. יישום אבטחה

בחלק זה נסקור שניים מתוך שלושת הנושאים; בִּטָחוֹן

פיתוח ותבנית אבטחה, כפי שכבר סקרנו את מודל האבטחה בשלב האחרון.

פיתוח אבטחה

חלק זה יראה כיצד ניתן למנוע פגיעויות במהלך תהליך יישום החוזה. 

בפלטפורמת Ethereum, יש לנו EIPs (הצעות לשיפור Ethereum) - המלצות למאבק בבעיות האבטחה ב- Ethereum פּלַטפוֹרמָה. לפיכך, EIPs אלה ראויים לציון ליישום מאובטח של חוזים חכמים. 

תבנית אבטחה

תבניות משמשות כמקור למסמכים חדשים. תבניות החוזה החכמות עם פרמטרים תפעוליים מחברות הסכם משפטי לקוד בר הפעלה. 

בהקשר לאבטחת חוזים חכמה, ניתן לחלץ את תבניות החוזה הסטנדרטיות עם פרמטרי אבטחה משודרגים, כגון דפוסי אבטחה וספריות אבטחה. זה יקטין את האפשרות לשגיאות בקידוד ידני. 

3. בדיקה לפני פריסה

שוב, הדרישה לשלב זה נובעת מאחד היתרונות של חוזים חכמים - "בלתי משתנה". 

ברגע שהחוזים החכמים נוצרים, אין דרך לשנות אותם. לכן, חובה לבצע מספיק בדיקות כדי להבטיח את אבטחת החוזים החכמים לפני הפריסה.

שלב זה מכסה שלושה פרמטרים אבטחה שיש לעקוב אחריהם לפני פריסת חוזה חכם; אימות רשמי קפדני, כלי ניתוח קוד וביקורת אבטחה. 

אימות פורמלי קפדני

אימות פורמלי הוא תהליך מוגדר היטב הממנף חשיבה מתמטית והוכחות מתמטיות כדי לאמת את המאפיינים הרצויים של המערכת. 

אנו יכולים לבצע אימות פורמלי בחוזים חכמים מכיוון שתוכנית החוזים היא קצרה ומוגבלת בזמן. ישנן מספר דרכים לפורמל ולאמת חוזים חכמים בצורה נוקשה; חלקם מבוססים על קוד חוזה, ואחרים על הסמנטיקה של המכונה הוירטואלית Ethereum (EVM). 

כלי ניתוח קוד

ניתוח הקוד נעשה ללא הפעלת התוכניות. לשם כך, אנו משתמשים בכמה כלים הנקראים כלי אבטחת יישומים סטטיים (SAST). כלים אלו מסייעים בגילוי פגמי אבטחה בקוד המקור. 

הניתוח המבוצע על ידי כלים אלה עשוי לכלול אחד או את כל השלבים הבאים:

(I) צור ייצוג ביניים (IR), כגון עץ תחביר מופשט (AST), לניתוח מפורט. 

(Ii) השלים את ה-IR עם מידע מספיק שהתקבל מבקרה סטטית או ניתוח זרימת תאריכים וטכניקות אימות פורמליות; טכניקות אלו כוללות: ביצוע סימבולי, פרשנות מופשטת ובדיקת מודלים סימבוליים. 

אבל מהם הכלים שניתן להשתמש בהם כדי לבצע ניתוח קוד בחוזה חכם? 

למרות שיש הרבה כלים שאפשר להשתמש בהם כדי לבצע את ניתוח האבטחה, Oyente הוא הפופולרי ביותר. 

אוינטה יכול לשמש לביצוע ניתוח אבטחה עבור החוזים החכמים של EVM. הוא משתמש ב"ביצוע סימבולי" כדי לגלות ארבעה באגים נפוצים; תלות בהזמנת עסקאות, תלות בחותמת זמן, חריגים שלא טופלו וכניסה חוזרת. 

הארכיטקטורה של Oyente מראה שהיא לוקחת קוד בתים ומציגה את המצב הגלובלי של Ethereum כקלט. 

אחד הצדדים האחוריים של Oyente הוא שהוא מזהה רק פרצות אבטחה. טכניקת הביצוע הסמלית בה משתמש אוינטה אינה חוקרת את כל הדרכים האפשריות. לפיכך, מתעורר הצורך בכלים אחרים כגון אבטחה וביקורות ידניות. 

ביקורת אבטחה

נתחיל את הקטע הזה איפה שהשארנו את האחרון; הביקורות הידניות. 

אבל ראשית, בואו נבין את הצורך בביקורת אבטחה; בין אם זו הפריצה לרשת רונין או הפריצה לרשת פולי, קוד לא מבוקר הוא הפגיע ביותר לפריצות וניצול. 

הם מובילים להפסדים כספיים עצומים. לא רק ביצוע ביקורת של פרויקט Web3 שלך, למען האמת, אלא גם קבלת ביקורת על ידי אנשי מקצוע מומחים חשובה שכן היא תלויה ביכולת המקצועית של המבקרים לבצע ביקורות אבטחה. 

שוב, היכן למצוא את אותם מומחים מקצועיים? אתה לא צריך ללכת לשום מקום לחפש רואי חשבון מהימנים; נְקִישָׁה https://t.me/quillhash ליצור קשר עם אחד מהם! 

ביקורת חוזה חכמה אידיאלית היא שילוב של ניתוח קוד ידני ואוטומטי; כפי שדיברנו בנקודה הקודמת, למרות שאחרי ניתוח קוד אוטומטי מכלים כגון Oyente, ישנה אפשרות של פגיעויות לא מזוהות בחוזה. 

לפיכך, כדי להתגבר על זה, מבקרי אבטחה יכולים לנתח ידנית כל שורת קוד ולבדוק אותם מול נקודות תורפה אפשריות. 

4. ניטור וניתוח

זוכרים את העיקרון ההולך ומתפתח של בלוקצ'יין עליו דנו בתחילה? 

שלב זה מבוסס על אותו נושא; לאחר פריסה והרצה של החוזה, כמה פגיעויות שנותרו ללא תשומת לב בשלבים הקודמים עלולות להתרחש עקב מהדורות חדשות ועדכונים תכופים שבהמשך הופכים את החוזים ליעילים פחות. 

אנחנו יכולים לבצע; שפע באגים, ניטור אבטחה וניתוח פוסט-הוק כדי להתגבר על החסמים הללו. 

BUG BOUNTY

מכיוון שאנו שוקלים את בעיות האבטחה שלאחר הפריסה עם חוזים, Bug Bounties יכול להיות מועיל. טכניקת האימות הפורמלית שנידונה בעבר היא טכניקת ניתוח סטטי. Bug Bounty, לעומת זאת, היא טכניקת ניתוח דינמית. 

הרעיון מאחורי Bug bounty הוא פשוט; האקרים מגלים באגים, ובתמורה הם מקבלים תגמולים כספיים מסוימים. נראה כמו מצב של win-win, נכון? אבל זה לא!

המלכוד כאן הוא; שערך הבאגים עשוי להיות גבוה מהשפע בשווקים האפורים, והאפשרות היא שהאקרים עלולים לנצל או למכור את הבאגים כדי לקבל מחיר גבוה. 

לפעמים, בעלי הפרויקט מכחישים את תשלום הפרס אלא אם כן יאושרו הבאגים; האקרים גם מודאגים מחוסר הוודאות של התשלומים לאחר חשיפת באגים. 

כדי להתגבר על כך, הוצעה מסגרת של שפע באגים, הידועה בשם "הידרה". 

הידרה משתמשת בטכנולוגיית ה-Exploit gap בשם N-of-N-version programming (NNVP) כמערכת פרס באגים בבלוקצ'יין. 

ניטור אבטחה

אנחנו יכולים להשתמש בניתוח קוד סטטי כדי לגלות את פרצות האבטחה, אבל שיטה זו משמשת לפני פריסת החוזים החכמים. 

אבל כדי למצוא באגים ופגיעויות פוטנציאליות בזמן אמת, עלינו לנטר ולנתח נתוני עסקאות בבלוקצ'יין. 

ניתן לכנות את הפגיעויות הללו שהתגלו על ידי ניתוח חוזים חכמים. שלושה סוגים של חוזים נמצאים במוקד פגיעות עקבות אלה; 

(I) חוזים חמדנים (חוזים שנשארים בחיים ונועלים את אתר ללא הגבלת זמן).

(Ii) חוזים אובדניים (חוזים המדליפים כספים ברישול למשתמשים שרירותיים) וכן,

(iii) חוזים אובדניים (חוזים שכל משתמש שרירותי יכול להרוג). 

אפילו רעיון של אובייקטים ללא התקשרות אפקטיבית (ECF) הוצע כדי לזהות נקודות תורפה על ידי ניטור אובייקטי ECF. 

בהקשר לכך, הוצג גם אלגוריתם מקוון; זה עזר לגלות נקודות תורפה לא ידועות. באותה הצעה, הוצע לבצע חוזים חכמים ב-Testnet לפני פריסה ב-Mainnet. 

ממשק המשתמש ניטור הוא פלטפורמת ניטור בלוקצ'יין המשתמשת ב-React.js. פלטפורמה זו יכולה לשמש לביצוע עסקאות, בדיקת נכסים ובירור לגבי מצב הבלוקצ'יין. 

איננו יכולים להסתמך על פלטפורמה זו לניטור מאובטח של חוזים חכמים, אך מכיוון שניתן למצוא את רוב נתוני העסקאות הקשורים לחוזים חכמים, אנו יכולים לזהות ניצולים בזמן אמת על ידי מעקב אחר העברת הנכסים. 

ניתוח פוסט הוק

Post Hoc Analysis משתמש בנתוני עסקאות בלוקצ'יין כדי לנתח, לגלות או להתחקות אחר איומים פוטנציאליים על הבלוקצ'יין במונחים של הדיוט. 

אם נדון בניתוח הגרף, הוא תוכנן כגישה לאיסוף כל נתוני העסקאות (זה כלל עסקאות פנימיות מחוזים חכמים). 

בעזרת הנתונים הללו הכינו שלושה גרפים; 

(I) גרף זרימת כסף (MFG)

(Ii) גרף יצירת חוזה (CCG) ו,

(iii) גרף הפעלת חוזה (CIG)

בהתבסס על ניתוח הגרפים שהוזכרו לעיל, הוצעו ממצאים חדשים רבים, כגון פתרונות לבעיות אבטחה בין מספר חוזים המקיימים אינטראקציה זה עם זה. 

סכימת פונזי היא אחת מתכניות ההונאה הקלאסיות שבאמצעותן ניתן לרכוש מספר רב של כספים ולהשפיע על הבלוקצ'יין המקומי. כדי להילחם בהונאה זו, הוצע מנגנון מסווג לאיתור תוכניות פונזי ב-Ethereum. 

מנגנון זה משתמש בכריית נתונים ולמידת מכונה כדי לזהות חוזי פונזי. תהליך זה עובד גם אם קוד המקור של החוזים החכמים אינו זמין. 

טיקאוואי

זהו, כן, זהו בינתיים!

אם היית איתנו עד עכשיו, נודה על כך. בלי למתוח יותר, בהערה לסיום, היינו רק אומרים שהמערכת האקולוגית של חוזים חכמים היא מבוזרת, וקשה לתקן באגים. 

ניסינו לשבור את האבטחה של חוזים חכמים מנקודת המבט של מחזור החיים של התוכנה. 

דנו לראשונה בתכונות המפתח של הבלוקצ'יין האחראיות עליהן בעיות אבטחה בחוזים חכמים. סיווגנו את פתרונות האבטחה עבור החוזים החכמים לארבעה שלבים. אנו מקווים להביא פוסטים נוספים כדי להקדים אותך מול האתגרים במערכת האקולוגית הצומחת של Web3. 

מה אתה חושב על גישת SDLC הזריזה הזו לאבטחת חוזים חכמה? שתף את המחשבות שלך בתגובות למטה!

ההודעה אבטחת חוזים חכמה: גישת SDLC זריזה  הופיע לראשונה ב Blog.quillhash.

• Coinsmart. בורסת הביטקוין והקריפטו הטובה באירופה.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה חופשית.
• CryptoHawk. רדאר אלטקוין. ניסיון חינם.
• מקור: https://blog.quillhash.com/2022/04/22/smart-contract-security-an-agile-sdlc-approach/