Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Security

आपकी जावास्क्रिप्ट ओपन-सोर्स डेपेंडेन्सीज़ कितनी सुरक्षित है?

by
Length:MediumLanguages:

Hindi (हिंदी) translation by Ashish Rampal (you can also view the original English article)

आधुनिक दिनों में जावास्क्रिप्ट डेवलपर्स npm से प्यार करते हैं। GitHub और npm रजिस्ट्री एक विशेष पैकेज खोजने के लिए डेवलपर की पहली पसंद जगह है। ओपन-सोर्स मॉड्यूल डेवलपर्स को कई प्रोजेक्ट्स के साथ उत्पादकता और दक्षता में जोड़ते हैं जिन्हें आप अपने प्रोजेक्ट में पुन: उपयोग कर सकते हैं। यह कहना उचित है कि अगर यह इन ओपन-सोर्स पैकेजों के लिए नहीं था, तो आज के ज्यादातर फ्रेमवर्क उनके वर्तमान रूप में मौजूद नहीं होंगे।

उदाहरण के लिए, एक पूर्ण एंटरप्राइज-लेवल की एप्लीकेशन सैकड़ों पर भरोसा कर सकता है यदि हजारों पैकेज नहीं हैं तो। सामान्य डेपेंडेन्सीज़ में डायरेक्ट डेपेंडेन्सीज़, डेवलपमेंट डेपेंडेन्सीज़, बंडल डेपेंडेन्सीज़, प्रोडक्शन डेपेंडेन्सीज़, और ऑप्शनल डेपेंडेन्सीज़ शामिल हैं। यह बहुत अच्छा है क्योंकि हर किसी को ओपन-सोर्स इकोसिस्टम से सबसे अच्छा फायदा हो रहा है।

हालांकि, अनदेखा किए जाने वाले फैक्टर्स में से एक इसमें शामिल रिस्क की मात्रा है। हालांकि ये थर्ड-पार्टी मॉड्यूल उनके डोमेन में विशेष रूप से उपयोगी हैं, लेकिन वे आपके एप्लिकेशन में कुछ सिक्योरिटी रिस्क भी पेश करते हैं।

ओपन-सोर्स लाइब्रेरी कमजोर हैं?

OSS डेपेंडेन्सीज़ वास्तव में एक्सप्लॉइट और कोम्प्रोमाईज़ करने के लिए कमजोर हैं। आइए कुछ उदाहरण देखें:

हाल ही में eslint-scope नामक पैकेज में एक वल्नेरेबिलिटी की खोज की गई जो कि कई लोकप्रिय जावास्क्रिप्ट पैकेजों जैसे कि babel-eslint और webpack की डिपेंडेंसी है। पैकेज मेंटेनर का अकाउंट कोम्प्रोमाईज़ किया गया था, और हैकर्स ने इसमें कुछ दुर्भावनापूर्ण (malicious) कोड जोड़े। सौभाग्य से, किसी ने जल्द ही एक्सप्लॉइट का पता लगा लिए जिससे नुक्सान को कुछ यूज़र्स ने ही रिपोर्ट किया।

Moment.js, जो जावास्क्रिप्ट में पार्सिंग और तारिख प्रदर्शित करने के लिए सबसे अधिक उपयोग की जाने वाली लाइब्रेरीज में से एक है, को हाल ही में 7.5 के गंभीर स्कोर के साथ वल्नेरेबिलिटी मिली है। एक्सप्लॉइट ने इसे ReDoS हमलों के लिए कमजोर बना दिया। पैच को जल्दी से जारी किया गया था, और वे इस मुद्दे को जल्दी से ठीक करने में सक्षम थे।

लेकिन यह सब कुछ नहीं है। हर हफ्ते कई नए एक्सप्लॉइट्स मिलते हैं। उनमें से कुछ पब्लिक के सामने डिस्क्लोस होते हैं, लेकिन अन्य गंभीर उल्लंघन के बाद ही हेडलाइंस बनते हैं।

तो हम इन जोखिमों को कैसे कम करते हैं? इस आर्टिकल में, मैं कुछ इंडस्ट्री-स्टैण्डर्ड सर्वोत्तम प्रैक्टिस को समझाऊंगा जिनका उपयोग आप अपनी ओपन-सोर्स डेपेंडेन्सीज़ को सुरक्षित करने के लिए कर सकते हैं।

1. अपने एप्लीकेशन की डेपेंडेन्सीज़ का ट्रैक करें

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

ये डेपेंडेन्सीज़ आसानी से खोजने योग्य हैं और आपके एप्लीकेशन की रुट डायरेक्टरी में npm ls चलाने के समान सरल हो सकती हैं। आप -prod आर्गुमेंट का उपयोग कर सकते हैं जो सभी प्रोडक्शन डेपेंडेन्सीज़ और प्रत्येक पैकेज डिस्क्रिप्शन के सारांश के लिए -long आर्गुमेंट को प्रदर्शित करता है।

इसके अलावा, आप डिपेंडेंसी मैनेजमेंट प्रोसेस को स्वचालित करने के लिए एक सर्विस का उपयोग कर सकते हैं जो आपकी डेपेंडेन्सीज़ के लिए रियल टाइम मॉनिटरिंग और आटोमेटिक अपडेट टेस्टिंग प्रदान करता है। कुछ परिचित टूल्स में GreenKeeper, Libraries.io, इत्यादि शामिल हैं। ये टूल उन डेपेंडेन्सीज़ की एक सूची को एकत्रित करते हैं जिनका आप वर्तमान में उपयोग कर रहे हैं और उनके बारे में रिलेवेंट इनफार्मेशन ट्रैक कर सकते हैं।

2. उन पैकेजों से छुटकारा पाएं जिनकी आपको आवश्यकता नहीं है

आपके कोड में समय और परिवर्तन के साथ, यह संभावना है कि आप कुछ पैकेजों का उपयोग बंद कर देंगे और इसके बजाय नए में जोड़ देंगे। हालांकि, डेवलपर्स पुराने पैकेज को नहीं हटाते हैं वे साथ ही चलते जाते हैं।

समय के साथ, आपके प्रोजेक्ट बहुत सारी बिना प्रयोग की डेपेंडेन्सीज़ को जमा कर सकता है। यद्यपि यह डायरेक्ट सिक्योरिटी रिस्क नहीं है, लेकिन ये डेपेंडेन्सीज़ लगभग निश्चित रूप से आपके प्रोजेक्ट को अटैक सरफेस में जोड़ती हैं और कोड में अनावश्यक क्लटर का कारण बनती हैं। एक अटैकर एक पुराना लेकिन इन्सटाल्ड पैकेज लोड करके एक लूपहोल पा सकता है जिसमें उच्च वल्नेरेबिलिटी का हिस्सा होता है, जिससे संभावित क्षति हो सकती है।

आप ऐसी बिना प्रयोग वाली डेपेंडेन्सीज़ की जांच कैसे करते हैं? आप इसे depcheck टूल की मदद से कर सकते हैं। Depcheck आपके पूरे कोड को required और import कमांड्स के लिए स्कैन करता है। इसके बाद यह इन कमांड्स को या तो इन्सटाल्ड पैकेज या आपके package.json में उल्लिखित करता है और आपको एक रिपोर्ट प्रदान करता है। कमांड को विभिन्न कमांड फ्लैग्स का उपयोग करके भी मॉडिफाई किया जा सकता है, जिससे प्रयोग नहीं की जा रही डेपेंडेन्सीज़ की जांच ऑटोमेट करने के लिए इसे आसान बना दिया जा सकता है।

depcheck को इस तरह से इनस्टॉल करें:

3. महत्वपूर्ण सिक्योरिटी भेद्यता खोजें और ठीक करें

ऊपर चर्चा की गई लगभग सभी बिंदु मुख्य रूप से संभावित समस्याओं से संबंधित हैं जिनसे आप सामना कर सकते हैं। लेकिन आप जिन डेपेंडेन्सीज़ का उपयोग कर रहे हैं, उनके बारे में क्या?

हाल के एक अध्ययन के आधार पर, मौजूदा पैकेजों में से लगभग 15% में ज्ञात भेद्यता (known vulnerability) शामिल है, या तो कंपोनेंट्स या डेपेंडेन्सीज़ में। हालांकि, अच्छी खबर यह है कि ऐसे कई टूल हैं जिनका उपयोग आप अपने कोड का विश्लेषण करने और अपने प्रोजेक्ट के भीतर ओपन-सोर्स सिक्योरिटी रिस्क खोजने के लिए कर सकते हैं।

सबसे सुविधाजनक उपकरण npm का npm audit है। ऑडिट एक ऐसी स्क्रिप्ट है जिसे npm के संस्करण 6 के साथ जारी किया गया था। नोड सिक्योरिटी प्लेटफार्म शुरू में npm ऑडिट डेवेलप हुआ, और npm रजिस्ट्री ने इसे बाद में हासिल किया। यदि आप जानना चाहते हैं कि npm ऑडिट क्या है, तो यहां आधिकारिक ब्लॉग से क्वोट दिया गया है:

एक सिक्योरिटी ऑडिट सिक्योरिटी भेद्यता के लिए पैकेज डेपेंडेन्सीज़ का मूल्यांकन है। सिक्योरिटी ऑडिट्स आपको डेपेंडेन्सीज़ में ज्ञात भेद्यता को खोजने और ठीक करने के लिए सक्षम करके अपने पैकेज के यूज़र्स की सुरक्षा में सहायता करती है। npm ऑडिट कमांड आपके पैकेज में कॉन्फ़िगर की गई डेपेंडेन्सीज़ का विवरण आपकी डिफ़ॉल्ट रजिस्ट्री में प्रस्तुत करता है और ज्ञात भेद्यता की एक रिपोर्ट मांगता है।

जनरेटेड रिपोर्ट में आमतौर पर निम्नलिखित विवरण शामिल होते हैं: प्रभावित पैकेज का नाम, भेद्यता की गंभीरता और डिस्क्रिप्शन, पाथ, और अन्य जानकारी, और, यदि उपलब्ध हो, तो कमजोरियों को हल करने के लिए पैच लागू करने के लिए कमांड्स। आप JSON में npm audit --json चलाकर ऑडिट रिपोर्ट भी प्राप्त कर सकते हैं।

इसके अलावा, npm भी रिपोर्ट के आधार पर कार्य करने के तरीके पर सहायता प्रदान करता है। आप पहले से पाए गए मुद्दों को ठीक करने के लिए npm audit fix का उपयोग कर सकते हैं। ये फिक्स आमतौर पर गाइडेड अपग्रेड या ओपन-सोर्स पैच के माध्यम से पूरे किए जाते हैं।

अधिक जानकारी के लिए npm के डॉक्यूमेंटेशन को रेफेर करने के लिए स्वतंत्र महसूस करें।

4. इन-हाउस अल्टरनेटिव के साथ Expired लाइब्रेरीज को रेप्लस करें

ओपन-सोर्स सिक्योरिटी की अवधारणा उस विशेष लाइब्रेरी पर देख रहे आंखों की संख्या पर काफी निर्भर है। सक्रिय रूप से उपयोग किए जाने वाले पैकेज अधिक बारीकी से देखे जाते हैं। इसलिए, बहुत अधिक संभावना है कि डेवलपर ने उस विशेष पैकेज में सभी ज्ञात सुरक्षा मुद्दों को संबोधित किया हो।

चलो एक उदाहरण लेते हैं। GitHub पर, कई JSON वेब टोकन इम्प्लीमेंट हैं जिन्हें आप अपने Node.js लाइब्रेरी के साथ उपयोग कर सकते हैं। हालांकि, जो एक्टिव डेवलपमेंट में नहीं हैं, उनमें महत्वपूर्ण भेद्यता हो सकती है। Auth0 द्वारा रिपोर्ट की गई ऐसी एक भेद्यता, किसी को भी अपने स्वयं के "signed" टोकन बनाने की अनुमति देता है जो भी पेलोड चाहते हैं के साथ।

यदि एक उचित लोकप्रिय या अच्छी तरह से इस्तेमाल किए गए पैकेज में यह दोष था, तो एक डेवलपर ढूंढने और गलती को पकड़ने की बाधाएं अधिक होंगी। लेकिन एक निष्क्रिय/त्यागे गए प्रोजेक्ट के बारे में क्या? हम इसके बारे में अगले पॉइंट में बात करेंगे।

5. हमेशा एक लाइब्रेरी चुनें जो एक्टिव डेवलपमेंट में है

शायद एक विशिष्ट पैकेज की गतिविधि निर्धारित करने का सबसे तेज़ और सबसे प्रभावी तरीका npm पर अपनी डाउनलोड दर जांचना है। आप इसे npm के पैकेज पेज के Stats सेक्शन में पा सकते हैं। npm stats API का उपयोग करके या npm-stat.com पर हिस्टोरिक stats को ब्राउज़ करके इन stats को ऑटोमेटिकली निकालना भी संभव है। GitHub रिपॉजिटरीज़ के साथ पैकेज के लिए, आपको commit हिस्ट्री, issue tracker, और लाइब्रेरी के लिए कोई प्रासंगिक pull requests को देखना चाहिए।

6. डेपेंडेन्सीज़ को अक्सर अपडेट करें

ऐसे कई बग हैं, जिनमें बड़ी संख्या में सिक्योरिटी बग शामिल हैं जिन्हें लगातार खोजा जाता है और, ज्यादातर मामलों में, तुरंत पैच कर लिया जाता है। हाल ही में रिपोर्ट की गई कमजोरियों को किसी दिए गए प्रोजेक्ट की रीसेंट ब्रांच/वर्जन पर पूरी तरह से ठीक किया जाना असामान्य नहीं है।

उदाहरण के लिए, आइए 2016 की शुरुआत में HMAC पैकेज 'hawk' पर रिपोर्ट की Regular Expression Denial of Service (ReDoS) वल्नेरेबिलिटी लें। hawk में यह बग जल्दी से हल हो गया था, लेकिन केवल लेटेस्ट मेजर वर्जन, 4.x में। 3.x जैसे पुराने वर्जन को बहुत बाद में पैच किया गया था, भले ही वे जोखिम में समान थे।

इसलिए, एक सामान्य नियम के रूप में, यदि वे लेटेस्ट उपलब्ध वर्जन का उपयोग करते हैं तो आपकी डेपेंडेन्सीज़ में कोई सुरक्षा बग होने की संभावना कम होती है।

अगर आप नवीनतम वर्जन का उपयोग कर रहे हैं तो पुष्टि करने का सबसे आसान तरीका npm outdated कमांड का उपयोग करना है। यह कमांड ऑटोमेशन को सरल बनाने के लिए किसी भी डेव डेपेंडेन्सीज़ और --json को अनदेखा करने के लिए -prod फ्लैग का समर्थन करता है।

नियमित रूप से उन पैकेजों का निरीक्षण करें जिनका उपयोग आप अपनी मॉडिफिकेशन वाली तारीख को वेरीफाई करने के लिए करते हैं। आप इसे दो तरीकों से कर सकते हैं: npm UI के माध्यम से, या npm view <package> time.modified चलाकर।

निष्कर्ष

अपने एप्लीकेशन को सुरक्षित करने की कुंजी शुरुआत से सिक्योरिटी-फर्स्ट कल्चर है। इस पोस्ट में, हमने आपके जावास्क्रिप्ट कंपोनेंट्स की सुरक्षा में सुधार के लिए कुछ स्टैण्डर्ड प्रथाओं को शामिल किया है।

  1. एक्टिव डेवलपमेंट में ओपन-सोर्स डेपेंडेन्सीज़ का उपयोग करें।
  2. अपने कंपोनेंट्स को पड़ते करें और उसकी निगरानी करें।
  3. अपने कोड की समीक्षा करें और उसके लिए टेस्ट लिखें।
  4. अवांछित डेपेंडेन्सीज़ को हटाएं या अल्टरनेटिव का उपयोग करें।
  5. अपनी डेपेंडेन्सीज़ का विश्लेषण करने के लिए npm audit जैसे सुरक्षा उपकरण का उपयोग करें।

यदि आपके पास जावास्क्रिप्ट सिक्योरिटी के बारे में कोई विचार है, तो उन्हें कमैंट्स में साझा करने के लिए स्वतंत्र महसूस करें।

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.