Transcript
00:00:00अगर आप NPM पैकेज इंस्टॉल करते हैं, तो आप एक निशाना हैं। शायद आज नहीं, शायद इस हफ्ते नहीं, लेकिन यह
00:00:05निश्चित रूप से आने वाला है। केवल पिछले कुछ महीनों में ही हमारे पास सैकड़ों पैकेज सुरक्षित नहीं रहे हैं,
00:00:09और यह कम नहीं हो रहा है। इसलिए हर बार जब ऐसा कुछ सामने आता है तो चिंता करने के बजाय,
00:00:14मैंने वास्तव में NPM, PNPM, और BUN पर अपने सेटअप को लॉक कर दिया है, और पता चला कि अधिकांश
00:00:18ऐसी चीजें जो आपको बचा सकती थीं, उन्हें सेट अप करने में लगभग 30 सेकंड लगते हैं। तो इस वीडियो में,
00:00:23मैं आपको उन सात बदलावों के बारे में बताऊंगा जो मैंने किए, कॉन्फ़िगरेशन में एक लाइन के बदलाव से लेकर
00:00:27जो सबसे आम हमले को पूरी तरह खत्म कर देता है, उन मुफ्त टूल तक जिन्हें हमलावरों ने खुद सबमिट किया था
00:00:30और जो पैकेज के आपकी मशीन तक पहुंचने से पहले ही उन्हें पकड़ लेंगे। आइए शुरू करते हैं।
00:00:39पहला और सबसे सरल तरीका बस नए पैकेज डाउनलोड करना बंद करना है। इनमें से अधिकांश सप्लाई
00:00:44चेन हमले घंटों के भीतर पकड़े जाते हैं, इसलिए यदि आप बिल्कुल नए वर्जन जारी होने के तुरंत बाद इंस्टॉल नहीं करते हैं,
00:00:48तो आप वास्तव में इनमें से अधिकांश सप्लाई चेन हमलों से पूरी तरह बच जाते हैं। सभी प्रमुख Node.js
00:00:52पैकेज मैनेजर अब किसी न किसी तरह का रिलीज़ एज गेटिंग (release age gating) प्रदान करते हैं। NPM के लिए, आप इसे NPM
00:00:57RC फ़ाइल में सेट करते हैं, और यह दिनों में सेट होता है। PNPM के लिए, आप इसे वैश्विक स्तर पर PNPM config.yaml फ़ाइल में सेट कर सकते हैं,
00:01:03या आप PNPM वर्कस्पेस फ़ाइल का उपयोग करके इसे प्रति प्रोजेक्ट आधार पर सेट कर सकते हैं, और यह मान वास्तव में
00:01:08मिनटों में सेट होता है। और यह भी ध्यान देने योग्य है कि PNPM 11 के बाद से, इसमें डिफ़ॉल्ट रूप से एक दिन का समय होता है,
00:01:14इसलिए यदि आप इसे सेट नहीं भी करते हैं, तब भी आपके पास कुछ सुरक्षा रहती है। BUN के लिए, आप इसे
00:01:17bunfig.toml फ़ाइल में सेट करते हैं, चाहे वैश्विक रूप से या फिर प्रति प्रोजेक्ट, और यह वास्तव में सेकंड में सेट होता है।
00:01:23मुझे वास्तव में आश्चर्य होता है कि एक ही सेटिंग के लिए तीन पैकेज मैनेजरों में, हमने
00:01:27तीन अलग-अलग मानों पर समझौता किया है, और यह इस इकोसिस्टम को काफी अच्छी तरह से दर्शाता है। एक बार जब आप इसे सेट कर लेते हैं,
00:01:32यदि आप फिर tanstack का react start जैसा पैकेज इंस्टॉल करते हैं, तो आप देख सकते हैं कि यह वर्जन इंस्टॉल नहीं करता है,
00:01:36यह वास्तव में सबसे हालिया इंस्टॉल करता है, जो मेरे रिलीज़ एज मानदंड को पूरा करता है, जो मेरे लिए
00:01:41एक सप्ताह पहले था। अब यदि आपको कभी इसे बायपास करने की आवश्यकता हो, शायद आप जिस
00:01:45पैकेज को इंस्टॉल कर रहे हैं उसमें कोई सुरक्षा समस्या है, और आपको नवीनतम वर्जन इंस्टॉल करने की आवश्यकता है, तो आप अभी भी ऐसा कर सकते हैं
00:01:49कमांड लाइन से, लेकिन यहाँ LLMs से भी सावधान रहें, क्योंकि मैंने ऐसे मामले देखे हैं जहाँ LLMs
00:01:54इसका उपयोग करके बायपास कर देते हैं और वैसे भी नवीनतम वर्जन इंस्टॉल कर देते हैं। एक और बात ध्यान में रखें कि
00:01:59NPX और BUNX इस सेटिंग का सम्मान नहीं करते हैं, वे वास्तव में अभी भी नवीनतम वर्जन इंस्टॉल करते हैं,
00:02:03और BUN में इसे ठीक करने के लिए एक ओपन PR है। अब जब हम इन सेटिंग्स में हैं, तो चलिए
00:02:07NPM के लिए इंस्टॉल स्क्रिप्ट्स को भी बंद कर देते हैं। PNPM और BUN में वास्तव में यह व्यवहार डिफ़ॉल्ट रूप से होता है,
00:02:12इसलिए उनके लिए सेट करने के लिए कुछ भी नहीं है। यदि आप नहीं जानते थे, तो जब आप कोई पैकेज इंस्टॉल करते हैं, तो उस पैकेज को
00:02:16इंस्टॉल होने के तुरंत बाद अपना खुद का कोड चलाने की अनुमति होती है, और यह वैध
00:02:20उपयोग मामलों जैसे नेटिव कोड को कंपाइल करने या बाइनरी डाउनलोड करने के लिए किया गया था, लेकिन समस्या यह है कि लगभग हर एक
00:02:26सप्लाई चेन हमले ने इंस्टॉल के तुरंत बाद आपकी मशीन पर दुर्भावनापूर्ण कोड चलाने के लिए इस विधि का उपयोग किया है।
00:02:30यदि आपको कोई ऐसा पैकेज मिलता है जिसे वास्तव में इन स्क्रिप्ट्स में से एक की आवश्यकता है, तो आप अभी भी इसे स्पष्ट रूप से
00:02:34सक्षम कर सकते हैं। PNPM में, जब आप कोई ऐसा पैकेज इंस्टॉल करते हैं जिसमें पोस्ट-इंस्टॉल स्क्रिप्ट्स होती हैं, तो यह वास्तव में आपको बता देगा,
00:02:39जैसे यहाँ esbuild, और फिर आप यह चुनने के लिए 'pnpm approved-builds' चला सकते हैं कि किसे अनुमति देनी है,
00:02:44और यह वास्तव में आपके PNPM वर्कस्पेस 'allow builds' कॉन्फ़िगरेशन को सेट करता है, और आप बस
00:02:48इंस्टॉल कमांड पर 'allow build' फ़्लैग का उपयोग करके भी वही काम कर सकते हैं। BUN के लिए, जैसा कि मैंने कहा, यह इन
00:02:52इंस्टॉल स्क्रिप्ट्स को भी डिफ़ॉल्ट रूप से रोकता है, लेकिन यह जानना उचित है कि इसमें वास्तव में
00:02:56उन पैकेजों की एक क्यूरेटेड सूची है जिन्हें इन स्क्रिप्ट्स को चलाने की अनुमति है, और इसमें वे शामिल हैं जिन्हें मैंने इंस्टॉल किया है जैसे
00:03:00esbuild। आप अपने package.json में 'trusted dependencies' जोड़कर इससे बाहर निकल सकते हैं,
00:03:04इस तरह केवल जिन पैकेजों को आप स्पष्ट रूप से अनुमति देते हैं, वे ही पोस्ट-इंस्टॉल स्क्रिप्ट्स चला पाएंगे।
00:03:09इसमें यह भी कहा गया है कि यदि आप ऐरे को खाली सेट करते हैं, तो उसे डिफ़ॉल्ट सूची को ओवरराइड कर देना चाहिए
00:03:12साथ ही, लेकिन यह मेरे लिए काम नहीं कर रहा है, और ऐसा लगता है कि यह एक बग है जो मुझे GitHub पर
00:03:17भी मिला है। फिलहाल इसके लिए वर्कअराउंड यह है कि उस सूची में एक मान डालें, और फिर डिफ़ॉल्ट
00:03:21सूची को अनदेखा कर दिया जाएगा। BUN के साथ, आप यह देखने के लिए 'bun pm untrusted' भी चला सकते हैं कि कौन से पैकेज
00:03:26स्क्रिप्ट चलाना चाहते हैं लेकिन अभी तक भरोसेमंद नहीं हैं, और फिर आप किसी को अनुमति देने के लिए 'bun pm trust' चला सकते हैं, या बस इसे उस
00:03:30trusted dependencies ऐरे में जोड़ सकते हैं। आप अपने वैश्विक BUN फ़िग में 'install scripts' को 'false' कहकर BUN में स्क्रिप्ट को पूरी तरह से अक्षम भी कर सकते हैं। NPM के लिए, यह थोड़ा अधिक कठिन है। ईमानदारी से, बस
00:03:35NPM का उपयोग न करें, PNPM का उपयोग करें, लेकिन यदि आपको वास्तव में किसी कारण से NPM का उपयोग करना है, तो आप एक समान अनुमति सूची
00:03:40व्यवहार प्राप्त कर सकते हैं Lavamote's allow-scripts NPM पैकेज का उपयोग करके। इस तरह, यह सिर्फ आपके
00:03:45package.json में भी एक अनुमति सूची है। तीसरा सुझाव git-आधारित निर्भरताओं को ब्लॉक करना है। NPM के साथ, एक निर्भरता
00:03:50वास्तव में एक git url के रूप में घोषित की जा सकती है, जो रजिस्ट्री को बायपास करती है, और अपना खुद का NPM RC भी भेज सकती है जो
00:03:55लाइफसाइकिल स्क्रिप्ट को फिर से सक्षम करती है। यह वास्तव में हाल ही के NPM सप्लाई चेन
00:04:01हमले में उपयोग की गई युक्तियों में से एक है जिसने tanstack को प्रभावित किया। आप अपने NPM कॉन्फ़िगरेशन में 'allow-git' को 'none' पर सेट करके इसे रोक सकते हैं,
00:04:05जो उन्हें पूरी तरह से ब्लॉक कर देता है, और दूसरा विकल्प इसे 'root' पर सेट करना है, जो git-आधारित
00:04:10निर्भरताओं को इंस्टॉल करने की अनुमति देता है, लेकिन केवल तभी जब वे आपके रूट package.json में घोषित हों, इसलिए संभवतः
00:04:15आपके द्वारा स्पष्ट रूप से सेट किया गया। PNPM के लिए, यह विकल्प 'block-exotic-sub-dependencies' है। जब इसे true पर सेट किया जाता है,
00:04:19केवल प्रत्यक्ष निर्भरताएं, यानी वे जो आपके रूट package.json में सूचीबद्ध हैं, विदेशी
00:04:25स्रोतों जैसे git रिपॉजिटरी या सीधे table URL का उपयोग कर सकती हैं। यह विकल्प अभी तक Bun में मौजूद नहीं है, लेकिन वहां
00:04:29इसे जोड़ने के लिए एक PR खुला है, तो शायद हम इसे जल्द ही देखेंगे। कॉन्फ़िगरेशन में बदलाव करने वाले सुझावों को समाप्त करने के लिए एक बोनस के रूप में,
00:04:35PNPM में वास्तव में 'trust-policy' सेटिंग है, जिसे हम 'no-downgrade' पर सेट कर सकते हैं, और इसका मतलब है
00:04:40कि यदि किसी पैकेज का ट्रस्ट स्तर उसके पिछले रिलीज़ की तुलना में कम हो गया है तो PNPM विफल हो जाएगा। इसलिए यदि
00:04:45कोई पैकेज पहले एक विश्वसनीय प्रकाशक द्वारा प्रकाशित किया गया था, लेकिन अब इसमें केवल प्रोवेनेंस या
00:04:50कोई विश्वसनीय सबूत नहीं है, तो इंस्टॉलेशन विफल हो जाएगा। यह उन हमलों को पकड़ने में मदद करेगा जो सामान्य
00:04:55प्रकाशन प्रक्रियाओं को बायपास करने के तरीके ढूंढते हैं। हालांकि टिप नंबर चार शायद सबसे शक्तिशाली है, जो है
00:05:00ऐसे टूल का उपयोग करना जो वास्तव में आपके द्वारा इंस्टॉल किए जा रहे पैकेजों को देखता है और उन्हें उनसे पहले ऑडिट कर सकता है
00:05:04आपकी मशीन को छुए। इसके लिए, हमारे पास दो शक्तिशाली और पूरी तरह से मुफ्त टूल हैं। पहला है
00:05:08MPQ। आप अपने सामान्य NPM, PNPM, या Bun कमांड के लिए एक उपनाम (alias) बनाकर इसे सेट कर सकते हैं,
00:05:14ताकि हर बार जब आप कोई इंस्टॉल चलाते हैं, तो यह वास्तव में कुछ चीजों की जांच करता है। यह Snyk के डेटाबेस के खिलाफ ज्ञात
00:05:18कमजोरियों के लिए स्कैन करेगा, और 22 दिनों से कम पुराने किसी भी पैकेज को फ़्लैग करेगा। यह
00:05:23टाइपो-स्कॉटिंग को पकड़ लेगा, जो तब होता है जब किसी ने express जैसा पैकेज 1s के साथ प्रकाशित किया हो, यह उम्मीद करते हुए
00:05:28कि आप टाइपो करेंगे और इसके बजाय वह इंस्टॉल कर लेंगे। यह रजिस्ट्री हस्ताक्षर और
00:05:32बिल्ड प्रोवेनेंस को सत्यापित करेगा। यह आपको चेतावनी देगा जब किसी पैकेज में प्री और पोस्ट इंस्टॉल स्क्रिप्ट्स होंगी, और इन सबके ऊपर
00:05:37वह डाउनलोड काउंट, क्या कोई रीडमी, लाइसेंस, रेपो URL है, जैसी बुनियादी चीजों की जांच करता है,
00:05:41और मेंटेनर का ईमेल क्या है, और क्या वह डोमेन अभी भी पंजीकृत है। यह सब करता है
00:05:46और फिर आपको अपने पैकेजों पर एक इंटरैक्टिव रिपोर्ट देता है, जहाँ आप अभी भी तय कर सकते हैं कि क्या आप
00:05:51इसे इंस्टॉल करना चाहते हैं। दूसरा है सॉकेट फ़ायरवॉल। यह वास्तव में वह है जिसका मैं उपयोग करता हूँ,
00:05:55और फिर से, आप अपने सभी सामान्य पैकेज मैनेजरों के लिए इसे उपनाम (alias) देते हैं, और यह वास्तव में
00:05:59JavaScript के अलावा दूसरों का भी समर्थन करता है, जैसे Python और Rust। MPQ के समान, जब आप
00:06:03इसके साथ कोई इंस्टॉल चलाते हैं, तो यह सॉकेट की जांच करेगा और किसी भी मानव-पुष्टि वाले दुर्भावनापूर्ण पैकेजों को ब्लॉक करेगा, और यह
00:06:08आपको किसी भी AI द्वारा पहचाने गए खतरों पर भी चेतावनी देगा, जो वे हैं जिनकी अभी तक मानव द्वारा समीक्षा नहीं की गई है। सच कहूं तो,
00:06:12मैंने मुख्य रूप से सॉकेट फ़ायरवॉल को चुना क्योंकि यह वह था जिसके बारे में मैंने सबसे पहले सुना था, लेकिन मैं सॉकेट पर भी भरोसा करता हूँ क्योंकि उन्होंने
00:06:16कई हालिया दुर्भावनापूर्ण पैकेजों को पकड़ा है, और हमलावरों ने एक इंटरव्यू भी दिया था जहाँ उन्होंने कहा था
00:06:21कि सॉकेट पैकेज के आपकी मशीन तक पहुंचने से पहले ही मैलवेयर का पता लगा लेगा, जो उनके लिए एक बहुत अच्छा
00:06:25विज्ञापन है, और मुझे यह भी पसंद है कि यह uv pip और cargo के साथ JavaScript से अधिक का समर्थन करता है।
00:06:30यदि आप इनमें से किसी को भी इंस्टॉल करते हैं, तो आप यह सुनिश्चित करना चाहेंगे कि आप अपने पैकेज मैनेजर के
00:06:35कैश को क्लियर करें ताकि यह सुनिश्चित हो सके कि हर इंस्टॉल किया गया पैकेज फ़ायरवॉल द्वारा चेक किया गया है। टिप पांच आपके
00:06:38लॉक फ़ाइलों के बारे में है। आपकी लॉक फ़ाइलें वह जगह हैं जहाँ हर पैकेज के लिए वास्तविक डाउनलोड URL होता है, और
00:06:42समस्या यह है कि लगभग कोई भी PR में अपनी लॉक फ़ाइलों की समीक्षा नहीं करता है। इसलिए यदि कोई आपके
00:06:47रेपो के खिलाफ PR खोलता है, तो वे चुपचाप एक रिजॉल्व्ड URL को उस पैकेज की ओर इंगित करने के लिए संपादित कर सकते हैं जिसे वे नियंत्रित करते हैं, और
00:06:51मिलान करने वाले इंटीग्रिटी हैश को भी सेट कर सकते हैं ताकि कुछ भी अजीब न लगे। अब अगली बार जब आप
00:06:56कोई इंस्टॉल चलाते हैं, तो आप हमलावर के सर्वर से कोड खींच रहे होते हैं। अच्छी खबर यह है, यदि आप PNPM का उपयोग कर रहे हैं, तो आप इसके प्रति संवेदनशील नहीं हैं।
00:07:01यह उन table स्रोतों को नहीं रखता है जिन्हें स्वैप किया जा सकता है, और यह कुछ भी इंस्टॉल नहीं करेगा
00:07:05जो लॉक फ़ाइल में है, लेकिन वास्तव में आपके package.json में घोषित नहीं है। मुझे
00:07:09bun पर कोई ठोस जानकारी नहीं मिली, इसलिए वह अभी भी इसके प्रति संवेदनशील हो सकता है। यदि आप
00:07:14PNPM का उपयोग नहीं कर रहे हैं, तो समाधान lockfileLint नामक टूल का उपयोग करना है। आप इसे एक dev निर्भरता के रूप में इंस्टॉल करते हैं, और यह
00:07:18आपकी लॉक फ़ाइल को सत्यापित करता है, यह जांचते हुए कि हर पैकेज NPM रजिस्ट्री जैसे विश्वसनीय होस्ट से रिजॉल्व होता है। यह
00:07:23जांचता है कि रिजॉल्व्ड URL वास्तव में पैकेज के नाम से मेल खाते हैं, और यह इंटीग्रिटी हैश के वास्तविक होने की भी जांच करता है
00:07:28साथ ही। यदि उसे संदेह होता है कि किसी के साथ छेड़छाड़ की गई है, तो यह इंस्टॉल को विफल कर देगा। टिप 6 है कि
00:07:32CI और प्रोडक्शन में NPM install का उपयोग करना बंद करें, और इसके बजाय क्लीन इंस्टॉल का उपयोग करें। NPM में इसके लिए कमांड
00:07:37बस 'npm ci' है, और bun और PNPM के लिए, आप वास्तव में 'frozen lockfile' फ़्लैग जोड़ते हैं, लेकिन उनके पास CI
00:07:42कमांड भी एक उपनाम (alias) के रूप में हैं जो वही काम करते हैं। PNPM वास्तव में डिफ़ॉल्ट रूप से इसका उपयोग करता है यदि यह पता लगाता है कि यह
00:07:47CI वातावरण में चल रहा है। क्लीन इंस्टॉल कमांड लॉक फ़ाइल में जो कुछ भी है उसे इंस्टॉल करती है,
00:07:52कुछ और नहीं, और यदि लॉक फ़ाइल और package.json सहमत नहीं हैं, तो यह बस रुक जाती है और त्रुटि दिखाती है,
00:07:57अनुमान लगाने और किसी भी तरह इंस्टॉल करने के बजाय। इसलिए इसे एक हमलावर को
00:08:01स्वैप किया गया वर्जन डालने से रोकना चाहिए। इनमें से कुछ भी काम नहीं करता है यदि आप अपनी लॉक फ़ाइल को प्रतिबद्ध नहीं कर रहे हैं
00:08:05पहली जगह में, इसलिए सुनिश्चित करें कि वह वर्जन कंट्रोल में है न कि आपके gitignore में, और मैं स्वीकार करता हूँ जब मैं
00:08:09पहली बार एक बच्चे के रूप में कोडिंग करना सीख रहा था, मुझे वास्तव में लगा कि आपको इन्हें अनदेखा करना चाहिए, इसलिए मैं खुश हूँ
00:08:13मैंने उन्हें प्रतिबद्ध करना सीखा। तो वे छह सुझाव मुख्य रूप से कॉन्फ़िगरेशन और टूलिंग थे, लेकिन कुछ
00:08:17आदतें भी हैं जिन्हें आप हमलों से बचने में मदद के लिए अपना सकते हैं। पहली यह है कि आंख मूंदकर अपडेट करना बंद करें
00:08:21सब कुछ। आप शायद पहले 'npm update' या इस कमांड के अन्य संस्करण चला चुके होंगे, और बस
00:08:25हर निर्भरता को एक बार में उसके नवीनतम वर्जन में अपडेट कर दिया, लेकिन यह उस तरह का सटीक व्यवहार है जिसकी ये
00:08:30हमलावर उम्मीद कर रहे हैं, इसलिए वास्तव में इन अपग्रेड्स के माध्यम से जाएं और खुद से पूछें कि आपको
00:08:35इसे अपग्रेड करने की आवश्यकता क्यों है। दूसरी आदत अधिक से अधिक प्रासंगिक होती जा रही है, बस कम पैकेजों का उपयोग करें। हर
00:08:39निर्भरता जिसे आप जोड़ते हैं, वह एक और हमला सतह है, और इनमें से अधिकांश हमले निर्भरताओं के माध्यम से फैलते हैं
00:08:43एक निर्भरता की, इसलिए वास्तव में यह पूछना उचित है कि आपको उस लाइब्रेरी की आवश्यकता क्यों है। कुछ सामान्य उदाहरण जो मैं देखता हूँ
00:08:48इसके वे चीजें हैं जैसे Lodash उन कार्यों के लिए जिन्हें कोड के एक छोटे स्निपेट के साथ किया जा सकता है, या Axios जब
00:08:53fetch वही काम कर सकता है। मैं ऐसा इसलिए कह रहा हूँ क्योंकि यह प्रासंगिक होता जा रहा है, एजेंटिक
00:08:58कोडिंग के युग में, निर्भरता का उपयोग करने के बजाय AI से अपने लिए कुछ फ़ंक्शन लिखवाना काफी आसान है।
00:09:03तीसरी आदत निर्भरताओं को एक सटीक वर्जन पर पिन करना है, ताकि अपग्रेड हमेशा एक सचेत
00:09:08विकल्प हो, लेकिन बस यह जान लें कि यह वास्तव में केवल उन पैकेजों को लॉक करता है जिन्हें आप अपने package.json में चुनते हैं,
00:09:12और आपकी निर्भरताओं की निर्भरताएं अभी भी अपनी सीमाओं का उपयोग कर सकती हैं, जो कि ठीक यही कारण है कि
00:09:17टिप 1 से वह कूलडाउन मायने रखता है। इन सबको मिलाकर आपको कुछ मानसिक शांति मिलनी चाहिए कि आप
00:09:21गलती से कोई समझौता किया हुआ पैकेज इंस्टॉल नहीं करेंगे। वे अजेय नहीं हैं, लेकिन वे
00:09:25कुछ न होने से तो बेहतर ही हैं। अंतिम सुझाव बस सब कुछ एक हार्डन्ड डेव कंटेनर में चलाना है, लेकिन मैंने हमेशा पाया है
00:09:29कि वह थोड़ी परेशानी का काम है, इसलिए मैं स्थानीय विकास पर वापस आ जाता हूँ। यदि आप कोई अन्य तरीका जानते हैं
00:09:34इस तरह के हमले से खुद को बचाने के लिए, मुझे नीचे कमेंट्स में बताएं, जब आप वहां हों,
00:09:38सब्सक्राइब करें, और हमेशा की तरह आपसे अगले वीडियो में मिलते हैं।
00:09:42सब्सक्राइब करें।
Community Posts
No posts yet. Be the first to write about this video!
Write about this video