mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
81 lines
16 KiB
Markdown
81 lines
16 KiB
Markdown
# DApps - Decentralized Applications
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|
|
|
|
## What is a DApp?
|
|
|
|
DApp एक विकेंद्रीकृत एप्लिकेशन है जो एक पीयर-टू-पीयर नेटवर्क पर चलता है, बजाय इसके कि इसे एक केंद्रीकृत सर्वर पर होस्ट किया जाए। DApps आमतौर पर **ब्लॉकचेन तकनीक** पर बनाए जाते हैं, जो डेटा की पारदर्शिता, सुरक्षा और अपरिवर्तनीयता की अनुमति देता है।
|
|
|
|
## Web3 DApp Architecture
|
|
|
|
[**इस पोस्ट**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications) के अनुसार Web3 DApps आर्किटेक्चर के 3 विभिन्न प्रकार हैं:
|
|
|
|
### "API-less" DApps
|
|
|
|
ये DApps एक ब्लॉकचेन के ऊपर बनाए जाते हैं और किसी भी केंद्रीकृत APIs या बैकएंड पर निर्भर नहीं होते। आप सोच सकते हैं कि ब्लॉकचेन वास्तव में एप्लिकेशन का बैकएंड है। ये **पूर्ण रूप से विकेंद्रीकृत** हैं और सीधे ब्लॉकचेन के माध्यम से एक्सेस किए जा सकते हैं।
|
|
|
|
ब्लॉकचेन के साथ इंटरैक्ट करने के लिए क्लाइंट आमतौर पर एक **वॉलेट** का उपयोग करेगा। वॉलेट लेनदेन पर हस्ताक्षर करेगा और उन्हें ब्लॉकचेन पर भेजेगा। क्लाइंट डेटा पढ़ने के लिए एक **नोड** का भी उपयोग कर सकता है।
|
|
|
|
### "API-Enabled" DApps
|
|
|
|
ये DApps एक ब्लॉकचेन के ऊपर बनाए जाते हैं लेकिन आमतौर पर जानकारी इकट्ठा करने के लिए केंद्रीकृत APIs पर निर्भर करते हैं। ये **अधिकतर विकेंद्रीकृत** होते हैं क्योंकि भले ही वे एक केंद्रीकृत API पर निर्भर करते हैं, DApp की मुख्य कार्यक्षमता अभी भी ब्लॉकचेन पर होती है। क्लाइंट और ब्लॉकचेन के बीच संचार आमतौर पर एक **वॉलेट** के माध्यम से किया जाता है।
|
|
|
|
इस प्रकार के DApp का एक अच्छा उदाहरण एक **NFT मिंटिंग एप्लिकेशन** है। सर्वर छवियों को अपलोड करने की अनुमति देता है लेकिन मिंटिंग क्लाइंट द्वारा वॉलेट के माध्यम से की जाती है।
|
|
|
|
### "Full-Scale" DApps
|
|
|
|
ये DApps एक ब्लॉकचेन के ऊपर बनाए जाते हैं लेकिन केंद्रीकृत APIs और बैकएंड सर्वरों पर भी निर्भर करते हैं। ये **आंशिक रूप से विकेंद्रीकृत** हो सकते हैं क्योंकि क्लाइंट वॉलेट का उपयोग करके ब्लॉकचेन पर संचालन कर सकता है। हालाँकि, आमतौर पर **बैकएंड भी ब्लॉकचेन पर संचालन करने में सक्षम होगा**।
|
|
|
|
इस प्रकार के DApp का एक अच्छा उदाहरण एक क्रॉस-चेन ब्रिज है जहाँ एक ऑफचेन घटक की आवश्यकता होती है **विभिन्न ब्लॉकचेन में स्मार्ट कॉन्ट्रैक्ट्स के साथ संवाद करने के लिए** ताकि संपत्तियों का हस्तांतरण किया जा सके।
|
|
|
|
## Web2 vulnerabilities
|
|
|
|
Web2 की कमजोरियाँ इन प्रकार के एप्लिकेशनों को प्रभावित करती हैं हालाँकि उनका प्रभाव भिन्न हो सकता है:
|
|
|
|
- **क्लाइंट साइड कमजोरियाँ** का प्रभाव बढ़ जाता है क्योंकि Web3 DApps में क्लाइंट आमतौर पर **ब्लॉकचेन पर संचालन करने वाला** होता है वॉलेट के माध्यम से। इसका मतलब है कि XSS जैसे हमले जो क्लाइंट साइड पर JS कोड को निष्पादित करने में सक्षम होते हैं या पृष्ठ की सामग्री के साथ छेड़छाड़ करते हैं, उनका प्रभाव बड़ा हो सकता है क्योंकि वे **वॉलेट के साथ इंटरैक्ट कर सकते हैं** और उपयोगकर्ता को ब्लॉकचेन पर अवांछित संचालन करने के लिए मना सकते हैं।
|
|
- ध्यान दें कि आमतौर पर इन प्रकार के एप्लिकेशनों में क्लाइंट अभी भी वॉलेट के साथ हस्ताक्षर करने से पहले संचालन की समीक्षा कर सकता है। हालाँकि, यदि हमलावर पृष्ठ की सामग्री के साथ छेड़छाड़ करने में सक्षम है, तो यह उपयोगकर्ता को एक लेनदेन पर हस्ताक्षर करने के लिए मना सकता है जो ब्लॉकचेन पर अवांछित संचालन करेगा।
|
|
- **सर्वर साइड कमजोरियाँ** अभी भी उन DApps में मौजूद हैं जो एक बैकएंड सर्वर पर निर्भर करते हैं। इन कमजोरियों का प्रभाव DApp की आर्किटेक्चर पर निर्भर करेगा। हालाँकि, ये अभी भी बहुत समस्याग्रस्त हो सकते हैं क्योंकि एक हमलावर बैकएंड में **कंपनी की कुंजी** पा सकता है जिससे स्मार्ट कॉन्ट्रैक्ट्स के फंड तक पहुँच प्राप्त हो सकती है, या खाता अधिग्रहण कर सकता है जिससे वे उपयोगकर्ताओं से फंड या NFTs चुरा सकते हैं।
|
|
|
|
बेशक, यदि DApp एक बैकएंड का उपयोग नहीं कर रहा है या उपयोग किया गया बैकएंड केवल सार्वजनिक श्रृंखला डेटा या स्थिर पृष्ठ प्रदान करता है, तो DApp की हमले की सतह कम हो जाती है।
|
|
|
|
## Web3 attack surface
|
|
|
|
हालाँकि सामान्यतः एक DApp की हमले की सतह कम होती है क्योंकि कई सुरक्षा जांच हमेशा ब्लॉकचेन पर की जाती हैं, फिर भी कुछ हमले के वेक्टर हैं जिन्हें एक हमलावर द्वारा शोषित किया जा सकता है।
|
|
|
|
यह संभव है कि Web3 DApps की कमजोरियों को निम्नलिखित श्रेणियों में वर्गीकृत किया जा सके:
|
|
|
|
- **गलत तरीके से प्रबंधित ऑन-चेन लेनदेन**: गलत तरीके से स्वरूपित या अनियंत्रित लेनदेन APIs, प्रतिक्रिया-प्रतीक्षा और ब्लॉक-निशान तर्क की कमी, संवेदनशील डेटा का प्रदर्शन, और विफल, वापस लिए गए, या आंतरिक-प्रकार के लेनदेन का गलत प्रबंधन जो दुर्भावनापूर्ण calldata इंजेक्शन की अनुमति देता है।
|
|
|
|
- **स्मार्ट-कॉन्ट्रैक्ट-चालित बैकएंड हमले**: संवेदनशील डेटा को अनुबंधों और डेटाबेस के बीच बिना सत्यापन के संग्रहीत या समन्वयित करना, बिना जांचे इवेंट उत्सर्जन या अनुबंध पते, और शोषण योग्य अनुबंध कमजोरियाँ जो बैकएंड तर्क को विषाक्त कर सकती हैं।
|
|
|
|
- **खराब क्रिप्टो-एसेट संचालन**: विभिन्न टोकन प्रकारों (स्थानीय बनाम ERC-20) को गलत तरीके से संसाधित करना, दशमलव सटीकता की अनदेखी करना, विफल हस्तांतरण या आंतरिक लेनदेन, और बिना सत्यापन के नकली, अपस्फीति, पुनर्संरचना, या स्लिपेज-प्रवण टोकन स्वीकार करना, जो टोकन मेटाडेटा के माध्यम से पेलोड इंजेक्शन की अनुमति देता है।
|
|
|
|
[**इस पोस्ट**](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications) से कुछ उदाहरण:
|
|
|
|
### Wasting Funds: Forcing backend to perform transactions
|
|
|
|
परिदृश्य **`Wasted Crypto in Gas via Unrestricted API`** में, हमलावर बैकएंड को स्मार्ट कॉन्ट्रैक्ट के कार्यों को कॉल करने के लिए मजबूर कर सकता है जो गैस का उपभोग करेगा। हमलावर, केवल एक ETH खाता संख्या भेजकर और बिना किसी सीमा के, बैकएंड को स्मार्ट कॉन्ट्रैक्ट को पंजीकृत करने के लिए कॉल करने के लिए मजबूर करेगा, जो गैस का उपभोग करेगा।
|
|
|
|
### DoS: Poor transaction handling time
|
|
|
|
परिदृश्य **`Poor Transaction Time Handling Leads to DoS`** में बताया गया है कि क्योंकि बैकएंड HTTP अनुरोध को तब तक खुला रखेगा जब तक एक लेनदेन नहीं किया जाता, एक उपयोगकर्ता आसानी से बैकएंड को कई HTTP अनुरोध भेज सकता है, जो बैकएंड के सभी संसाधनों का उपभोग करेगा और DoS की ओर ले जाएगा।
|
|
|
|
### Backend<-->Blockchain desync - Race condition
|
|
|
|
परिदृश्य **`Poor Transaction Time Handling Leads to Race Condition`** में बताया गया है कि एक खेल में उपयोगकर्ता को बैकएंड को एक निकासी अनुरोध भेजने की अनुमति थी जो उपयोगकर्ता को उसके सिक्के भेजेगा लेकिन जब तक लेनदेन अभी भी संसाधित हो रहा था, उपयोगकर्ता उन सिक्कों का उपयोग खेल में वस्तुएं खरीदने के लिए कर सकता था, उन्हें मुफ्त में प्राप्त कर सकता था।
|
|
|
|
एक और उदाहरण यह हो सकता है कि उपयोगकर्ता विभिन्न वस्तुओं को खरीदने के लिए समान सिक्कों का उपयोग कर सके क्योंकि बैकएंड तुरंत उपयोगकर्ता को वस्तु दे रहा है बिना लेनदेन की पुष्टि की प्रतीक्षा किए और इसलिए ब्लॉकचेन में उपयोगकर्ता के संतुलन को कम किए बिना।
|
|
|
|
### Smart contract address validation
|
|
|
|
परिदृश्य **`Bridge Backend Lacks Smart Contract Address Validation`** में बताया गया है कि बैकएंड स्मार्ट कॉन्ट्रैक्ट के पते की जांच कर रहा था, इसलिए एक हमलावर के लिए एक नकली स्मार्ट कॉन्ट्रैक्ट को तैनात करना, उस पर फंड डालना, बैकएंड को लेनदेन भेजना संभव था और बैकएंड यह सोचेगा कि उपयोगकर्ता ने असली स्मार्ट कॉन्ट्रैक्ट को फंड भेजा है और उपयोगकर्ता को टोकन देगा।
|
|
|
|
### Mishandling of Asset Classes
|
|
|
|
परिदृश्य **`Mishandling of Asset Classes`** में बताया गया है कि बैकएंड ने एक पते पर 1 MATIC के साथ एक धोखाधड़ी NFT को भ्रमित किया, जिससे हमलावर को उस पते पर सैकड़ों धोखाधड़ी NFTs भेजने और उनके लिए प्लेटफॉर्म से 1 MATIC प्राप्त करने की अनुमति मिली।
|
|
|
|
## References
|
|
- [https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications](https://www.certik.com/resources/blog/web2-meets-web3-hacking-decentralized-applications)
|
|
|
|
{{#include ../banners/hacktricks-training.md}}
|