टोकन एकत्रीकरण तपासणीसूची

Solidity

स्मार्ट कॉन्ट्रॅक्ट

सुरक्षा

tokens

मध्यम

Trailofbits

Building secure contracts

13 ऑगस्ट, 2020

4 मिनिट वाचन

अनियंत्रित टोकन्ससोबत संवाद साधताना ही तपासणीसूची पाळा. प्रत्येक बाबीशी संबंधित धोके तुम्ही समजून घेतले आहेत याची खात्री करा आणि या नियमांमधील कोणत्याही अपवादांचे समर्थन करा.

सोयीसाठी, सर्व Slither युटिलिटीज (opens in a new tab) थेट टोकन ॲड्रेसवर चालवल्या जाऊ शकतात, जसे की:

Slither वापरण्याचे ट्युटोरियल

slither-check-erc 0xdac17f958d2ee523a2206206994597c13d831ec7 TetherToken

ही तपासणीसूची फॉलो करण्यासाठी, तुम्हाला टोकनसाठी Slither कडून हा आउटपुट हवा असेल:

- slither-check-erc [target] [contractName] [optional: --erc ERC_NUMBER]
- slither [target] --print human-summary
- slither [target] --print contract-summary
- slither-prop . --contract ContractName # कॉन्फिगरेशन आवश्यक आहे, आणि Echidna व Manticore चा वापर

सामान्य विचार

कॉन्ट्रॅक्टचे सुरक्षा पुनरावलोकन झाले आहे. ज्या कॉन्ट्रॅक्ट्सचे सुरक्षा पुनरावलोकन झालेले नाही त्यांच्याशी संवाद साधणे टाळा. मूल्यांकनाची लांबी (उर्फ "प्रयत्नांची पातळी"), सुरक्षा फर्मची प्रतिष्ठा, आणि निष्कर्षांची संख्या व तीव्रता तपासा.
तुम्ही डेव्हलपर्सशी संपर्क साधला आहे. तुम्हाला त्यांच्या टीमला एखाद्या घटनेबद्दल सतर्क करण्याची आवश्यकता असू शकते. blockchain-security-contacts (opens in a new tab) वर योग्य संपर्क शोधा.
त्यांच्याकडे गंभीर घोषणांसाठी एक सुरक्षा मेलिंग लिस्ट आहे. त्यांच्या टीमने वापरकर्त्यांना (तुमच्यासारख्या!) सल्ला द्यावा. जेव्हा गंभीर समस्या आढळतात किंवा जेव्हा अपग्रेड्स होतात.

ERC अनुरूपता

Slither मध्ये एक युटिलिटी, slither-check-erc (opens in a new tab) समाविष्ट आहे, जी अनेक संबंधित ERC मानकांशी टोकनच्या अनुरूपतेचे पुनरावलोकन करते. हे तपासण्यासाठी slither-check-erc वापरा:

Transfer आणि transferFrom एक बुलियन परत करतात. अनेक टोकन्स या फंक्शन्सवर बुलियन परत करत नाहीत. परिणामी, कॉन्ट्रॅक्टमधील त्यांचे कॉल्स अयशस्वी होऊ शकतात.
जर वापरले असेल तर name, decimals, आणि symbol फंक्शन्स उपस्थित आहेत. ही फंक्शन्स ERC20 मानकांमध्ये ऐच्छिक आहेत आणि उपस्थित नसू शकतात.
Decimals एक uint8 परत करते. अनेक टोकन्स चुकीने uint256 परत करतात. असे असल्यास, परत केलेले मूल्य 255 च्या खाली आहे याची खात्री करा.
टोकन ज्ञात ERC20 रेस कंडीशन (opens in a new tab) कमी करते. ERC20 मानकांमध्ये एक ज्ञात ERC20 रेस कंडीशन आहे जी हल्लेखोरांना टोकन चोरण्यापासून रोखण्यासाठी कमी करणे आवश्यक आहे.
टोकन एक ERC777 टोकन नाही आणि transfer व transferFrom मध्ये कोणतेही बाह्य फंक्शन कॉल नाही. ट्रान्सफर फंक्शन्समधील बाह्य कॉल्समुळे रीएन्ट्रन्सी होऊ शकते.

Slither मध्ये एक युटिलिटी, slither-prop (opens in a new tab) समाविष्ट आहे, जी युनिट टेस्ट्स आणि सुरक्षा गुणधर्म निर्माण करते जे अनेक सामान्य ERC त्रुटी शोधू शकतात. हे तपासण्यासाठी slither-prop वापरा:

कॉन्ट्रॅक्ट slither-prop मधील सर्व युनिट टेस्ट्स आणि सुरक्षा गुणधर्मांमध्ये पास होतो. निर्माण केलेल्या युनिट टेस्ट्स चालवा, नंतर Echidna (opens in a new tab) आणि Manticore (opens in a new tab) सह गुणधर्म तपासा.

शेवटी, काही विशिष्ट वैशिष्ट्ये आहेत जी आपोआप ओळखणे कठीण आहे. या परिस्थितींसाठी स्वतः तपासा:

Transfer आणि transferFrom ने फी घेऊ नये. डिफ्लेशनरी टोकन्समुळे अनपेक्षित वर्तन होऊ शकते.
टोकनमधून मिळणारे संभाव्य व्याज विचारात घेतले जाते. काही टोकन्स टोकन धारकांना व्याज वितरित करतात. जर ते विचारात घेतले नाही तर हे व्याज कॉन्ट्रॅक्टमध्ये अडकू शकते.

कॉन्ट्रॅक्ट रचना

कॉन्ट्रॅक्ट अनावश्यक गुंतागुंत टाळतो. टोकन एक साधा कॉन्ट्रॅक्ट असावा; गुंतागुंतीच्या कोड असलेल्या टोकनसाठी उच्च दर्जाचे पुनरावलोकन आवश्यक आहे. गुंतागुंतीचा कोड ओळखण्यासाठी Slither चा human-summary printer (opens in a new tab) वापरा.
कॉन्ट्रॅक्ट SafeMath वापरतो. जे कॉन्ट्रॅक्ट्स SafeMath वापरत नाहीत त्यांना उच्च दर्जाच्या पुनरावलोकनाची आवश्यकता असते. SafeMath वापरासाठी कॉन्ट्रॅक्टची स्वतः तपासणी करा.
कॉन्ट्रॅक्टमध्ये टोकनशी संबंधित नसलेले फक्त काही फंक्शन्स आहेत. टोकनशी संबंधित नसलेले फंक्शन्स कॉन्ट्रॅक्टमध्ये समस्या असण्याची शक्यता वाढवतात. कॉन्ट्रॅक्टमध्ये वापरलेल्या कोडचे विस्तृतपणे पुनरावलोकन करण्यासाठी Slither चा contract-summary printer (opens in a new tab) वापरा.
टोकनला फक्त एकच ॲड्रेस आहे. बॅलन्स अपडेट्ससाठी अनेक एंट्री पॉइंट्स असलेले टोकन्स ॲड्रेसवर आधारित अंतर्गत बुककीपिंग तोडू शकतात (उदा., balances[token_address][msg.sender] वास्तविक बॅलन्स दर्शवू शकत नाही).

मालकाचे विशेषाधिकार

टोकन अपग्रेड करण्यायोग्य नाही. अपग्रेड करण्यायोग्य कॉन्ट्रॅक्ट्स कालांतराने त्यांचे नियम बदलू शकतात. कॉन्ट्रॅक्ट अपग्रेड करण्यायोग्य आहे की नाही हे ठरवण्यासाठी Slither चा human-summary printer (opens in a new tab) वापरा.
मालकाकडे मर्यादित मिंटिंग क्षमता आहे. दुर्भावनापूर्ण किंवा तडजोड केलेले मालक मिंटिंग क्षमतेचा गैरवापर करू शकतात. मिंटिंग क्षमतेचे पुनरावलोकन करण्यासाठी Slither चा human-summary printer (opens in a new tab) वापरा, आणि कोडचे स्वतः पुनरावलोकन करण्याचा विचार करा.
टोकन पॉज करण्यायोग्य नाही. दुर्भावनापूर्ण किंवा तडजोड केलेले मालक पॉज करण्यायोग्य टोकन्सवर अवलंबून असलेले कॉन्ट्रॅक्ट्स अडकवू शकतात. पॉज करण्यायोग्य कोड स्वतः ओळखा.
मालक कॉन्ट्रॅक्टला ब्लॅकलिस्ट करू शकत नाही. दुर्भावनापूर्ण किंवा तडजोड केलेले मालक ब्लॅकलिस्ट असलेल्या टोकन्सवर अवलंबून असलेले कॉन्ट्रॅक्ट्स अडकवू शकतात. ब्लॅकलिस्टिंग वैशिष्ट्ये स्वतः ओळखा.
टोकनमागील टीम ज्ञात आहे आणि गैरवापरासाठी जबाबदार धरले जाऊ शकते. अज्ञात डेव्हलपमेंट टीम असलेले कॉन्ट्रॅक्ट्स, किंवा जे कायदेशीर आश्रयस्थानांमध्ये राहतात त्यांना उच्च दर्जाच्या पुनरावलोकनाची आवश्यकता असेल.

टोकनची टंचाई

टोकन टंचाईच्या समस्यांचे पुनरावलोकन करण्यासाठी स्वतः पुनरावलोकन करणे आवश्यक आहे. या परिस्थिती तपासा:

कोणत्याही एका वापरकर्त्याकडे बहुतेक पुरवठा नाही. जर काही वापरकर्त्यांकडे बहुतेक टोकन्स असतील, तर ते टोकनच्या पुनर्वितरणावर आधारित ऑपरेशन्सवर प्रभाव टाकू शकतात.
एकूण पुरवठा पुरेसा आहे. कमी एकूण पुरवठा असलेल्या टोकन्समध्ये सहज फेरफार केली जाऊ शकते.
टोकन्स काही एक्सचेंजेसपेक्षा जास्त ठिकाणी आहेत. जर सर्व टोकन्स एकाच एक्सचेंजमध्ये असतील, तर त्या एक्सचेंजमधील तडजोड टोकनवर अवलंबून असलेल्या कॉन्ट्रॅक्टशी तडजोड करू शकते.
वापरकर्ते मोठ्या निधी किंवा फ्लॅश लोन्सशी संबंधित धोके समजतात. टोकन बॅलन्सवर अवलंबून असलेल्या कॉन्ट्रॅक्ट्सनी मोठ्या निधी असलेल्या हल्लेखोरांचा किंवा फ्लॅश लोन्सद्वारे होणाऱ्या हल्ल्यांचा काळजीपूर्वक विचार केला पाहिजे.
टोकन फ्लॅश मिंटिंगला परवानगी देत नाही. फ्लॅश मिंटिंगमुळे बॅलन्स आणि एकूण पुरवठ्यात लक्षणीय चढ-उतार होऊ शकतात, ज्यामुळे टोकनच्या ऑपरेशनमध्ये कठोर आणि व्यापक ओव्हरफ्लो तपासणी आवश्यक होते.

पृष्ठ अखेरचे अद्यतन: 3 मार्च, 2026