[बुकमार्क] Node.js अनुप्रयोगों की सुरक्षा के लिए २३ सिफारिशें

इन दिनों, वेब सेवाओं को लगातार विभिन्न प्रकार के हमलों से अवगत कराया जाता है। इसलिए, सुरक्षा परियोजना के जीवन चक्र के सभी चरणों में याद रखना है। सामग्री के लेखक, जिसका अनुवाद आज हम प्रकाशित करते हैं, GitHub पर एक रिपॉजिटरी बनाए रखते हैं, जिसमें Node.js. पर चल रहे अनुप्रयोगों को सुरक्षित रखने के लिए लगभग 80 सिफारिशें शामिल हैं। कई सुरक्षा प्रकाशनों पर आधारित इस सामग्री में Node.js और कुछ सामान्य युक्तियों के बारे में दो दर्जन से अधिक सिफारिशें हैं। इसके अलावा, यह सामग्री OWASP परियोजना की सूची से शीर्ष 10 कमजोरियों को कवर करती है।

1. कोड की सुरक्षा की जाँच करने के उद्देश्य से, लाइनर के लिए नियमों का उपयोग करें

सिफारिशें

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

→ यहाँ लिंटर नियमों पर कुछ उपयोगी सामग्री है

लिन बाल्डविन लिनिंग के बारे में निम्नलिखित कहते हैं: “लिंटर केवल एक उपकरण नहीं होना चाहिए जो सावधानीपूर्वक उपयोग किए गए रिक्त स्थान, अर्धविराम और eval कमांड के उपयोग के बारे में नियमों का पालन करता है। ESLint डेवलपर को एक शक्तिशाली मंच प्रदान करता है जो कोड में संभावित खतरनाक पैटर्न की एक विस्तृत श्रृंखला का पता लगा सकता है और उसे समाप्त कर सकता है। हम बात कर रहे हैं, उदाहरण के लिए, नियमित अभिव्यक्ति के बारे में, उपयोगकर्ता इनपुट की जाँच के बारे में, और इसी तरह। मेरा मानना ​​है कि लिंटर उन डेवलपर्स को देता है जो सुरक्षा के मुद्दों पर ध्यान देने के लिए एक शक्तिशाली नए उपकरण के बारे में चिंतित हैं। "

संभावित समस्याएं

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

2. एक साथ सर्वर अनुरोधों की संख्या को सीमित करें

सिफारिशें

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

→ यहां सर्वर के लिए अनुरोधों की आवृत्ति को सीमित करने के लिए सिस्टम के कार्यान्वयन पर सामग्री है

संभावित समस्याएं

एक आवेदन जो एक साथ अनुरोधों की संख्या को सीमित करने के लिए एक प्रणाली प्रदान नहीं करता है, उस पर हमला किया जा सकता है, जिससे इसकी विफलता हो जाएगी। यह इस तथ्य में व्यक्त किया गया है कि इस तरह के एप्लिकेशन के उपयोगकर्ताओं को या तो इसके साथ काम करने में कठिनाई होगी या इसके साथ बातचीत करने में सक्षम नहीं होगा।

3. कॉन्फ़िगरेशन फ़ाइलों से गोपनीय जानकारी निकालें या उन्हें एन्क्रिप्ट करें

सिफारिशें

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

→ यहाँ संवेदनशील डेटा के प्रबंधन के बारे में सामग्री है

संभावित समस्याएं

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

4. कोड इंजेक्शन भेद्यताओं को रोकें

सिफारिशें

SQL / NoSQL इंजेक्शन और इसी तरह के अन्य हमलों को रोकने के लिए, हमेशा डेटा सफाई, या नामित या अनुक्रमित पैरामीटर प्रश्नों का समर्थन करने के लिए ORM / ODM पुस्तकालयों या DBMS तंत्र का उपयोग करें, और जाँच करें कि उपयोगकर्ता क्या आ रहा है। क्वेरी टेक्स्ट में कुछ मानों को एम्बेड करने के लिए कभी भी उपयोग न करें, केवल टेम्पलेट स्ट्रिंग स्ट्रिंग, या स्ट्रिंग संयोजन, क्योंकि यह दृष्टिकोण आपके एप्लिकेशन को कमजोरियों की एक विस्तृत श्रृंखला में खोलता है। डेटा के साथ काम करने के लिए उपयोग किए गए Node.js के सभी सम्मानजनक पुस्तकालयों (उदाहरण के लिए, सेक्लाइज़ , Knex , mongoose ) में कोड इंजेक्ट करके हमलों के खिलाफ अंतर्निहित सुरक्षा होती है।

→ यहाँ ORM / ODM पुस्तकालयों का उपयोग करके इंजेक्शन से बचाव की सामग्री दी गई है

संभावित समस्याएं

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

5. प्रक्रिया की असामान्य समाप्ति के लिए शर्तों को स्पष्ट रूप से निर्धारित करके DoS के हमलों से बचें

सिफारिशें

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

संभावित समस्याएं

आइए हम निम्नलिखित स्थिति का विश्लेषण करें। कई Node.js अनुप्रयोग हैं। क्या होता है अगर हम उन्हें खाली JSON के साथ POST अनुरोध के रूप में भेजना शुरू करते हैं? इससे इनमें से कई एप्लिकेशन क्रैश हो जाएंगे।

अब, अगर हम साइबर क्रिमिनल्स की भूमिका निभाते हैं, तो हमारे लिए अनुप्रयोगों को दुर्घटनाग्रस्त होने से बचाने के लिए, उन्हें समान अनुरोध भेजते रहना पर्याप्त होगा।

6. प्रोजेक्ट सुरक्षा बढ़ाने के लिए HTTP प्रतिक्रिया हेडर कॉन्फ़िगर करें

सिफारिशें

एक एप्लिकेशन को सुरक्षा-उन्मुख HTTP हेडर का उपयोग करना चाहिए ताकि हमलावरों को क्रॉस-साइट स्क्रिप्टिंग (एक्सएसएस), क्लिकजैकिंग, और अन्य जैसे सामान्य हमले तकनीकों का सहारा लेने से रोका जा सके। हेडर को अनुकूलित करना हेलमेट जैसे विशेष मॉड्यूल का उपयोग करना आसान है।

→ यहाँ सुरक्षित हेडर का उपयोग करने पर सामग्री है

संभावित समस्याएं

यदि सुरक्षित HTTP हेडर का उपयोग नहीं किया जाता है, तो हमलावर आपके अनुप्रयोगों के उपयोगकर्ताओं पर हमले करने में सक्षम होंगे, जिससे बड़ी कमजोरियां होती हैं।

7. लगातार, स्वचालित रूप से, उन में कमजोर निर्भरता के उपयोग के लिए अपनी परियोजनाओं की जांच करें

सिफारिशें

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

→ यहाँ परियोजना निर्भरता सुरक्षा पर सामग्री है

संभावित समस्याएं

एक हमलावर परियोजना में प्रयुक्त वेब फ्रेमवर्क को निर्धारित कर सकता है और सभी ज्ञात कमजोरियों पर हमले कर सकता है।

8. पासवर्ड प्रोसेसिंग के लिए मानक Node.js क्रिप्टो मॉड्यूल का उपयोग न करने की कोशिश करें, इसके बजाय Bcrypt का उपयोग करें

सिफारिशें

पासवर्ड या अन्य संवेदनशील डेटा (उदाहरण के लिए एपीआई कुंजी) को "नमक" का उपयोग करके क्रिप्टोग्राफ़िक फ़ंक्शन के साथ संसाधित करके संग्रहीत किया जाना चाहिए, जैसे कि Bcrypt। यह कुछ इसी तरह का उपयोग करने के लायक है, न कि सुरक्षा और प्रदर्शन कारणों के लिए मानक Node.js crypto मॉड्यूल।

→ यहाँ Bcrypt के बारे में सामग्री है

संभावित समस्याएं

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

9. उपयोगकर्ता को भेजे गए HTML, JS और CSS डेटा में वर्ण भागने वाले सिस्टम का उपयोग करें

सिफारिशें

यदि कुछ डेटा उपयोगकर्ता के ब्राउज़र को एक अविश्वसनीय स्रोत से भेजे जाते हैं, तो भले ही उन्हें बस प्रदर्शित किया जाना चाहिए, ऐसा डेटा एक कोड हो सकता है जिसे निष्पादित किया जा सकता है। इसे आमतौर पर क्रॉस-साइट स्क्रिप्टिंग (XSS) के रूप में जाना जाता है। आप विशेष पुस्तकालयों का उपयोग करके ऐसे हमलों के जोखिम को कम कर सकते हैं जो डेटा को संसाधित करते हैं ताकि इसे निष्पादित नहीं किया जा सके। इसे एन्कोडिंग या परिरक्षण डेटा कहा जाता है।

→ यहाँ उत्पादन को परिरक्षण के बारे में सामग्री है

संभावित समस्याएं

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

10. सर्वर पर आने वाले JSON डेटा की जाँच करें

सिफारिशें

आने वाले अनुरोधों के निकायों की सामग्री को नियंत्रित करना, यह जाँचना कि क्या वे ऐसे अनुरोधों को देखने के लिए अपेक्षा करते हैं। यदि अनुरोध अपेक्षित रूप से नहीं दिखता है, तो इसे तुरंत संसाधित करना बंद कर दें। प्रत्येक मार्ग के लिए लेखन अनुरोध सत्यापन कोड के समय लेने वाले संचालन से बचने के लिए, आप डेटा सत्यापन के लिए हल्के JSON टूल का उपयोग कर सकते हैं, जैसे कि jsonschema या joi ।

→ यहाँ आने वाले JSON डेटा की जाँच करने पर सामग्री दी गई है

संभावित समस्याएं

यदि सर्वर किसी भी अनुरोध को सौहार्दपूर्वक पूरी तरह से जांच किए बिना स्वीकार करता है, तो यह एप्लिकेशन की हमले की सतह को बढ़ाता है और हमलावरों को उनमें से कई को खोजने की कोशिश करने के लिए प्रेरित करता है जो सिस्टम के "क्रैश" का नेतृत्व करते हैं।

11. ब्लैक लिस्टेड JWT टोकन बनाए रखें

सिफारिशें

JWT टोकन का उपयोग करते समय (उदाहरण के लिए, यदि आप Passport.js के साथ काम करते हैं), तो डिफ़ॉल्ट रूप से, पहले से जारी टोकन के लिए सिस्टम एक्सेस विशेषाधिकारों को रद्द करने के लिए कोई मानक तंत्र नहीं है। यहां तक ​​कि अगर आपको लगता है कि एक निश्चित उपयोगकर्ता असामान्य रूप से कुछ कर रहा है, तो आपके पास टोकन तंत्र के माध्यम से, सिस्टम तक उसकी पहुंच को अवरुद्ध करने का कोई रास्ता नहीं है, जब तक कि उसके पास एक वैध टोकन है। अविश्वसनीय समस्या वाले ब्लैक लिस्ट को लागू करके इस समस्या को कम किया जा सकता है, जिसकी पुष्टि प्रत्येक अनुरोध पर की जाती है।

→ यहाँ JWT टोकन ब्लैक लिस्टेड है

संभावित समस्याएं

गलत हाथों में पड़ने वाले टोकन का उपयोग हमलावर द्वारा किया जा सकता है। वह आवेदन का उपयोग करने और एक साधारण उपयोगकर्ता को प्रतिरूपण करने में सक्षम होगा - टोकन का मालिक।

12. लॉगिन प्रयासों की संख्या को सीमित करें

सिफारिशें

एक्सप्रेस पर आधारित अनुप्रयोगों में, ब्रूट बल के हमलों और डिक्शनरी हमलों से बचाने के लिए, यह उपयुक्त मिडलवेयर का उपयोग करने के लायक है, जैसे एक्सप्रेस-ब्रूट । इसी तरह, आपको महत्वपूर्ण मार्गों जैसे /admin या /login को सुरक्षित रखने की आवश्यकता है। संरक्षण क्वेरी गुणों के विश्लेषण पर आधारित होना चाहिए, जैसे कि क्वेरी में उपयोग किए जाने वाले उपयोगकर्ता नाम या अन्य पहचानकर्ता, जैसे क्वेरी बॉडी पैरामीटर।

→ यहाँ लॉगिन प्रयासों की संख्या को सीमित करने की सामग्री है

संभावित समस्याएं

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

13. एक गैर-रूट उपयोगकर्ता के रूप में Node.js चलाएं

सिफारिशें

एक अत्यंत सामान्य परिदृश्य है, जब Node.js को असीमित विशेषाधिकारों के साथ रूट उपयोगकर्ता के रूप में चलाया जाता है। उदाहरण के लिए, यह है कि डोकर कंटेनरों में डिफ़ॉल्ट रूप से सब कुछ कैसे कॉन्फ़िगर किया गया है। यह अनुशंसा की जाती है कि आप एक ऐसा उपयोगकर्ता बनाएं जिसके पास रूट विशेषाधिकार नहीं हैं, और या तो इसे डॉकर छवि में एम्बेड करें, या उस उपयोगकर्ता की ओर से प्रक्रिया शुरू करें -u username ध्वज के साथ कंटेनर को कॉल करके।

→ यहां Node.js को एक गैर-रूट उपयोगकर्ता के रूप में लॉन्च करने की सामग्री है

संभावित समस्याएं

यदि Node.js रूट उपयोगकर्ता खाते के तहत चलाया जाता है, तो एक हमलावर जो सर्वर पर स्क्रिप्ट चलाने में सक्षम था, उसे स्थानीय मशीन पर असीमित संभावनाएं मिलती हैं। मान लें कि यह iptable settings को change कर सकता है और ट्रैफिक को अपने कंप्यूटर में रीडायरेक्ट कर सकता है।

14. रिवर्स प्रॉक्सी सर्वर या मिडलवेयर का उपयोग करके अनुरोधित प्रेषित डेटा की मात्रा को सीमित करें

सिफारिशें

अनुरोध निकाय में डेटा की मात्रा जितनी अधिक होगी, एकल-थ्रेडेड सर्वर के लिए इस तरह के अनुरोध को संसाधित करना उतना ही कठिन होगा। बड़े अनुरोधों का उपयोग एक हमलावर को अनावश्यक कार्यों के साथ सर्वर को बाढ़ करने का अवसर देता है, उसे भारी संख्या में अनुरोधों के बिना (अर्थात, DoS / DDoS हमले के बिना)। आप एक निश्चित सीमा प्रणाली (एक फ़ायरवॉल या एक लोड बैलेंसर पर) पर आने वाले अनुरोधों के निकायों के आकार को सीमित करके, या केवल थोड़ी मात्रा में डेटा प्राप्त करने वाले बॉडी-पार्सर एक्सप्रेस सेट करके ऐसे हमलों के जोखिम को कम कर सकते हैं।

→ यहां अनुरोधों में प्रेषित डेटा की मात्रा को सीमित करने के बारे में सामग्री है

संभावित समस्याएं

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

15. जावास्क्रिप्ट में eval फ़ंक्शन का उपयोग करने से बचें

सिफारिशें

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

इसके अलावा, आपको new Function निर्माता से बचना चाहिए। setTimeout और setInterval फ़ंक्शंस को गतिशील रूप से उत्पन्न JS कोड को पास करने की आवश्यकता नहीं है।

→ यहाँ सामान के बारे में है

संभावित समस्याएं

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

16. दुर्भावनापूर्ण नियमित अभिव्यक्तियों के साथ एकल-थ्रेडेड Node.js अनुप्रयोगों को अधिभार न डालें

सिफारिशें

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

→ यहाँ एंटी-मालवेयर रेगेक्स मटीरियल है

संभावित समस्याएं

खराब लिखित नियमित अभिव्यक्तियाँ एक विशेष प्रकार के DoS हमलों के अधीन हो सकती हैं, जिसके दौरान इवेंट लूप पूरी तरह से अवरुद्ध हो जाता है। उदाहरण के लिए, नवंबर 2017 में, यह पता चला कि लोकप्रिय moment पैकेज ऐसे हमलों के लिए असुरक्षित था।

17. चर का उपयोग करके लोडिंग मॉड्यूल से बचें

सिफारिशें

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

→ यहाँ सुरक्षित मॉड्यूल लोडिंग पर सामग्री है

संभावित समस्याएं

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

18.

, (, ), «», . , ( cluster.fork() ), npm-, .

→

, , . — , , , .

19.

, , . , , , . child_process.execFile , , , , , .

→ ,

, , , , .

20.

express, , . , , , Error ( ). , , , - , .

→

, , , , , , .

21. npm Yarn

, -, (MFA, multi-factor authentication). npm Yarn , . , , , . , . , , npm, .

, ? eslint, .

22. ,

- . , — , - . , , X-Powered-By , , . , ( , , Node.js express).

→ -

- . , , -, — . .

23.

, . — , Node.js. , OWASP .

• root- .
• ( SSH-).
• , , , . OWASP, .
• , . , .
  
• OAuth, OpenID, . Basic Authentication.
  
• . , ( — ), X , Y .
  
• — , — . , .
  
• , , . ( — GitHub, AWS, Jenkins, ).
  

परिणाम

. , Node.js-.

प्रिय पाठकों! -, ?