स्मार्ट अनुबंध सुरक्षा टूल के लिए एक गाइड

हम तीन विशिष्ट परीक्षण और प्रोग्राम विश्लेषण तकनीकों का उपयोग करने जा रहे हैं:

• स्लिथर के साथ स्थिर विश्लेषण (Static analysis)। प्रोग्राम के सभी पथों का एक ही समय में अनुमान लगाया जाता है और विभिन्न प्रोग्राम प्रस्तुतियों (जैसे, नियंत्रण-प्रवाह-ग्राफ़) के माध्यम से विश्लेषण किया जाता है।
• एकिड्ना के साथ फ़ज़िंग (Fuzzing)। कोड को लेन-देन के छद्म-यादृच्छिक (pseudo-random) निर्माण के साथ निष्पादित किया जाता है। फ़ज़र किसी दी गई विशेषता (property) का उल्लंघन करने के लिए लेन-देन का एक क्रम खोजने का प्रयास करेगा।
• मैन्टिकोर के साथ प्रतीकात्मक निष्पादन (Symbolic execution)। एक औपचारिक सत्यापन तकनीक, जो प्रत्येक निष्पादन पथ को एक गणितीय सूत्र में अनुवादित करती है, जिस पर बाधाओं (constraints) की जांच की जा सकती है।

प्रत्येक तकनीक के अपने फायदे और नुकसान हैं, और यह विशिष्ट मामलों में उपयोगी होगी:

* यदि सभी पथों का बिना टाइमआउट के अन्वेषण किया जाता है

स्लिथर सेकंड के भीतर अनुबंधों का विश्लेषण करता है, हालांकि, स्थिर विश्लेषण से झूठे अलार्म मिल सकते हैं और यह जटिल जांच (जैसे, अंकगणितीय जांच) के लिए कम उपयुक्त होगा। अंतर्निहित डिटेक्टरों तक पुश-बटन पहुंच के लिए API के माध्यम से या उपयोगकर्ता-परिभाषित जांच के लिए API के माध्यम से स्लिथर चलाएं।

एकिड्ना को कई मिनटों तक चलने की आवश्यकता होती है और यह केवल सही सकारात्मक (true positives) परिणाम देगा। एकिड्ना Solidity में लिखी गई उपयोगकर्ता द्वारा प्रदान की गई सुरक्षा विशेषताओं की जांच करता है। यह बग को छोड़ सकता है क्योंकि यह यादृच्छिक अन्वेषण पर आधारित है।

मैन्टिकोर "सबसे भारी (heaviest weight)" विश्लेषण करता है। एकिड्ना की तरह, मैन्टिकोर उपयोगकर्ता द्वारा प्रदान की गई विशेषताओं को सत्यापित करता है। इसे चलने के लिए अधिक समय की आवश्यकता होगी, लेकिन यह किसी विशेषता की वैधता साबित कर सकता है और झूठे अलार्म की रिपोर्ट नहीं करेगा।

सुझाई गई कार्यप्रणाली (Suggested workflow)

यह सुनिश्चित करने के लिए कि अभी कोई साधारण बग मौजूद नहीं है या बाद में पेश नहीं किया जाएगा, स्लिथर के अंतर्निहित डिटेक्टरों के साथ शुरुआत करें। इनहेरिटेंस, वेरिएबल निर्भरता और संरचनात्मक समस्याओं से संबंधित विशेषताओं की जांच करने के लिए स्लिथर का उपयोग करें। जैसे-जैसे कोडबेस बढ़ता है, स्थिति मशीन (state machine) की अधिक जटिल विशेषताओं का परीक्षण करने के लिए एकिड्ना का उपयोग करें। Solidity से अनुपलब्ध सुरक्षा के लिए कस्टम जांच विकसित करने के लिए स्लिथर पर फिर से विचार करें, जैसे किसी फ़ंक्शन को ओवरराइड होने से बचाना। अंत में, महत्वपूर्ण सुरक्षा विशेषताओं, जैसे अंकगणितीय संचालन, का लक्षित सत्यापन करने के लिए मैन्टिकोर का उपयोग करें।

• सामान्य समस्याओं को पकड़ने के लिए स्लिथर के CLI का उपयोग करें
• अपने अनुबंध की उच्च-स्तरीय सुरक्षा विशेषताओं का परीक्षण करने के लिए एकिड्ना का उपयोग करें
• कस्टम स्थिर जांच लिखने के लिए स्लिथर का उपयोग करें
• जब आप महत्वपूर्ण सुरक्षा विशेषताओं का गहन आश्वासन चाहते हैं तो मैन्टिकोर का उपयोग करें

यूनिट परीक्षणों पर एक नोट। उच्च गुणवत्ता वाले सॉफ़्टवेयर बनाने के लिए यूनिट परीक्षण आवश्यक हैं। हालाँकि, ये तकनीकें सुरक्षा खामियों को खोजने के लिए सबसे उपयुक्त नहीं हैं। इनका उपयोग आमतौर पर कोड के सकारात्मक व्यवहार का परीक्षण करने के लिए किया जाता है (यानी, कोड सामान्य संदर्भ में अपेक्षा के अनुरूप काम करता है), जबकि सुरक्षा खामियां उन चरम मामलों (edge cases) में होती हैं जिन पर डेवलपर्स ने विचार नहीं किया था। दर्जनों स्मार्ट अनुबंध सुरक्षा समीक्षाओं के हमारे अध्ययन में, हमारे क्लाइंट के कोड में पाई गई सुरक्षा खामियों की संख्या या गंभीरता पर यूनिट परीक्षण कवरेज का कोई प्रभाव नहीं पड़ा (opens in a new tab)।

सुरक्षा विशेषताओं का निर्धारण

अपने कोड का प्रभावी ढंग से परीक्षण और सत्यापन करने के लिए, आपको उन क्षेत्रों की पहचान करनी होगी जिन पर ध्यान देने की आवश्यकता है। चूंकि सुरक्षा पर खर्च किए गए आपके संसाधन सीमित हैं, इसलिए अपने प्रयास को अनुकूलित करने के लिए अपने कोडबेस के कमजोर या उच्च-मूल्य वाले हिस्सों को स्कोप करना महत्वपूर्ण है। थ्रेट मॉडलिंग (Threat modeling) मदद कर सकती है। निम्नलिखित की समीक्षा करने पर विचार करें:

• रैपिड रिस्क असेसमेंट (Rapid Risk Assessments) (opens in a new tab) (समय कम होने पर हमारा पसंदीदा दृष्टिकोण)
• डेटा-सेंट्रिक सिस्टम थ्रेट मॉडलिंग के लिए गाइड (opens in a new tab) (उर्फ NIST 800-154)
• शोस्टैक थ्रेट मॉडलिंग (Shostack threat modeling) (opens in a new tab)
• STRIDE (opens in a new tab) / DREAD (opens in a new tab)
• PASTA (opens in a new tab)
• कथनों का उपयोग (Use of Assertions) (opens in a new tab)

घटक (Components)

यह जानना कि आप क्या जांचना चाहते हैं, आपको सही टूल चुनने में भी मदद करेगा।

स्मार्ट अनुबंधों के लिए अक्सर प्रासंगिक होने वाले व्यापक क्षेत्रों में शामिल हैं:

• स्थिति मशीन (State machine)। अधिकांश अनुबंधों को एक स्थिति मशीन के रूप में दर्शाया जा सकता है। यह जांचने पर विचार करें कि (1) किसी अमान्य स्थिति तक नहीं पहुंचा जा सकता है, (2) यदि कोई स्थिति मान्य है तो उस तक पहुंचा जा सकता है, और (3) कोई भी स्थिति अनुबंध को फंसाती नहीं है।

  • स्थिति-मशीन विनिर्देशों का परीक्षण करने के लिए एकिड्ना और मैन्टिकोर पसंदीदा टूल हैं।

• एक्सेस नियंत्रण (Access controls)। यदि आपके सिस्टम में विशेषाधिकार प्राप्त उपयोगकर्ता (जैसे, एक मालिक, नियंत्रक, ...) हैं, तो आपको यह सुनिश्चित करना होगा कि (1) प्रत्येक उपयोगकर्ता केवल अधिकृत कार्य कर सकता है और (2) कोई भी उपयोगकर्ता अधिक विशेषाधिकार प्राप्त उपयोगकर्ता के कार्यों को रोक नहीं सकता है।

  • स्लिथर, एकिड्ना और मैन्टिकोर सही एक्सेस नियंत्रण की जांच कर सकते हैं। उदाहरण के लिए, स्लिथर यह जांच सकता है कि केवल श्वेतसूचीबद्ध (whitelisted) फ़ंक्शंस में onlyOwner संशोधक (modifier) का अभाव है। एकिड्ना और मैन्टिकोर अधिक जटिल एक्सेस नियंत्रण के लिए उपयोगी हैं, जैसे कि अनुमति केवल तभी दी जाती है जब अनुबंध किसी दी गई स्थिति तक पहुंचता है।

• अंकगणितीय संचालन (Arithmetic operations)। अंकगणितीय संचालन की सुदृढ़ता की जांच करना महत्वपूर्ण है। ओवरफ़्लो/अंडरफ़्लो को रोकने के लिए हर जगह SafeMath का उपयोग करना एक अच्छा कदम है, हालांकि, आपको अभी भी अन्य अंकगणितीय खामियों पर विचार करना चाहिए, जिसमें राउंडिंग की समस्याएं और अनुबंध को फंसाने वाली खामियां शामिल हैं।

  • मैन्टिकोर यहाँ सबसे अच्छा विकल्प है। यदि अंकगणित SMT समाधानकर्ता (solver) के दायरे से बाहर है तो एकिड्ना का उपयोग किया जा सकता है।

• इनहेरिटेंस की शुद्धता (Inheritance correctness)। Solidity अनुबंध कई इनहेरिटेंस पर बहुत अधिक निर्भर करते हैं। super कॉल को मिस करने वाले शैडोइंग फ़ंक्शन और गलत तरीके से समझे गए c3 रैखिककरण (linearization) क्रम जैसी गलतियाँ आसानी से पेश की जा सकती हैं।

  • इन समस्याओं का पता लगाना सुनिश्चित करने के लिए स्लिथर एक टूल है।

• बाहरी इंटरैक्शन (External interactions)। अनुबंध एक-दूसरे के साथ इंटरैक्ट करते हैं, और कुछ बाहरी अनुबंधों पर भरोसा नहीं किया जाना चाहिए। उदाहरण के लिए, यदि आपका अनुबंध बाहरी ओरेकल (oracles) पर निर्भर करता है, तो क्या यह सुरक्षित रहेगा यदि उपलब्ध ओरेकल में से आधे से समझौता किया जाता है?

  • आपके अनुबंधों के साथ बाहरी इंटरैक्शन का परीक्षण करने के लिए मैन्टिकोर और एकिड्ना सबसे अच्छे विकल्प हैं। मैन्टिकोर में बाहरी अनुबंधों को स्टब (stub) करने के लिए एक अंतर्निहित तंत्र है।

• मानक अनुरूपता (Standard conformance)। इथेरियम मानकों (जैसे, ERC-20) के डिज़ाइन में खामियों का इतिहास रहा है। आप जिस मानक पर निर्माण कर रहे हैं उसकी सीमाओं से अवगत रहें।

  • स्लिथर, एकिड्ना और मैन्टिकोर आपको किसी दिए गए मानक से विचलन का पता लगाने में मदद करेंगे।

टूल चयन चीटशीट

आपके लक्ष्यों के आधार पर अन्य क्षेत्रों की जांच करने की आवश्यकता होगी, लेकिन ध्यान केंद्रित करने वाले ये मोटे-मोटे क्षेत्र किसी भी स्मार्ट अनुबंध सिस्टम के लिए एक अच्छी शुरुआत हैं।

हमारे सार्वजनिक ऑडिट में सत्यापित या परीक्षण की गई विशेषताओं के उदाहरण हैं। वास्तविक दुनिया की सुरक्षा विशेषताओं की समीक्षा करने के लिए निम्नलिखित रिपोर्टों के Automated Testing and Verification अनुभागों को पढ़ने पर विचार करें:

• 0x (opens in a new tab)
• Balancer (opens in a new tab)