जोखिम और संभावनाएं या परिदृश्य क्या हैं जिससे कोई व्यक्ति मूल रूप से मास्कर्ड लाइब्रेरी प्रतियां प्रदान करने के लिए मैवेन रिपॉजिटरीज़ और/या आईपी स्ट्रीम के मास्करेड सेट करता है लेकिन दुर्भावनापूर्ण या हानिकारक कोड से इंजेक्शन देता है।मेवेन का उपयोग कितना सुरक्षित है?
ऐसे जोखिमों और संभावनाओं को रोकने के लिए क्या कदम और अभ्यास हैं?
मुझे लगता है एक समर्पित और साधन संपन्न हमलावर एक MITM हमले करते हैं और सार्वजनिक Maven खजाने के लिए सभी अनुरोधों को रोक, ध्यान से दुर्भावनापूर्ण इंजेक्शन लगाने सकता है जेएआर कलाकृतियों में बाइटकोड, फिर एसएचए 1 हैश का पुनर्मूल्यांकन और आपूर्ति।
क्लाइंट के लिए, यह एक वैध आर्टिफैक्ट के रूप में दिखाई देगा: बाइनरी जेएआर और एसएचए 1 मैच और वैकल्पिक मिरर की जांच करने के बावजूद भी वही होगा।
मुझे लगता है कि एकमात्र असली समाधान केंद्रीय रिपोज़ को HTTPS का समर्थन करने का अनुरोध करना है (और विश्वास है कि टीएलएस स्वयं टूट नहीं गया है)।
वैकल्पिक रूप से, एक व्यावहारिक दृष्टिकोण एक मैवेन प्रॉक्सी (आर्टिफैक्टरी या नेक्सस) स्थापित करना हो सकता है जो आंतरिक ग्राहकों को HTTPS पर सेवा प्रदान करता है। इससे हमले की सतह कम हो जाती है और इसका मतलब है कि आपको उस सर्वर से बाहरी दुनिया में संचार लाइनों को सुरक्षित करना होगा। मैं समय-समय पर जांच करूँगा कि प्रॉक्सी पर जेएआरएस और हैश उन लोगों से मिलते हैं जो पूरी तरह से स्वतंत्र, भरोसेमंद नेटवर्क का उपयोग करते हुए सार्वजनिक दर्पणों पर मेल खाते हैं।
तुम सच में, वास्तव में आप पर भरोसा नहीं किया जाएगा सुरक्षित करना चाहते हैं बाइनरी-बजाय, आप सभी स्रोत कोड डाउनलोड हो चाहते हैं और उन्हें हाथ द्वारा की समीक्षा कर उन्हें संकलन से पहले अपने आप को-लेकिन यह है कि मान लिया गया तुम हो समीक्षा करने के लिए पर्याप्त योग्य संसाधन और समय और आरंभ करने के लिए अपनी संपूर्ण बिल्ड टूल श्रृंखला पर भरोसा करें।
ठीक है, परतों में सुरक्षा जैसा कि वे हमेशा कहते हैं।
या आप श्वेतसूची दृष्टिकोण –
का उपयोग कर सकते हैं उन्हें सभी अनुरोधों को रोकने की आवश्यकता नहीं है, केवल एक खराब जार इंजेक्ट करने के लिए पर्याप्त है। और यदि आप वाईफाई का उपयोग कर लैपटॉप पर काम करते हैं, तो यह डब्ल्यूपीए के साथ भी एक संसाधनकारी हमलावर नहीं लेता है। – aij
एमआईटीएम हमला मैवेन केंद्रीय में काम नहीं करता है क्योंकि यह कलाकृतियों के लिए पीजीपी हस्ताक्षर का उपयोग करता है। –
यदि आप प्रसिद्ध रिपोजिटरी (केंद्रीय मेवेन रिपोजिटरी, जेबॉस रिपोजिटरी) का उपयोग करते हैं तो यह हानिकारक कोड इंजेक्शन देने की बहुत कम संभावना है। कंप्यूटर वायरस, आपका आईएसपी, या ऐसा करने के लिए आपके आईएसपी का आईएसपी, DNS सर्वर में गड़बड़ करना होगा, या गंतव्य के कुछ सेट के लिए रूटिंग पथ बदलना होगा। मुझे लगता है कि यह असंभव है - यह केवल मैवेन रिपो के बारे में नहीं है बल्कि सभी इंटरनेट सेवाओं (ईमेल, http, voip और इसी तरह के लिए) है। परियोजना साइटों से सीधे जेएआर डाउनलोड करने के साथ और भी जोखिम क्या है।
वैसे भी, अगर आप एक कुल नियंत्रण आप अपने खुद के Maven भंडार (http://nexus.sonatype.org/) सेट कर सकते हैं करना चाहते हैं
हर फ़ाइल भंडार में उपलब्ध होना चाहिए md5 या शा checksum उत्पन्न - अगर आप डाउनलोड करते हैं तो वास्तव में आप जो चाहते हैं उसे सत्यापित कर सकते हैं। लेकिन - अगर हमलावर (वायरस) आपके डेटा ट्रांसफर और जेएआर फाइलों में गड़बड़ी को रोकने के लिए पर्याप्त स्मार्ट है तो वह एमडी 5/शा चेकस को रोकने के लिए पर्याप्त स्मार्ट होगा। इसके खिलाफ रक्षा चेकसम और कलाकृतियों दोनों के लिए पीजीपी हस्ताक्षर प्रदान करना है - केंद्रीय रेपो को अपलोड किए गए रिलीज कलाकृतियों को ऐसा करने के लिए मजबूर किया जाता है (.asc फाइलें)
अच्छा विचार है Nexus पेशेवर का उपयोग करना - आप कॉन्फ़िगर करने में सक्षम होंगे प्रत्येक बार आर्टिफैक्ट डाउनलोड होने पर सार्वजनिक कुंजी सर्वर के खिलाफ पीजीपी हस्ताक्षर की जांच करने के लिए खरीद सूट। Maven साथ पीजीपी हस्ताक्षर के बारे में अधिक जानकारी यहां पाया जा सकता है:
https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
मैं कई परिदृश्यों के बारे में सोच सकता हूं, हालांकि पहला मैवेन-विशिष्ट नहीं है।
DNS कैश दूषित
डीएनएस डेटा आप मानक खजाने जहर हो सकता है करने के लिए उपयोग करते हैं, एक अलग भंडार से कलाकृतियों डाउनलोड करने के लिए Maven के कारण। the wikipedia article on DNS cache poisoning देखें।
गैर मानक खजाने
किसी भी भंडार है कि आप अपने Maven विन्यास में जोड़ने कलाकृतियों कि दुर्भावनापूर्ण कोड शामिल हैं प्रदान कर सकता है। केवल उन तृतीय पक्ष भंडारों का उपयोग करके इसे रोकें जिन्हें आप भरोसा करते हैं।
भंडार विषाक्तता
Maven के Guide to uploading artifacts to the Central Repository के आधार पर यह केंद्रीय Maven भंडार की तरह लग रहा है अनुमोदित भंडार मेजबान की स्मृतियों को प्रकाशित करता है, तो कलाकृतियों की सुरक्षा मेजबान पर निर्भर करता है। मुझे एक अनुमोदित भंडार मेजबान बनने की प्रक्रिया के बारे में विशिष्ट जानकारी नहीं है, लेकिन बहुत कम सूचीबद्ध के साथ यह शायद कठिन है।
इसके अलावा, केंद्रीय रिपो को सभी तैनाती के लिए पीजीपी हस्ताक्षर की आवश्यकता होती है, इसलिए जब तक किसी दुर्भावनापूर्ण उपयोगकर्ता को किसी प्रोजेक्ट के लिए निजी कुंजी तक पहुंच प्राप्त न हो, मुझे नहीं लगता कि यह संभव है। प्रसारण के दौरान
विरूपण साक्ष्य संशोधन (बीच में आदमी)
Maven सभी कलाकृतियों के लिए स्वत: चेकसम सत्यापन करता है, तो हमलावर विरूपण साक्ष्य और साथ चेकसम दुर्भावनापूर्ण कोड इंजेक्षन करने के लिए संशोधित करना होगा। मुझे नहीं पता कि क्या आप इसे पूरी तरह से रोक सकते हैं, लेकिन यह सुनिश्चित करने के लिए कि आप चेकसम पर ध्यान दे रहे हैं, सुनिश्चित करें कि आपकी चेकसम नीति अनदेखा करने के लिए सेट नहीं है। settings doc देखें।
के रूप में अन्य टिप्पणीकर्ताओं का उल्लेख किया है, अपने उत्पादन तैनाती में प्रवेश करने से दुर्भावनापूर्ण कोड को रोकने के लिए एक अच्छा तरीका उत्पादन रिहाई बनाता है के लिए केवल एक आंतरिक Maven भंडार का प्रयोग है। उस भंडार पर निर्भरताओं के अतिरिक्त पहुंच तक पहुंच प्रतिबंधित करके, आप यह सुनिश्चित कर सकते हैं कि वे सभी स्तरों पर आपके द्वारा चुने गए स्तर पर सत्यापित हैं, उदा। चेकसम डबल-चेकिंग, स्रोत स्कैनिंग।
संबंधित: http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/ –
मैंने इसे हल करने के लिए एक सामान्य उद्देश्य Enforcer प्लगइन नियम लिखा है: https://github.com/gary-rowe/BitcoinjEnforcerRules –
@GaryRowe ऐसा लगता है कि आपकी प्लगइन बाद के डाउनलोड को रोकती है जो रिकॉर्ड किए गए चेकसम से मेल नहीं खाती निर्माण में चेकसम को बेकिंग (जो हमले की सतह को कम करता है, जो अच्छा है), लेकिन जब निर्माण पहली बार बनाया गया है और चेकसम सूची लिखी जाती है (या जेनरेट की जाती है) में यह सुरक्षा नहीं होती है। असल में आप जहर से निर्माण को रोकते हैं * किसी और को * सही? क्या यह आपकी प्लगइन की उचित समझ है? – Gus