הסבר על Reentrancy Attack: כיצד למנוע Reentrancy ב-Solidity

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

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

מהי התקפת ריאנטרנסי וכיצד היא מנצלת חוזים חכמים?

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

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

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

תובנות ממומחי סוקן: “בלמעלה מ-40% מבדיקות האבטחה האחרונות שלנו ב-DeFi, מופיעים דפוסי ריאנטרנסי בצורה כלשהי, לעיתים כווריאציות עדינות הכרוכות בחוזי Proxy או קריאות מרובות שכבות. זיהוי זה מחייב ניתוח מעמיק של קריאות בין חוזים מעבר לבדיקה חד-חוזית.”

דפוסי סולידיטי נפוצים הגורמים לפרצות ריאנטרנסי

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

הדפוס הפגיע ביותר נראה כך:

function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount;
}

כאן, הקריאה החיצונית באמצעות call.value() מתרחשת לפני הפחתת יתרת המשתמש. במהלך הקריאה החיצונית, פונקציית fallback של התוקף יכולה לקרוא לפונקציית withdraw() שוב ושוב, ולרוקן כספים לפני שהיתרות מתעדכנות.

מבנים מסוכנים עיקריים כוללים:

• קריאות חיצוניות לפני עדכון מצב: שליחת ETH או טוקנים לפני עדכון היתרות.
• שימוש ב-call או send ללא אמצעי זהירות: קריאה חיצונית באמצעות פונקציות ברמה נמוכה עוקפת בדיקות ועלולה לקרוא לפונקציות fallback.
• היעדר מנעול ריאנטרנסי: ללא Mutexes או מנגנוני נעילה אחרים.
• שרשראות קריאה מורכבות עם delegatecall: אלו יכולים לפתוח ריאנטרנסי בעקיפין דרך קריאות חיצוניות בתוך חוזים שהוקראו.

לעומת זאת, דפוס בטוח יותר הופך את הסדר:

function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount;  // עדכון מצב תחילה
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
}

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

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

טכניקות מנע סטנדרטיות:

1. דפוס Checks-Effects-Interactions:
   תמיד לעדכן את המצב הפנימי לפני ביצוע קריאות חיצוניות. זה מקטין את מצב החוזה הלא עקבי במהלך הקריאות החיצוניות.

2. מנעולי ריאנטרנסי / Mutexes:
   ReentrancyGuard של OpenZeppelin משתמש במנעול פשוט לחסימת קריאות מקוננות. משלבים כך:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureContract is ReentrancyGuard {
    mapping(address => uint256) balances;

    function withdraw(uint256 amount) public nonReentrant {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success);
    }
}

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

2. אנליזות סטטיות וכלים אוטומטיים:
   כלים כמו Slither ומסגרות הבדיקה של סוקן מסמנים ריאנטרנסי.

3. שימוש בגרסאות וסולריטי עדכניות & תכונות:
   סולידיטי 0.8+ מציעה בדיקות built-in לאוברפלו, אך סיכוני ריאנטרנסי נמשכים, לכן יש לשלב בטיחות קוד עם דפוסי עיצוב.

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

דוגמאות מהעולם האמיתי לניצולי ריאנטרנסי וההשפעה שלהם

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

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

vectors delegatecall ו-flash loan: הגברת סיכוני ריאנטרנסי

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

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

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

תובנת אבטחה: “בניסיון סוקן, המניעה של ריאנטרנסי חורגת מהחוזה הבודד לעיצוב ברמת הפרוטוקול — במיוחד כש delegatecall ו-flash loans מתקיימים יחד. יש לשלב מנעולי ריאנטרנסי עם אימות כניסה ובדיקות ייעודיות ל-flash loans (תקרות הלוואה, הגבלות על קריאות חוזרות).”

טבלת השוואה: טכניקות מנע ריאנטרנסי נפוצות

דוגמת קוד סולידיטי: חוזה פגיע לריאנטרנסי ותיקונו

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

// פגיע: משיכה לפני עדכון יתרה
contract Vulnerable {
    mapping(address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient funds");
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        balances[msg.sender] -= amount; // פגיע: עדכון מצב אחרי קריאה חיצונית
    }
}

תיקון באמצעות ReentrancyGuard של OpenZeppelin ועדכון מצב לפני אינטראקציה:

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract Secure is ReentrancyGuard {
    mapping(address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 amount) external nonReentrant {
        require(balances[msg.sender] >= amount, "Insufficient funds");
        balances[msg.sender] -= amount; // עדכון מצב לפני קריאה חיצונית
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }
}

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

פרצות ריאנטרנסי ממשיכות להיות איום קריטי על חוזים חכמים, במיוחד באקוסיסטמים מורכבים של DeFi המשתמשים ב-flash loans ו-delegatecall. ההגנות היעילות ביותר משלבות משמעת קוד (checks-effects-interactions), מנעולי ריאנטרנסי מפורשים, ביקורות קפדניות ואימות עסקות בהקשר.

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

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

דברו עם מומחה סוקן | צפו בדוחות הביקורת שלנו