# Dependency Confusion

{{#include ../banners/hacktricks-training.md}}

## Basic Information

संक्षेप में, एक dependency confusion vulnerability तब होती है जब एक प्रोजेक्ट एक लाइब्रेरी का उपयोग कर रहा होता है जिसका **गलत स्पेलिंग** है, **अस्तित्वहीन** है या जिसका **निर्धारित संस्करण** नहीं है और उपयोग की गई dependency repository **सार्वजनिक** repositories से **अपडेटेड संस्करणों को इकट्ठा करने** की अनुमति देती है।

- **गलत स्पेलिंग**: **`reqests`** को आयात करें बजाय `requests`
- **अस्तित्वहीन**: `company-logging` को आयात करें, एक आंतरिक लाइब्रेरी जो **अब अस्तित्व में नहीं है**
- **निर्धारित संस्करण नहीं**: एक **आंतरिक** **अस्तित्व में** `company-requests` लाइब्रेरी को आयात करें, लेकिन repo **सार्वजनिक repos** की जांच करता है यह देखने के लिए कि क्या **बड़े संस्करण** हैं।

## Exploitation

> [!WARNING]
> सभी मामलों में हमलावर को केवल एक **दुष्ट पैकेज का नाम** प्रकाशित करने की आवश्यकता है जो पीड़ित कंपनी द्वारा उपयोग की जाने वाली लाइब्रेरी का नाम है।

### गलत स्पेलिंग और अस्तित्वहीन

यदि आपकी कंपनी एक **लाइब्रेरी आयात करने की कोशिश कर रही है जो आंतरिक नहीं है**, तो बहुत संभावना है कि लाइब्रेरी का repo इसे **सार्वजनिक repositories** में खोजने जा रहा है। यदि एक हमलावर ने इसे बनाया है, तो आपका कोड और चलने वाली मशीनें बहुत संभावना है कि समझौता की जाएंगी।

### निर्दिष्ट संस्करण नहीं

डेवलपर्स के लिए यह बहुत सामान्य है कि वे उपयोग की जाने वाली लाइब्रेरी का **कोई संस्करण निर्दिष्ट नहीं करते** हैं, या केवल एक **मुख्य संस्करण** निर्दिष्ट करते हैं। फिर, इंटरप्रेटर उन आवश्यकताओं के अनुसार **नवीनतम संस्करण** डाउनलोड करने की कोशिश करेगा।\
यदि लाइब्रेरी एक **ज्ञात बाहरी लाइब्रेरी** है (जैसे python `requests`), तो एक **हमलावर ज्यादा कुछ नहीं कर सकता**, क्योंकि वह `requests` नाम की लाइब्रेरी नहीं बना सकेगा (जब तक कि वह मूल लेखक न हो)।\
हालांकि, यदि लाइब्रेरी **आंतरिक** है, जैसे इस उदाहरण में `requests-company`, यदि **लाइब्रेरी repo** बाहरी रूप से **नए संस्करणों की जांच करने** की अनुमति देता है, तो यह सार्वजनिक रूप से उपलब्ध एक नए संस्करण की खोज करेगा।\
तो यदि एक **हमलावर जानता है** कि कंपनी `requests-company` लाइब्रेरी **संस्करण 1.0.1** का उपयोग कर रही है (छोटे अपडेट की अनुमति देता है)। वह लाइब्रेरी `requests-company` **संस्करण 1.0.2** को **प्रकाशित** कर सकता है और कंपनी उस लाइब्रेरी का **उपयोग करेगी** बजाय आंतरिक वाले के।

## AWS Fix

यह सुरक्षा कमी AWS **CodeArtifact** में पाई गई (पढ़ें [**इस ब्लॉग पोस्ट में विवरण**](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)).\
AWS ने इसे इस तरह से ठीक किया कि यह निर्दिष्ट करने की अनुमति देता है कि एक लाइब्रेरी आंतरिक है या बाहरी, ताकि बाहरी repositories से आंतरिक निर्भरताओं को डाउनलोड करने से बचा जा सके।

## Finding Vulnerable Libraries

[**Dependency confusion के बारे में मूल पोस्ट**](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) में, लेखक ने हजारों उजागर package.json फ़ाइलों की खोज की जिनमें जावास्क्रिप्ट प्रोजेक्ट की निर्भरताएँ थीं।

## References

- [https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)
- [https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)

{{#include ../banners/hacktricks-training.md}}