[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-4-asasiyat-aman-msg-sender-tahakkum-wusul-iaadat-dukhul":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":7,"meta_description":16,"focus_keyword":17,"og_image":18,"canonical_url":18,"robots_meta":19,"created_at":15,"updated_at":15,"tags":20,"category_name":34,"related_articles":35},"d9000000-0000-0000-0000-000000000104","a0000000-0000-0000-0000-000000000092","Deep EVM #4: أساسيات الأمان — msg.sender والتحكم في الوصول وإعادة الدخول","deep-evm-4-asasiyat-aman-msg-sender-tahakkum-wusul-iaadat-dukhul","كيف ينشئ نموذج تنفيذ EVM ثغرات أمنية وكيفية الوقاية منها: msg.sender مقابل tx.origin، هجمات إعادة الدخول، مخاطر delegatecall، وأنماط التحكم في الوصول.","## نموذج أمان EVM\n\nأمان العقود الذكية يختلف جوهرياً عن أمان البرمجيات التقليدية. في البرمجيات التقليدية، الأخطاء تسبب أعطالاً. في العقود الذكية، الأخطاء تتسبب في خسائر مالية لا رجعة فيها.\n\nثلاث خصائص تجعل أمان EVM فريداً:\n1. **الثبات** — الكود المنشور لا يمكن تصحيحه (إلا عبر أنماط الوكيل)\n2. **الشفافية** — البايتكود مرئي للجميع، مما يعني أن المهاجمين يمكنهم دراسة عقدك\n3. **التنفيذ الذري** — المعاملات إما تنجح بالكامل أو تفشل بالكامل\n\n## msg.sender مقابل tx.origin\n\n- **msg.sender** — عنوان المستدعي المباشر (عقد أو حساب خارجي)\n- **tx.origin** — الحساب الخارجي الذي بدأ المعاملة (دائماً EOA)\n\nلا تستخدم أبداً `tx.origin` للتحقق من الصلاحيات:\n\n```solidity\n\u002F\u002F خطر! عرضة لهجمات التصيد\nfunction withdraw() external {\n    require(tx.origin == owner); \u002F\u002F المهاجم يستدرج المالك لاستدعاء عقد خبيث\n    payable(msg.sender).transfer(address(this).balance);\n}\n\n\u002F\u002F آمن\nfunction withdraw() external {\n    require(msg.sender == owner);\n    payable(msg.sender).transfer(address(this).balance);\n}\n```\n\nسيناريو الهجوم: ينشر المهاجم عقداً يستدعي `withdraw()` على عقدك. إذا تفاعل المالك مع عقد المهاجم (عبر معاملة تبدو بريئة)، فإن `tx.origin` سيكون عنوان المالك، مما يمنح التحقق.\n\n## هجمات إعادة الدخول\n\nإعادة الدخول هي أكثر ثغرات العقود الذكية شهرة. تحدث عندما يستدعي عقدك عقداً خارجياً قبل تحديث حالته الخاصة.\n\n```solidity\n\u002F\u002F عرضة لإعادة الدخول!\nfunction withdraw(uint256 amount) external {\n    require(balances[msg.sender] >= amount);\n    \n    \u002F\u002F 1. إرسال ETH (يستدعي receive() على المستلم)\n    (bool success,) = msg.sender.call{value: amount}(\"\");\n    require(success);\n    \n    \u002F\u002F 2. تحديث الرصيد — متأخر جداً!\n    balances[msg.sender] -= amount;\n}\n```\n\nالمهاجم ينشر عقداً مع:\n```solidity\nreceive() external payable {\n    if (address(victim).balance >= 1 ether) {\n        victim.withdraw(1 ether); \u002F\u002F إعادة الدخول!\n    }\n}\n```\n\n### الحل: نمط الفحوصات-التأثيرات-التفاعلات\n\n```solidity\nfunction withdraw(uint256 amount) external {\n    \u002F\u002F الفحوصات\n    require(balances[msg.sender] >= amount);\n    \n    \u002F\u002F التأثيرات (تحديث الحالة أولاً)\n    balances[msg.sender] -= amount;\n    \n    \u002F\u002F التفاعلات (الاستدعاء الخارجي أخيراً)\n    (bool success,) = msg.sender.call{value: amount}(\"\");\n    require(success);\n}\n```\n\n### حارس إعادة الدخول (ReentrancyGuard)\n\nOpenZeppelin توفر حارس إعادة الدخول كخط دفاع إضافي:\n\n```solidity\nimport \"@openzeppelin\u002Fcontracts\u002Fsecurity\u002FReentrancyGuard.sol\";\n\ncontract Vault is ReentrancyGuard {\n    function withdraw(uint256 amount) external nonReentrant {\n        \u002F\u002F محمي من إعادة الدخول\n    }\n}\n```\n\n## مخاطر DELEGATECALL\n\nDELEGATECALL ينفذ كود عقد آخر في سياق تخزين العقد المستدعي. هذا قوي لكنه خطير:\n\n```solidity\n\u002F\u002F العقد A يستدعي العقد B عبر delegatecall\n\u002F\u002F كود B يُنفَّذ لكنه يقرأ\u002Fيكتب في تخزين A\n(bool success,) = addressB.delegatecall(\n    abi.encodeWithSignature(\"setOwner(address)\", attacker)\n);\n\u002F\u002F إذا كان B يعدل فتحة 0، فهو يعدل فتحة 0 في A!\n```\n\nالقاعدة: لا تستخدم delegatecall أبداً مع عقود غير موثوقة. في أنماط الوكيل، تأكد من أن عقد التنفيذ ليس له سلطة تعديل منطق الوكيل.\n\n## أنماط التحكم في الوصول\n\n### Ownable (مالك واحد)\n```solidity\nmodifier onlyOwner() {\n    require(msg.sender == owner, \"Not owner\");\n    _;\n}\n```\n\n### التحكم القائم على الأدوار\n```solidity\nimport \"@openzeppelin\u002Fcontracts\u002Faccess\u002FAccessControl.sol\";\n\ncontract MyContract is AccessControl {\n    bytes32 public constant ADMIN_ROLE = keccak256(\"ADMIN\");\n    bytes32 public constant OPERATOR_ROLE = keccak256(\"OPERATOR\");\n    \n    function adminAction() external onlyRole(ADMIN_ROLE) {\n        \u002F\u002F فقط المسؤولون\n    }\n}\n```\n\n## التحقق الرسمي\n\nللعقود عالية القيمة، التدقيق البشري ليس كافياً. التحقق الرسمي يثبت رياضياً أن العقد يتصرف وفق مواصفاته:\n\n- **Certora** — لغة مواصفات CVL + محقق آلي\n- **KEVM** — دلالات K لـ EVM، يمكنه إثبات خصائص على مستوى البايتكود\n- **Solidity SMTChecker** — محقق مدمج في المترجم\n\n## الخلاصة\n\nأمان العقود الذكية يتطلب عقلية دفاعية. افترض أن كل استدعاء خارجي معادٍ. حدّث الحالة قبل التفاعلات الخارجية. لا تثق بـ tx.origin. استخدم أنماط التحكم في الوصول المُختبرة. واحصل دائماً على تدقيق احترافي قبل النشر على الشبكة الرئيسية.","\u003Ch2 id=\"evm\">نموذج أمان EVM\u003C\u002Fh2>\n\u003Cp>أمان العقود الذكية يختلف جوهرياً عن أمان البرمجيات التقليدية. في البرمجيات التقليدية، الأخطاء تسبب أعطالاً. في العقود الذكية، الأخطاء تتسبب في خسائر مالية لا رجعة فيها.\u003C\u002Fp>\n\u003Cp>ثلاث خصائص تجعل أمان EVM فريداً:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>الثبات\u003C\u002Fstrong> — الكود المنشور لا يمكن تصحيحه (إلا عبر أنماط الوكيل)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>الشفافية\u003C\u002Fstrong> — البايتكود مرئي للجميع، مما يعني أن المهاجمين يمكنهم دراسة عقدك\u003C\u002Fli>\n\u003Cli>\u003Cstrong>التنفيذ الذري\u003C\u002Fstrong> — المعاملات إما تنجح بالكامل أو تفشل بالكامل\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"msg-sender-tx-origin\">msg.sender مقابل tx.origin\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>msg.sender\u003C\u002Fstrong> — عنوان المستدعي المباشر (عقد أو حساب خارجي)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>tx.origin\u003C\u002Fstrong> — الحساب الخارجي الذي بدأ المعاملة (دائماً EOA)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>لا تستخدم أبداً \u003Ccode>tx.origin\u003C\u002Fcode> للتحقق من الصلاحيات:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F خطر! عرضة لهجمات التصيد\nfunction withdraw() external {\n    require(tx.origin == owner); \u002F\u002F المهاجم يستدرج المالك لاستدعاء عقد خبيث\n    payable(msg.sender).transfer(address(this).balance);\n}\n\n\u002F\u002F آمن\nfunction withdraw() external {\n    require(msg.sender == owner);\n    payable(msg.sender).transfer(address(this).balance);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>سيناريو الهجوم: ينشر المهاجم عقداً يستدعي \u003Ccode>withdraw()\u003C\u002Fcode> على عقدك. إذا تفاعل المالك مع عقد المهاجم (عبر معاملة تبدو بريئة)، فإن \u003Ccode>tx.origin\u003C\u002Fcode> سيكون عنوان المالك، مما يمنح التحقق.\u003C\u002Fp>\n\u003Ch2 id=\"\">هجمات إعادة الدخول\u003C\u002Fh2>\n\u003Cp>إعادة الدخول هي أكثر ثغرات العقود الذكية شهرة. تحدث عندما يستدعي عقدك عقداً خارجياً قبل تحديث حالته الخاصة.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F عرضة لإعادة الدخول!\nfunction withdraw(uint256 amount) external {\n    require(balances[msg.sender] >= amount);\n    \n    \u002F\u002F 1. إرسال ETH (يستدعي receive() على المستلم)\n    (bool success,) = msg.sender.call{value: amount}(\"\");\n    require(success);\n    \n    \u002F\u002F 2. تحديث الرصيد — متأخر جداً!\n    balances[msg.sender] -= amount;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>المهاجم ينشر عقداً مع:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">receive() external payable {\n    if (address(victim).balance >= 1 ether) {\n        victim.withdraw(1 ether); \u002F\u002F إعادة الدخول!\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>الحل: نمط الفحوصات-التأثيرات-التفاعلات\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">function withdraw(uint256 amount) external {\n    \u002F\u002F الفحوصات\n    require(balances[msg.sender] >= amount);\n    \n    \u002F\u002F التأثيرات (تحديث الحالة أولاً)\n    balances[msg.sender] -= amount;\n    \n    \u002F\u002F التفاعلات (الاستدعاء الخارجي أخيراً)\n    (bool success,) = msg.sender.call{value: amount}(\"\");\n    require(success);\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>حارس إعادة الدخول (ReentrancyGuard)\u003C\u002Fh3>\n\u003Cp>OpenZeppelin توفر حارس إعادة الدخول كخط دفاع إضافي:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">import \"@openzeppelin\u002Fcontracts\u002Fsecurity\u002FReentrancyGuard.sol\";\n\ncontract Vault is ReentrancyGuard {\n    function withdraw(uint256 amount) external nonReentrant {\n        \u002F\u002F محمي من إعادة الدخول\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"delegatecall\">مخاطر DELEGATECALL\u003C\u002Fh2>\n\u003Cp>DELEGATECALL ينفذ كود عقد آخر في سياق تخزين العقد المستدعي. هذا قوي لكنه خطير:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-solidity\">\u002F\u002F العقد A يستدعي العقد B عبر delegatecall\n\u002F\u002F كود B يُنفَّذ لكنه يقرأ\u002Fيكتب في تخزين A\n(bool success,) = addressB.delegatecall(\n    abi.encodeWithSignature(\"setOwner(address)\", attacker)\n);\n\u002F\u002F إذا كان B يعدل فتحة 0، فهو يعدل فتحة 0 في A!\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>القاعدة: لا تستخدم delegatecall أبداً مع عقود غير موثوقة. في أنماط الوكيل، تأكد من أن عقد التنفيذ ليس له سلطة تعديل منطق الوكيل.\u003C\u002Fp>\n\u003Ch2 id=\"\">أنماط التحكم في الوصول\u003C\u002Fh2>\n\u003Ch3>Ownable (مالك واحد)\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">modifier onlyOwner() {\n    require(msg.sender == owner, \"Not owner\");\n    _;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>التحكم القائم على الأدوار\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-solidity\">import \"@openzeppelin\u002Fcontracts\u002Faccess\u002FAccessControl.sol\";\n\ncontract MyContract is AccessControl {\n    bytes32 public constant ADMIN_ROLE = keccak256(\"ADMIN\");\n    bytes32 public constant OPERATOR_ROLE = keccak256(\"OPERATOR\");\n    \n    function adminAction() external onlyRole(ADMIN_ROLE) {\n        \u002F\u002F فقط المسؤولون\n    }\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">التحقق الرسمي\u003C\u002Fh2>\n\u003Cp>للعقود عالية القيمة، التدقيق البشري ليس كافياً. التحقق الرسمي يثبت رياضياً أن العقد يتصرف وفق مواصفاته:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Certora\u003C\u002Fstrong> — لغة مواصفات CVL + محقق آلي\u003C\u002Fli>\n\u003Cli>\u003Cstrong>KEVM\u003C\u002Fstrong> — دلالات K لـ EVM، يمكنه إثبات خصائص على مستوى البايتكود\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Solidity SMTChecker\u003C\u002Fstrong> — محقق مدمج في المترجم\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"\">الخلاصة\u003C\u002Fh2>\n\u003Cp>أمان العقود الذكية يتطلب عقلية دفاعية. افترض أن كل استدعاء خارجي معادٍ. حدّث الحالة قبل التفاعلات الخارجية. لا تثق بـ tx.origin. استخدم أنماط التحكم في الوصول المُختبرة. واحصل دائماً على تدقيق احترافي قبل النشر على الشبكة الرئيسية.\u003C\u002Fp>\n","ar","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:32.235972Z","أمان العقود الذكية: msg.sender مقابل tx.origin، هجمات إعادة الدخول، مخاطر delegatecall، وأنماط التحكم في الوصول.","أمان EVM",null,"index, follow",[21,26,30],{"id":22,"name":23,"slug":24,"created_at":25},"c0000000-0000-0000-0000-000000000016","EVM","evm","2026-03-28T10:44:21.513630Z",{"id":27,"name":28,"slug":29,"created_at":25},"c0000000-0000-0000-0000-000000000013","Security","security",{"id":31,"name":32,"slug":33,"created_at":25},"c0000000-0000-0000-0000-000000000014","Solidity","solidity","بلوكتشين",[36,43,49],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":41,"published_at":42},"d0000000-0000-0000-0000-000000000686","لماذا Bali تتحول إلى مركز تكنولوجيا التأثير في جنوب شرق آسيا 2026","limadha-bali-tatahawwal-markaz-tiknulujia-attathir-janub-sharq-asia-2026","تحتل Bali المرتبة 16 بين أنظمة الشركات الناشئة في جنوب شرق آسيا. مع تركيز متزايد لبناة Web3 وشركات AI المستدامة الناشئة وشركات تكنولوجيا السفر البيئي، تنحت الجزيرة مكانتها كعاصمة تكنولوجيا التأثير في المنطقة.","الهندسة","2026-03-28T10:44:50.120618Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":41,"published_at":48},"d0000000-0000-0000-0000-000000000685","فسيفساء حماية البيانات في ASEAN: قائمة امتثال للمطورين","fusayfisa-himayat-albayanat-asean-qaimat-imtithal-lilmutawwirin","تمتلك سبع دول في ASEAN الآن قوانين شاملة لحماية البيانات، لكل منها نماذج موافقة ومتطلبات توطين وهياكل عقوبات مختلفة. إليك قائمة امتثال عملية للمطورين الذين يبنون تطبيقات متعددة البلدان.","2026-03-28T10:44:50.114369Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":41,"published_at":54},"d0000000-0000-0000-0000-000000000684","التحول الرقمي في Indonesia بقيمة 29 مليار دولار: فرص لشركات البرمجيات","attahawwul-arraqami-indonesia-29-milyar-dular-furas-sharikat-albarmajiyat","من المتوقع أن يصل سوق خدمات تكنولوجيا المعلومات في Indonesia إلى 29.03 مليار دولار في 2026، ارتفاعاً من 24.37 مليار دولار في 2025. البنية التحتية السحابية والذكاء الاصطناعي والتجارة الإلكترونية ومراكز البيانات تقود أسرع نمو في جنوب شرق آسيا.","2026-03-28T10:44:50.092728Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":18,"linkedin":18,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]