AI מגלה סיכון של הוצאה כפולה TOCTOU
תנאי מירוץ בין זמן הבדיקה לזמן השימוש הם סוג של באגים תזמוניים המגשרים על הפער בין נקודת ההחלטה של המערכת לרגע שבו ההחלטה מיושמת. בתהליכי תשלום בבלוקצ'יין, פער כזה יכול להיות ההבדל בין רכישה חוקית אחת לבין הוצאה כפולה. כאשר הקוד קורא את היתרה, ואז מאוחר יותר מיישם רכישה, תוקף שיכול להגיש עסקאות כמעט בו-זמניות או לנצל שינוי סדר יכול לגרום לבדיקה להצליח פעמיים, בעוד שעדכון המצב מתרחש רק פעם אחת. זהו לב ליבו של TOCTOU ההוצאה הכפולה.
איך פועל Penligent
הגישה של Penligent לאיתור בעיות אלה אינה מבוססת על ניחושים. היא מתחילה בדפוסי ניתוח סטטיים המסמנים ביטויים מסוג "בדוק ואז פעל" — שורות קוד שבהן נקראים האיזון או הזכאות, ולאחר מכן כתיבה מעדכנת את מונה הזכאות. מיקומים מסומנים אלה מקבלים הקשר: גרף הקריאות של נתיב הקוד, נקודת הקצה ברשת שמפעילה אותו, וההנחות הסביבתיות שהוא עושה (למשל, "מניח עדכונים חד-שרשתיים" או "מניח אישורי בלוקים לפני השלב הבא"). בהקשר זה, Penligent מפעיל אימות מבוקר: בדיקות לא הרסניות נגד נקודות קצה ביניים, קורלציה עם עקבות עסקאות כאשר הן זמינות, ובדיקות מקבילות ממוקדות המדגמות התנהגות תחת הגשות כמעט סימולטניות.
באופן קונקרטי, זרימה פגיעה עשויה להיראות כך בייצור: היישום בודק יתרה[כתובת_החנות] == 1_000_000 ואז מגדיל את מספר היהלומים של הקונה. תוקף מגיש שתי עסקאות של 1,000,000 DDCoin המגיעות בתוך פרק הזמן שבין הבדיקה לבין שינוי המצב האפקטיבי. מכיוון שהבדיקה מתבצעת לפני ששתיהן מתבצעות, שתי הבדיקות עוברות, והמשתמש מקבל שני יהלומים תוך שהוא מוציא רק יחידה אחת של הנכס. Penligent אוסף ראיות על ידי איסוף עקבות הבקשות/התגובות, מזהי העסקאות, חותמות הזמן של הבלוקים וכל תוצרי המירוץ הניתנים לצפייה, ואז מקשר אותם למיקום הקוד הסטטי שמבצע את הבדיקה.
כיצד לתקן TOCOTOU
תיקון TOCTOU בהקשרים של בלוקצ'יין פירושו בדרך כלל ביצוע בדיקת איזון ושינוי מצב אטומי. במערכות אחוריות מסורתיות, פירוש הדבר הוא עסקאות מסד נתונים עם רמות בידוד גבוהות ומנעולים או תוכניות ריבוי משימות אופטימיות עם ניסיונות חוזרים. בחוזים חכמים, פירוש הדבר הוא תכנון החוזה כך שמעברי מצב יבוצעו בעסקה אחת, או שימוש במנגנונים כמו nonces ומספרי רצף מפורשים לכל חשבון כדי למנוע פעולות חוזרות או כפולות. הפסיודקוד הבטוח הבא מציג את הדפוס ההגנתי, תוך הדגשת אטומיות ונכונות במקום פגיעות להתקפה:
קוד מדומה הגנתי #: עדכון אטומי בתוך עסקה הניתנת לסידור עם db.transaction(isolation="serializable"): אם balance[shop_address] >= PRICE: balance[shop_address] -= PRICE session["your_diamonds"] += 1 אחרת: raise InsufficientBalanceError()
מבחינה תפעולית, אמצעים נוספים עוזרים: דרישת nonces או מונים מונוטוניים בהגשת עסקאות, שמירה על סדר קפדני של פעולות בשער ה-API, ויישום עקיבות מלאה כך שניתן יהיה לשחזר דפוסים של הגשות מקבילות. הגבלת קצב ועיבוד אצווה יכולים גם הם לצמצם את חלון ההזדמנויות המעשי שבו ניתן לנצל את המקבילות.
מנקודת המבט של הזיהוי, הערך האמיתי של Penligent טמון במיזוג אותות. אינדיקטורים סטטיים לבדם מייצרים תוצאות חיוביות כוזבות רבות; טלמטריה בזמן ריצה לבדה חסרה קשר ישיר לקוד המקור. Penligent קושרת ממצאי קוד סטטיים לראיות ביצוע אמיתיות: אילו נקודות קצה נקראו, אילו מזהי עסקאות נצפו בשרשרת, ואילו רצף אירועים הוביל לסטייה במצב. התוצאה היא חבילת ראיות שניתן לפעול על פיה: מפתחים מקבלים את שורות המקור המדויקות שיש לתקן, מחלקות התפעול מקבלות את עקבות העסקאות כדי לאמת ביטול או הפחתה, וצוותי האבטחה מקבלים תוכנית תיקון מסודרת לפי סדר עדיפויות.
עבור צוותים המאמצים מודל זה, זרימת העבודה הופכת למהירה יותר ואחראית יותר. במקום חודשים של מיון ידני, אתם מקבלים ראיות שניתן לשחזר ודרך תיקון ברורה. התיקון קשור לא פחות להנדסה מאשר לתהליך: בעלי המוצר חייבים לקבל אילוצים אטומיים, התפעול חייב להבטיח בידוד טרנזקציונלי בפריסה, והאבטחה חייבת לאמת את ההקלות באמצעות הפעלות חוזרות ממוקדות.
הצעה לפקודה של Penligent (בשפה טבעית) — לשימוש פנימי
אם ברצונך ש-Penligent יבדוק סיכוני הוצאה כפולה מסוג TOCTOU בשירות נתון, הנחיה תמציתית יכולה להיות:
"סרוק את נקודת הקצה של התשלומים בכתובת https://staging.example.com/create_transaction עבור TOCTOU ותנאי מירוץ כפולות. התמקד בנתיבי קוד שקוראים יתרות או זכויות ואז כותבים מצב. צור דגימות אימות לא הרסניות, קשר בין כל עקבות העסקאות המקבילות, והפק חבילת ראיות עם מיקומי המקור ותיקונים לפי סדר עדיפות.
ההנחיה הזו מורה ל-Penligent לשלב התאמת תבניות סטטיות עם אימות זמן ריצה בטוח וקורלציה של ראיות.
