תמיכה בביקורת חוזים חכמים: סקירת אבטחה וטיוטת ממצאים

רווחים:

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

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

מדוע ביקורת היא קריטית לאבטחה

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

למה זה לא עובר? כי:

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

שכבות של שימוש בבינה מלאכותית בשליטה

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

2. הסבר קוד. הסבר פונקציה מורכבת ל-AI בשפה פשוטה מאפשר למבקר להבין במהירות את ההיגיון; אבל התיאור תמיד מושווה לקוד.

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

4. יצירת השערת נגד. שאל את ה-AI "כיצד ניתן לנצל את הפונקציה הזו לרעה?" לשאול "מזכיר לנו את הפרספקטיבה האגרסיבית.

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

מציאת רמות חומרה

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

רמה

משמעות

דוגמה

קריטי

הפסד/נעילה אפשרי ישירות

משיכת כספים עם כניסה חוזרת

גבוה

השפעה חמורה בתנאים מסוימים

הדפסה לא מורשית (נענע)

בינוני

השפעה מוגבלת או מצב קשה

הפסד קטן עם סטיית אורקל

נמוך

סיכון קל, הפרת נוהגים טובים

שידור אירוע חסר

מידע

אי אבטחה, קריאות

חוסר NatSpec

הנחיה חלשה / הנחיה חזקה

הנחיה חלשה:

האם החוזה הזה בטוח?

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

הנחיה עוצמתית:

תפקידך: עוזר למבקר חוזים חכמים בכיר. סרוק את החוזה הבא לאבטחה. עברו על הקטגוריות הבאות אחת לאחת: כניסה חוזרת, בקרת גישה, פעולות שלמים, אימות קלט, נתונים אורקל/חיצוניים, ריצה קדמית, מגבלת גז. עבור כל ממצא: (1) שורת קוד רלוונטית, (2) גורם לסיכון, (3) חומרה משוערת (קריטי/גבוה/בינוני/נמוך), (4) הצעת פתרון. אלו הן השערות שיש לאשר; אל תיתן פסק דין "בטוח". סמן בבירור את האזורים שאתה לא בטוח בהם "תן למבקר לאשר".

ארבע תבניות הניתנות להעתקה

1) גלישה מבוססת קטגוריות:

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

2) השערת נגד מנקודת מבטו של התוקף:

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

3) טיוטת דוח ממצאים:

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

4) תקן את האימות:

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

שלושה מארזים קטנים (במספרים)

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

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

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

פגיעות לוגיקה עסקית: הנקודה העיוורת של AI

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

רמז: שאל את ה-AI "כיצד ניתן לנצל את התמריצים הכלכליים של פרוטוקול זה?" והשתמש בתרחישים שעולים כנקודת התחלה - אבל זכור שאתה והצוות שלך צריכים לעשות את הניתוח האמיתי.

טעויות נפוצות

• שאל את ה-AI "האם זה בטוח?" שואל ובוטח בכן שלך. אין צורך בשיפוט מוחלט.
• עצירת הסקירה כאשר ה-AI אומר "לא הצלחתי למצוא את זה". היעדרות אינה ראיה.
• האצלת סקירת לוגיקה עסקית ל-AI. זו הנקודה העיוורת הגדולה ביותר שלו.
• אי שימוש בכלים עצמאיים (Slither וכו'). AI לבדו לא מספיק.
• הכנסת הממצא שהומצא על ידי ה-AI לדוח מבלי לאמת אותו. סיכון להזיות.
• מנסה להטיל אחריות בקרה על AI. האחריות היא על המומחה.

לסיכום

• הביקורת היא קריטית לבטיחות; AI מרחיב את היקף המבקר אך אינו מחליף אותו.
• בינה מלאכותית מפספסת את הפגיעות המקורית ואת באג ההיגיון העסקי; אמירת "בטוח" אינה בטחון.
• הממצאים מסווגים לפי רמת החומרה; AI שימושי ביצירת טיוטות.
• השערת-נגד והקרנת קטגוריות משמרות את משמעת ההכללה.
• האישור הסופי והאחריות המקצועית מוטלים תמיד על המבקר המוסמך.

משימת יישום

מצא חוזה לדוגמה שמכיל פגיעות ידועה (למטרות חינוכיות, דוגמאות של "חוזים פגיעים" זמינות בקוד פתוח). החל את ההנחיה "סריקה מבוססת קטגוריות" על ה-AI. שימו לב אם ה-AI: (1) מצא את הפגיעות האמיתית, (2) הוציא ממצאים מפוברקים/שקריים, (3) עשה שיפוט מוחלט כמו "מאבטח". לאחר מכן השווה את זה עם כלי ניתוח סטטי.

רשימת בדיקה

• [ ] שאל את ה-AI "האם זה בטוח?" במקום זאת, עברתי סריקה מבוססת קטגוריות.
• [ ] התייחסתי לכל ממצא כהשערה.
• [ ] עשיתי את סקירת ההיגיון העסקי בעצמי/בצוות.
• [ ] תקפתי אותו בעזרת כלי ניתוח סטטי עצמאי.
• [ ] אישרתי שה-AI אינו מפברק ממצאים.
• [ ] סיווגתי את הממצאים לפי רמת החומרה.
• [ ] קיבלתי כי האישור הסופי נמצא בידי המבקר המוסמך.