हमने अभी देखा है कि कैसे एक छोटी सी खामियों से वित्तीय नुकसान होता है (अलग-अलग परिमाण का), उसी तरह सॉलिडिटी पर विकसित स्मार्ट कॉन्ट्रैक्ट विभिन्न ज्ञात और अज्ञात हमलों के लिए प्रवण होते हैं। शोषक स्मार्ट अनुबंधों में झाँकने और हमलों को अंजाम देने के लिए उनमें हेरफेर करने के लिए बग और खामियों का फायदा उठाते हैं। यहां हम सॉलिडिटी प्रोग्रामिंग भाषा में आम तौर पर सामने आई शीर्ष 5 त्रुटियों की एक विस्तृत सूची प्रस्तुत करते हैं।
QuillAudits में हम हर हैक का सार जानने के लिए अनुकूली पद्धति का पालन करते हैं और किसी भी संभावित खतरे से बचने के लिए भविष्य के स्मार्ट अनुबंधों पर इसकी सीख को लागू करते हैं।
सॉलिडिटी प्रोग्रामिंग लैंग्वेज में त्रुटियां
1. अनियंत्रित बाहरी कॉल
हम इस मुद्दे को पहले स्थान पर खींच रहे हैं क्योंकि यह सबसे अधिक देखे जाने वाले सॉलिडिटी नुकसानों में से एक है। आम तौर पर, किसी बाहरी खाते में ईथर भेजने के लिए किया जाता है स्थानांतरण () समारोह। इसके अलावा, बाहरी कॉल करने के लिए दो सबसे व्यापक रूप से उपयोग किए जाने वाले कार्य हैं; कॉल (), तथा भेजने के लिए (), यहाँ मुख्य रूप से कॉल () डेवलपर्स द्वारा बहुमुखी बाहरी कॉल करने के लिए फ़ंक्शन का व्यापक रूप से उपयोग किया जाता है।
यद्यपि कॉल () और भेजने के लिए () फ़ंक्शन एक बूलियन मान लौटाता है जो निर्दिष्ट करता है कि कॉल सफल था या नहीं। इस प्रकार इस मामले में, यदि कोई कार्य कॉल () or भेजने के लिए () कार्य करने में विफल रहता है, वे a . के साथ वापस आ जाएंगे असत्य। इसलिए, यदि डेवलपर रिटर्न वैल्यू को क्रॉस-चेक नहीं करता है, तो यह एक नुकसान बन जाएगा।
भेद्यता
नीचे दिए गए उदाहरण पर विचार करें:
अनुबंध लोट्टो{
बूलपब्लिक ने भुगतान किया = झूठा;
सार्वजनिक विजेता को संबोधित करें;
यूंटपब्लिक विनअमाउंट;
// ... अतिरिक्त कार्यक्षमता यहाँ
फ़ंक्शन भेजें टॉविनर () सार्वजनिक {
आवश्यकता है (! भुगतान किया गया);
विजेता। भेजें (winAmount);
भुगतान किया गया = सच;
}
फ़ंक्शन वापस लेना लेफ्टओवर () सार्वजनिक {
आवश्यकता है (भुगतान किया गया);
msg.sender.send (यह संतुलन);
}
}
ऊपर दिए गए लोट्टो जैसे अनुबंध में, हम देख सकते हैं कि a विजेता प्राप्त जीत राशि किसी भी बाहरी एजेंट से वापस लेने के लिए थोड़ा बचा हुआ ईथर छोड़ देता है।
यहां, अनुबंध के लिए नुकसान लाइन [11] पर मौजूद है, जहां a भेजें प्रतिक्रिया के क्रॉस-सत्यापन के बिना उपयोग किया जाता है। उपरोक्त उदाहरण में, a विजेता जिसका लेन-देन विफल हो जाता है (या तो गैस की कमी से या यदि यह एक अनुबंध है जो जानबूझकर फ़ॉलबैक फ़ंक्शन में फेंकता है), अधिकृत करता है भुगतान किया गया के लिए सेट किया जाना है <strong>उद्देश्य</strong> भले ही ईथर का लेन-देन सफल रहा या नहीं। इस घटना में, कोई भी शोषक वापस ले सकता है विजेता का के माध्यम से जीत वापस लेफ्टओवर समारोह.
QuillAudit का दृष्टिकोण
डेवलपर्स की हमारी इन-हाउस टीम के उपयोग से इस बग से निपटती है [स्थानांतरण] के बजाय समारोह [भेजें] फ़ंक्शन, जैसा कि [स्थानांतरण] बाहरी लेन-देन के वापस आने पर वापस आ जाएगा। और यदि आप [भेजें] का उपयोग कर रहे हैं, तो हमेशा वापसी मूल्य को क्रॉस-चेक करें।
हमारे द्वारा अनुसरण किए जाने वाले मजबूत दृष्टिकोणों में से एक [वापसी पैटर्न] का उपयोग करना है। यहां, हम तार्किक रूप से बाहरी प्रेषण कार्यक्षमता को बाकी कोडबेस से अलग करते हैं, और संभावित रूप से विफल लेनदेन का दबाव अंतिम उपयोगकर्ता पर डालते हैं, क्योंकि वह निकासी फ़ंक्शन को कॉल करने वाला है।
2. पुन: प्रवेश
एथेरियम स्मार्ट कॉन्ट्रैक्ट अन्य बाहरी अनुबंधों से कोड को कॉल और उपयोग करते हैं, और इसे संचालित करने के लिए, अनुबंधों को बाहरी कॉल जमा करने की आवश्यकता होती है। ये बाहरी कॉल असुरक्षित और हमलों के लिए प्रवण हैं, ऐसा ही एक हमला हाल ही में डीएओ हैक के मामले में हुआ था।
भेद्यता
जब कोई अनुबंध किसी अज्ञात पते पर ईथर भेजता है तो हमलावर ऐसे हमले करते हैं। इस मामले में, हमलावर बाहरी पते पर एक अनुबंध बना सकता है जिसमें फ़ॉलबैक फ़ंक्शन में दुर्भावनापूर्ण कोड होता है, और यह दुर्भावनापूर्ण कोड तब लागू किया जाएगा जब अनुबंध इस पते पर ईथर भेजता है।
तथ्य: 'रीएंट्रेंसी' शब्द इस तथ्य से गढ़ा गया है कि जब कोई बाहरी दुर्भावनापूर्ण अनुबंध किसी फ़ंक्शन को कमजोर अनुबंध पर कॉल करता है और फिर कोड निष्पादन पथ 'फिर से प्रवेश' करता है।
नीचे दिए गए उदाहरण पर विचार करें, यह एक एथेरियम वॉल्ट है जो जमाकर्ताओं को प्रति सप्ताह केवल 1 ईथर निकालने की अनुमति देता है।
अनुबंध ईथरस्टोर {
uint256 सार्वजनिक निकासी सीमा = 1 ईथर;
मानचित्रण (पता => uint256) सार्वजनिक अंतिम विथड्राटाइम;
मानचित्रण (पता => uint256) सार्वजनिक शेष;
फंक्शन डिपॉजिटफंड्स () बाहरी देय {
शेष [msg.sender] += msg.value;
}
समारोह निकासीफंड (uint256 _weiToWithdraw) सार्वजनिक {
आवश्यकता (शेष [msg.sender] >= _weiToWithdraw);
// निकासी को सीमित करें
आवश्यकता है (_weiToWithdraw <= निकासी सीमा);
// वापस लेने के लिए अनुमत समय को सीमित करें
आवश्यकता है (अब> = अंतिम निकासी समय [msg.sender] + 1 सप्ताह);
आवश्यकता है (msg.sender.call.value (_weiToWithdraw) ());
शेष राशि [msg.sender] -= _weiToWithdraw;
lastWithdrawTime [msg.sender] = अब;
}
}
उपरोक्त अनुबंध में, हमारे पास दो सार्वजनिक कार्य हैं, [जमा निधि] और [निकासी निधि]। [जमा निधि] का उपयोग प्रेषक की शेष राशि को बढ़ाने के लिए किया जाता है, जबकि [निकासी निधि] निकासी की जाने वाली राशि को निर्दिष्ट करता है। इस मामले में, यह एक सफलता होगी यदि निकाली जाने वाली राशि 1 ईथर से कम है।
यहाँ गड्ढा लाइन [17] में है जहाँ ईथर का स्थानांतरण होता है। हमलावर एकमात्र कंस्ट्रक्टर पैरामीटर के रूप में [ईथरस्टोर्स] के अनुबंध पते के साथ एक दुर्भावनापूर्ण अनुबंध बना सकता है। यह [ईथरस्टोर] को एक सार्वजनिक चर बना देगा, इसलिए हमला होने की अधिक संभावना है।
क्विलऑडिट का दृष्टिकोण App
स्मार्ट अनुबंधों में संभावित पुनर्प्रवेश कमजोरियों से बचने के लिए हम विभिन्न तकनीकों का पालन करते हैं। ईथर को किसी बाहरी अनुबंध में स्थानांतरित करते समय सबसे पहला और सबसे अच्छा संभव तरीका बिल्ट-इन [ट्रांसफर] फ़ंक्शन का उपयोग है।
दूसरे, यह सुनिश्चित करना महत्वपूर्ण है कि ईथर को अनुबंध से बाहर भेजने से पहले राज्य चर में सभी तर्क परिवर्तन किए जाने चाहिए। [ईथरस्टोर] उदाहरण में, लाइन [१८] और [१९] को लाइन [१७] से पहले रखा जाना चाहिए।
रीएंट्रेंट कॉलों को रोकने के लिए तीसरी तकनीक का भी उपयोग किया जा सकता है; एक म्यूटेक्स की शुरूआत के माध्यम से। यह एक स्टेट वेरिएबल का एक अतिरिक्त है जो कोड निष्पादन के दौरान अनुबंध को लॉक कर देगा।
3. डिफ़ॉल्ट दृश्यता
सॉलिडिटी में हमारे द्वारा उपयोग किए जाने वाले कार्यों के लिए दृश्यता विनिर्देशक हैं, और वे उस तरीके को निर्धारित करते हैं जिस तरह से उन्हें बुलाया जा सकता है। यह दृश्यता है जो कार्यों की कॉलिंग को निर्धारित करती है; बाहरी रूप से उपयोगकर्ताओं द्वारा, अन्य व्युत्पन्न अनुबंधों द्वारा, केवल आंतरिक रूप से या केवल बाह्य रूप से। आइए देखें कि कैसे दृश्यता विनिर्देशों का गलत उपयोग स्मार्ट अनुबंधों में भारी भेद्यता पैदा कर सकता है।
भेद्यता
डिफ़ॉल्ट रूप से, फ़ंक्शन की दृश्यता [सार्वजनिक] है, इसलिए बाहरी उपयोगकर्ता फ़ंक्शन को बिना किसी विशिष्ट दृश्यता के कॉल कर सकते हैं। बग तब उत्पन्न होता है जब डेवलपर्स उन कार्यों पर दृश्यता निर्दिष्ट करना भूल जाते हैं जो निजी होना चाहिए (या अनुबंध के भीतर ही कहा जा सकता है)। उदाहरण के लिए;
अनुबंध हैशफॉरएथर {
फंक्शन विदड्रॉविनिंग्स () {
// विजेता यदि पते के अंतिम 8 हेक्स वर्ण 0 . हैं
आवश्यकता है (uint32 (msg.sender) == 0);
_sendWinnings ();
}
समारोह _sendWinnings () {
msg.sender.transfer (यह संतुलन);
}
}
उपरोक्त अनुबंध एक साधारण पता-अनुमान लगाने वाला इनाम खेल है। इसमें, हम देख सकते हैं कि कार्यों की दृश्यता निर्दिष्ट नहीं है, विशेष रूप से [ _sendWinnings] फ़ंक्शन [सार्वजनिक] (डिफ़ॉल्ट रूप से) है, इसलिए इसे किसी भी पते के माध्यम से इनाम चोरी करने के लिए कहा जा सकता है।
QuillAudit का दृष्टिकोण
हमारी इन-हाउस टीम में अनुभवी डेवलपर्स शामिल हैं जो हमेशा सर्वोत्तम ऑडिट प्रथाओं का पालन करते हैं, यहां कार्यों की दृश्यता स्पष्ट रूप से निर्दिष्ट की जानी चाहिए, भले ही उन्हें सार्वजनिक रखा जाए, इसका उल्लेख किया जाना चाहिए।
4. कंस्ट्रक्टर्स के उपयोग की सुरक्षा
आम तौर पर, कंस्ट्रक्टर्स को विशेष कार्य कहा जाता है जिनका उपयोग अनुबंधों को प्रारंभ करते समय महत्वपूर्ण और विशेषाधिकार प्राप्त कार्यों को करने के लिए किया जाता है। सॉलिडिटी [v0.4.22] से पहले, कंस्ट्रक्टर उसी नाम को धारण कर रहे थे जिसका इस्तेमाल अनुबंध में किया गया था। अब, एक ऐसे मामले पर विचार करें जहां विकास चरण के दौरान अनुबंध का नाम बदल दिया जाता है, लेकिन कंस्ट्रक्टर का नाम वही रहता है, यह खामी हमलावरों को आपके स्मार्ट अनुबंध में आसान प्रवेश भी प्रदान कर सकती है।
भेद्यता
यदि अनुबंध का नाम संशोधित किया जाता है तो इसके गंभीर परिणाम हो सकते हैं लेकिन निर्माता का नाम अपरिवर्तित रहता है। उदाहरण के लिए:
अनुबंध स्वामी वॉलेट {
पता सार्वजनिक मालिक;
// कंस्ट्रक्टर
समारोह स्वामी वॉलेट (पता _स्वामी) सार्वजनिक {
मालिक = _स्वामी;
}
// मैदान छोड़ना। ईथर लीजिए।
समारोह () देय {}
समारोह वापस लेना () सार्वजनिक {
आवश्यकता है (msg.sender == स्वामी);
msg.sender.transfer (यह संतुलन);
}
}
उपरोक्त अनुबंध में, हम देख सकते हैं कि केवल मालिक ही [वापसी] फ़ंक्शन को कॉल करके ईथर को वापस ले सकता है। यहां, भेद्यता तब होती है जब कंस्ट्रक्टर का नाम अनुबंध से अलग होता है (पहला अक्षर अलग होता है!)। इस प्रकार शोषक [मालिक वॉलेट] फ़ंक्शन को कॉल कर सकता है और खुद को मालिक के रूप में अधिकृत कर सकता है, और फिर [वापसी] को कॉल करके अनुबंध में सभी ईथर वापस ले सकता है।
QuillAudit का दृष्टिकोण
हम सॉलिडिटी कंपाइलर के संस्करण [0.4.22] का अनुपालन करते हैं। इस संस्करण ने एक कीवर्ड पेश किया है; [कन्स्ट्रक्टर] जिसे अनुबंध के नाम से मेल खाने के लिए फ़ंक्शन के नाम की आवश्यकता होती है।
5. टीएक्स। मूल प्रमाणीकरण
यहां, [Tx.Origin] सॉलिडिटी का वैश्विक चर है, इसमें उस खाते का पता होता है जिसने मूल रूप से कॉल या लेनदेन को अंजाम दिया था। इस चर का उपयोग प्रमाणीकरण के लिए नहीं किया जा सकता है, क्योंकि ऐसा करने से अनुबंध फ़िशिंग हमलों के प्रति संवेदनशील हो जाता है।
भेद्यता
[tx.origin] चर के माध्यम से उपयोगकर्ताओं को अधिकृत करने वाले अनुबंध बाहरी हमलों के संपर्क में आते हैं, जिससे उपयोगकर्ता गलत अनुबंध पर प्रमाणित कार्रवाई करते हैं। नीचे दिए गए उदाहरण पर विचार करें:
अनुबंध फ़िशेबल {
पता सार्वजनिक मालिक;
कंस्ट्रक्टर (पता _स्वामी) {
मालिक = _स्वामी;
}
फ़ंक्शन () बाहरी देय {} // ईथर इकट्ठा करें
समारोह वापस लेना सभी (पता _प्राप्तकर्ता) सार्वजनिक {
आवश्यकता है (tx.origin == स्वामी);
_प्राप्तकर्ता.स्थानांतरण (यह संतुलन);
}
}
यहां लाइन [११] पर, अनुबंध [tx.origin] की मदद से [withdrawAll] फ़ंक्शन को अधिकृत करता है।
QuillAudit का दृष्टिकोण
हम आम तौर पर स्मार्ट अनुबंधों में प्राधिकरण के लिए [tx.origin] का उपयोग करने से बचते हैं। हालांकि, [tx.origin] का उपयोग सख्त वर्जित नहीं है, इसके कुछ विशिष्ट उपयोग के मामले हैं। हम वर्तमान अनुबंध को कॉल करने से बाहरी अनुबंधों को अस्वीकार करने के लिए [tx.origin] का उपयोग कर सकते हैं, इसे [require] फॉर्म के [require(tx.origin == msg.sender)] के साथ निष्पादित किया जा सकता है। यह मौजूदा अनुबंध को कॉल करने के लिए मध्यवर्ती अनुबंधों को कॉल करने से बचने के लिए किया जाता है जो अनुबंध को नियमित कोडलेस पते तक सीमित करता है।
अंतिम लपेटें ऊपर
हमने सॉलिडिटी भाषा में पांच सामान्य नुकसानों को व्यापक रूप से कवर किया है। स्मार्ट अनुबंध विकसित करते समय, हमें यह नहीं भूलना चाहिए कि वे डिज़ाइन द्वारा अपरिवर्तनीय हैं, जिसका अर्थ है कि एक बार जब हम उन्हें बना लेते हैं, तो स्रोत कोड को पैच करने का कोई तरीका नहीं होता है।
यह डेवलपर्स के लिए तैनाती से पहले उपलब्ध सुरक्षा परीक्षण और ऑडिटिंग टूल का लाभ उठाने के लिए एक बड़ी चुनौती है।
स्मार्ट कॉन्ट्रैक्ट्स के लिए संभावित दुर्भावनापूर्ण खतरों की खोज करना, और जिन जोखिमों का हमने ऊपर उल्लेख किया है, उन्हें ऑडिटिंग विशेषज्ञों की हमारी इन-हाउस टीम द्वारा बहुत ही अनोखे और मजबूत तरीके से निष्पादित किया जाता है। QuillAudits में हम आपके अनुबंध को सुरक्षित और सुरक्षित रखने के लिए सभी सॉफ़्टवेयर सुरक्षा प्रथाओं के साथ आपके अनुबंध को अद्यतन रखने के लिए सुरक्षा अनुसंधान में अपना सर्वश्रेष्ठ प्रयास करते हैं।
QuillHash तक पहुँचें
वर्षों की एक उद्योग उपस्थिति के साथ, क्विलहाश दुनिया भर में उद्यम समाधान दिया है। विशेषज्ञों की एक टीम के साथ QuillHash एक प्रमुख ब्लॉकचेन डेवलपमेंट कंपनी है, जो डेफी एंटरप्राइज सहित विभिन्न उद्योग समाधान प्रदान करती है, यदि आपको स्मार्ट कॉन्ट्रैक्ट्स ऑडिट में किसी भी तरह की सहायता की आवश्यकता है, तो हमारे विशेषज्ञों तक पहुंचने के लिए स्वतंत्र महसूस करें। यहाँ!
अधिक अपडेट के लिए QuillHash का पालन करें
स्रोत: https://blog.quillhash.com/2021/06/04/top-5-common-errors-in-solvity-programming-language/
- 11
- लेखा
- लाभ
- सब
- आडिट
- प्रमाणीकरण
- प्राधिकरण
- BEST
- blockchain
- दोष
- कीड़े
- कॉल
- मामलों
- कारण
- चुनौती
- कोड
- सामान्य
- कंपनी
- अनुबंध
- ठेके
- वर्तमान
- डीएओ
- Defi
- डिज़ाइन
- डेवलपर
- डेवलपर्स
- विकास
- उद्यम
- ईथर
- ethereum
- कार्यक्रम
- विशेषज्ञों
- फेसबुक
- वित्तीय
- प्रथम
- का पालन करें
- प्रपत्र
- मुक्त
- समारोह
- भविष्य
- खेल
- गैस
- वैश्विक
- महान
- हैक
- यहाँ उत्पन्न करें
- कैसे
- HTTPS
- विशाल
- सहित
- उद्योग
- IT
- भाषा
- नेतृत्व
- प्रमुख
- लाइन
- लिंक्डइन
- सूची
- मैच
- अन्य
- मालिक
- पैच
- पैटर्न
- फ़िशिंग
- फ़िशिंग हमले
- निर्धारित करना
- वर्तमान
- निजी
- प्रोग्रामिंग
- सार्वजनिक
- खींच
- अनुसंधान
- प्रतिक्रिया
- बाकी
- सुरक्षित
- सुरक्षा
- सेवाएँ
- सेट
- सरल
- छोटा
- स्मार्ट
- स्मार्ट अनुबंध
- स्मार्ट अनुबंध
- So
- सॉफ्टवेयर
- दृढ़ता
- समाधान ढूंढे
- राज्य
- सफलता
- परीक्षण
- स्रोत
- धमकी
- पहर
- ऊपर का
- शीर्ष 5
- ट्रांजेक्शन
- लेनदेन
- us
- उपयोगकर्ताओं
- मूल्य
- मेहराब
- दृश्यता
- कमजोरियों
- भेद्यता
- चपेट में
- सप्ताह
- कौन
- अंदर
- साल