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

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

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

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

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

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

מה נותנת בדיקת קוד החוזים לפני ואחרי ההשקה

נעלמות מחלקות פגיעות עם ההשלכות היקרות ביותר

הניתוח נעשה לפי מרשם מחלקות הכשל הידוע SWC Registry, ולא לפי רשימת בדיקה כללית: כניסה חוזרת, הצפה בחישובים, קריאות חיצוניות בלתי מבוקרות, טעויות בחלוקת נתחים. בחוזה בדרגת מורכבות בינונית מדובר ב־3–7 ממצאים בדרגת "קריטי" ו"גבוה", שהוסרו לפני העלאה לרשת. לכל אחד — בדיקה ניתנת לשחזור, שנכשלה לפני התיקון ועוברת אחריו: את התוצאה אפשר לאמת באופן עצמאי.

בקרת גישה של הבעלים מפסיקה להיות מבוססת אמון

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

עצירת חירום מקצרת את זמן התגובה לאירוע

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

חלון הפגיעות מצטמצם

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

דרכי בדיקת החוזה ומתי כל אחת מתאימה

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

השוואת מצבי הבדיקה

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

איך מתנהלת העבודה: מניתוח הקוד ועד מסירת הדוח

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

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

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

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

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

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

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

מערכת מסמכים ותיקונים בעקבות הבדיקה

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

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

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

מקרה בוחן: ממצאים לפני ההשקה ומה השתנה אחרי התיקונים

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

מה נמצא לפני הפריסה

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

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

מדדים לפני ואחרי

• ממצאים קריטיים: 3 מתוך 3 נסגרו לפני הפריסה, גבוהים — 7 מתוך 7.
• כשלים של קריאות ניהוליות לפי הרשאות גישה: 11% → 0.
• זמן תגובה לשינוי הרשאות: 6-8 שעות של תיאומים ידניים → כ־20 דקות לפי הנוהל.
• כיסוי בדיקות של מסלולי הרשאות גישה: 24% → 91%.

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

במה שונה ביקורת חוזים חכמים מבדיקת תשתית

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

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

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

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

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

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

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

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

מה לעשות אם החוזה כבר פרוס ותיקונים בלתי אפשריים?

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

מי אחראי לפגיעות אחרי מסירת הדוח?

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

נדון במשימה: מה לשלוח להערכה ולתכנית עבודה

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

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

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