تعلم كيفية منع هجمات رفض الخدمة (DOS) في العقود الذكية من خلال ضمان أن تكون قوائم الانتظار آمنة ، والتعامل مع الرموز العشرية المنخفضة ، وإدارة المكالمات الخارجية بشكل آمن.
مرحبًا بك مرة أخرى في سلسلة قرار قائمة المراجعة الفردية . سنستمر في استكشاف قوائم مراجعة تدقيق العقد الذكي SOLODIT ، مع التركيز على الاستراتيجيات العملية لكتابة عقود ذكية آمنة ومرنة.
تساعدك قائمة المراجعة هذه على تحديد نقاط الضعف المحتملة وتنفيذ تدابير أمنية استباقية. في القسم السابق " دقة قائمة المراجعة الفرعية (1) " ، قمنا بفحص ثلاث قوائم مراجعة ( نمط الاستخراج ، والحد الأدنى من مبلغ المعاملة ، والقائمة السوداء ) المتعلقة بهجوم رفض الخدمة (DOS) وقدموا حلولًا للمطورين. إذا لم تكن قد قرأتها بعد ، فإنني أوصي بمراجعة المقالة قبل المتابعة.
في هذه المقالة ، سنناقش ثلاثة عناصر أخرى في قائمة المراجعة ، مع التركيز مرة أخرى على هجمات DOS. سوف نغوص في نقاط الضعف في التعامل مع قائمة الانتظار ، والتحديات التي تشكلها الرموز العشرية المنخفضة ، وأهمية التعامل بأمان مع مكالمات العقد الخارجية .
للحصول على أفضل تجربة ، افتح علامة قائمة مراجعة من Solodit للرجوع إليها.
هذا ما سنناقشه اليوم:
SOL-AM-DOSA-4: منع معالجة قائمة الانتظار : تحدث هذه المشكلة عندما يعالج المهاجم قائمة الانتظار لإيقاف تشغيل أو مقاطعة عملياته ، مما يؤدي إلى DOS. سننظر في كيفية تدمير المهاجمين مع المعالجة.
SOL-AM-DOSA-5: الرموز العشرية المنخفضة : مشاكل تحدث عند التعامل مع الرموز ذات الأماكن العشرية المنخفضة. يمكن اقتطاع الحساب ، وخاصة الانقسام ، إلى الصفر ، مما يؤدي إلى سلوك غير متوقع وضار. يمكن أن تسبب هذه الرموز ذات الدقة المنخفضة مشكلات في تقسيم عدد صحيح ، وبالتالي التدخل في الوظائف الرئيسية.
SOL-AM-DOSA-6: مكالمات خارجية غير آمنة : سنستكشف كيفية الاعتماد على العقود الخارجية دون التعامل مع الأخطاء المناسبة لإنشاء نقاط الضعف. عندما لا يتم التعامل مع فشل المكالمة الخارجية بشكل صحيح ، فقد يتسبب ذلك في تراجع العقد بأكمله.
تثبت هجمات العالم الحقيقي أن هذه الأضرار المحتملة التي يمكن أن تسببها هذه الثغرات الأمنية. عانى المشروع من خسائر كبيرة بسبب الإهمال البسيط على ما يبدو.
تعتمد قوائم مراجعة Solodit على نتائج التدقيق ، وتقارير Bounty للضعف ، والأحداث في العالم الحقيقي. من خلال دراسة قوائم المراجعة هذه ، يمكنك التعلم من الأخطاء السابقة وتحسين أمان الكود الخاص بك .
الآن ، دعونا نلقي نظرة على كل عنصر فحص واحد تلو الآخر من خلال رمز العينة. تم تبسيط هذه الأمثلة لتسليط الضوء على نقاط الضعف الأساسية.
المشكلة : إذا كان عقدك الذكي يعتمد على قائمة انتظار لمعالجة المهام ، فيجوز للمهاجم التعامل مع حالة معينة في قائمة الانتظار لمنع المعالجة الصحيحة.
سؤال قائمة المراجعة : "هل يمكن للمهاجم حظر أو منع معالجة قائمة الانتظار للتسبب في انقطاع الخدمة؟"
الحل : تتطلب آلية معالجة قائمة الانتظار الخاصة بك آليات قوية في التعامل مع الأخطاء وآليات العودة لضمان استمرار معالجة المشكلات حتى لو حدثت.
مثال :
النظر في مثال على استخراج قائمة انتظار:
يطلب المستخدم الاستخراج ، وبعض الأعلام تشير إلى أن الطلب نشط.
يمكن للمهاجم استخدام وظيفة resetUserStatus بعد الاستخراج لمنع نفس التشغيل للمستخدمين الآخرين.
// 易受攻击的函数：可以被利用function resetUserStatus() external { // 任何人在仍然处于队列中的情况下都可以重置他们的状态withdrawalRequested[msg.sender] = false; // 注意：用户没有被移出队列！ } // 处理队列中的下一次提取function processNextWithdrawal() external { require(withdrawalQueue.length > currentIndex, "没有可处理的提取"); // 获取下一次提取Withdrawal memory withdrawal = withdrawalQueue[currentIndex]; // 可被攻击者利用：此检查可能会被重置状态所攻击require(withdrawalRequested[withdrawal.user], "提取请求不再有效"); // 处理提取uint256 amount = withdrawal.amount; require(balances[withdrawal.user] >= amount, "余额不足"); // 更新余额balances[withdrawal.user] -= amount; // 重置提取请求withdrawalRequested[withdrawal.user] = false; // 发送资金(bool success, ) = payable(withdrawal.user).call{value:amount}(""); require(success, "资金发送失败"); // 移动到队列中的下一个currentIndex++; }للاستفادة من هذا ، يمكن للمهاجم القيام بما يلي:
resetUserStatus .processNextWithdrawal ، مما تسبب في هجوم DOS مستمر.العلاجات :
withdrawalRequested للمسؤول.المشكلة : يمكن أن تسبب الرموز ذات الأماكن العشرية المنخفضة مشاكل في تقسيم عدد صحيح ، وبالتالي التقريب إلى الصفر .
تخيل عقدًا مميزًا لتخصيص الرموز المميزة على مدى فترة من الزمن. إذا كانت جولات tokensPerSecond إلى الصفر بسبب انقسام عدد صحيح مع رموز عشرية منخفضة ، سيتم حظر وظيفة التخصيص. سؤال قائمة المراجعة : "هل تؤدي الرموز العشرية المنخفضة إلى DOS؟" الحل : تنفيذ المنطق للتعامل مع النقاط العشرية المنخفضة لمنع انقطاع عمليات التداول بسبب أخطاء التقريب. مثال :
فكر في عقد TokenStream الذي يقوم بانتظام بتشغيل عدد معين من الرموز المميزة للمستخدمين ، حيث:
total_tokens إلى العقدtoken_per_second إلى الصفر لأننا نستخدم الرموز ذات النقطة العشرية 1distributeTokens contract TokenStream { IERC20 public token; uint256 public streamDuration; uint256 public tokensPerSecond; constructor(IERC20 _token, uint256 _streamDuration, uint256 _tokensPerSecond) { token = _token; streamDuration = _streamDuration; tokensPerSecond = _tokensPerSecond; } function distributeTokens(address recipient) external { uint256 balance = token.balanceOf(address(this)); uint256 amount = tokensPerSecond * streamDuration; uint256 tokensToSend = amount > balance ? balance : amount; require(tokensToSend > 0, "没有足够的代币进行流送"); token.transfer(recipient, tokensToSend); } } contract LowDecimalToken is ERC20 { constructor() ERC20("LowDecimalToken", "LDT") { _mint(msg.sender, 100000 * (10 ** decimals())); } function decimals() public view virtual override returns (uint8) { return 1; // 模拟小数点为低的代币} } في هذه الحالة ، سيتم إعادة اختبار testDOSWithLowDecimalTokens في TokenStreamTest .
العلاج : تأكد من أن العقد يتعامل مع الرموز العشرية المنخفضة بشكل صحيح ، مما يخفف من المشكلات الناجمة عن تقريب الأعداد الصحيحة أثناء عملية الحساب عن طريق تحجيم الصيغ الرياضية .
المشكلة : تعتمد العديد من العقود الذكية على العقود الخارجية للتفاعل. يمكن أن يتسبب السلوك غير المتوقع للعقود الخارجية في تراجع النظام بأكمله . الفشل في التعامل مع هذه الأخطاء الخارجية يمكن أن يؤدي إلى نقاط الضعف DOS.
سؤال قائمة المراجعة : "هل يتناول البروتوكول تفاعلات العقد الخارجي بأمان؟"
الحل : تأكد من معالجة الأخطاء القوية لتفاعلات العقد الخارجية لحماية سلامة البروتوكول بغض النظر عن أداء العقود الخارجية.
مثال : ضع في اعتبارك عقدًا يتفاعل مع مصدر بيانات أسعار SainLink الخارجي. إذا لم تستخدم Try/Catch لمعالجة الأخطاء المناسبة ، فستنتشر أي تراجعات من مصادر البيانات الخارجية إلى المتفوق وتتسبب في تراجع العقد.
getPrice بيانات السعر.calculateSomethingImportant على getPrice وسوف تراجع أيضًا. contract PriceDependentContract { AggregatorV3Interface public priceFeed; constructor(address _priceFeed) { priceFeed = AggregatorV3Interface(_priceFeed); } // 易受攻击的函数，在没有处理可能的Chainlink 回滚的情况下获取价格function getPrice() public view returns (uint256) { (, int256 price, , , ) = priceFeed.latestRoundData(); // 易受攻击的行：没有错误处理require(price > 0, "价格必须为正"); return uint256(price); } function calculateSomethingImportant() public view returns (uint256) { uint256 price = getPrice(); // ... 使用价格的一些重要计算return price * 2; }علاج : لف مكالمات العقد الخارجي في كتلة محاولة/catch للتعامل مع أخطاء التراجع وتنفيذ قيم التراجع أو ذاكرة التخزين المؤقت.
ملاحظة : هناك حالة حافة حيث يستهلك العقد الخارجي عن عمد الغاز ، والذي يمكن أن يفشل أيضًا في كتلة الصيد! سنناقش هذا لاحقًا.
نستكشف ثلاثة اختبارات رئيسية مصممة لتعزيز قدرة عقدك الذكي على مقاومة هجمات DOS: قائمة الانتظار معالجة الضعف ، والتحديات المرتبطة بالرموز العشرية المنخفضة ، وأهمية التعامل مع تفاعلات العقد الخارجي بشكل آمن .
تذكر أن الأمثلة المقدمة تهدف إلى توضيح نقاط الضعف الأساسية. من المهم للغاية فهم المبادئ الأساسية وتكييف هذه المفاهيم مع حالات الاستخدام المحددة.
من خلال تنفيذ هذه الاقتراحات ، يمكنك تحسين أمان ومرونة عقودك الذكية بشكل كبير.
ترقبوا الجزء التالي من سلسلة قرار قائمة التحقق من Solodit.
- الرابط الأصلي: cyfrin.io/blog/solodit-c ...
- مجتمع Denglian Ai Ai Assant يترجم مقالات إنجليزية ممتازة للجميع. إذا كان هناك أي مجالات لا تكون فيها الترجمة مفهومة ، فالرجاء سامحني ~
