अपने वेब एप्लिकेशन को सुरक्षित रखना: इसे तीसरे पक्ष के हस्तक्षेप से कैसे बंद किया जाए

अनुवादक से: हम आपके लिए जिम मेडलॉक, एक प्रोग्रामर और सॉफ्टवेयर आर्किटेक्ट द्वारा एक लेख प्रकाशित कर रहे हैं । मेडलॉक आपके एप्लिकेशन या वेब सेवा की सुरक्षा के बुनियादी तरीकों के बारे में बात करता है। यह ध्यान देने योग्य है कि यह सामग्री नौसिखिए प्रोग्रामर के लिए उपयोगी होने की संभावना है। हालांकि अगर पेशेवरों ने अपनी टिप्पणी छोड़ दी, तो हर कोई आभारी होगा।

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

पिछले कुछ महीनों में, कई बड़े संगठनों ने सूचनाओं के विशाल लीक के बाद खबर को हिट किया है। इनमें फेसबुक और इसके 50 मिलियन चोरी हुए अकाउंट्स, फीफा के 3.4 टीबी डेटा और 70 मिलियन डॉक्युमेंट्स, गूगल के साथ 0.5 मिलियन अकाउंट्स, मैरियट होटल्स के साथ पूरे नेटवर्क के 427 मिलियन कस्टमर्स के डेटा हैं।

स्किलबॉक्स सलाह देता है: दो साल का व्यावहारिक कोर्स "मैं एक प्रो वेब डेवलपर हूं । "

हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।

स्रोत

न केवल हैकर हमलों की संख्या बढ़ रही है, बल्कि साइबर अपराधियों को होने वाली क्षति की मात्रा भी है। विशेषज्ञों के अनुसार, साइबर अपराधियों के कारण प्रत्यक्ष और अप्रत्यक्ष नुकसान का औसत आकार $ 3.86 मिलियन प्रति एक सफल हैक है। बेशक, यह बाजार का एक औसत है; वास्तविक संख्याएं बदलती हैं, और बहुत ज्यादा।

कुछ और आंकड़े। साइबर अपराधियों के कारण होने वाले नुकसान का आंकलन निम्न आंकड़ों द्वारा किया जा सकता है:

• $ 148 - एक चोरी खाते की "कीमत";
• $ 40 मिलियन - 1 मिलियन खातों के लिए;
• $ 350 मिलियन - 50 मिलियन खातों के लिए।

पैसा केवल तर्क नहीं है: इस बारे में सोचें कि सब कुछ क्रम में रखने में कितना समय लगेगा।

इन्फ्रास्ट्रक्चर सुरक्षा बनाम। अनुप्रयोग सुरक्षा

अधिकांश सुरक्षा उपायों का उद्देश्य आईटी अवसंरचना के आधार की रक्षा करना है, जैसे कि सर्वर, भंडारण, डेटा केंद्र। यह आवश्यक है, लेकिन यह केवल उनकी सुरक्षा नहीं है।

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

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

सबसे प्रभावी उपाय परत-दर-परत सुरक्षा की अवधारणा पर आधारित हैं। इस मामले में, संरक्षित तत्वों में से प्रत्येक अपने स्वयं के उपकरण का उपयोग करता है।

आप क्लाइंट-साइड के साथ कुछ नहीं कर सकते

समस्या यह है कि आप उपयोगकर्ता की ओर से अपनी परियोजना की सुरक्षा करने में सक्षम होने की संभावना नहीं है। आधुनिक ब्राउज़र अपने रचनाकारों के प्रयासों के बावजूद असुरक्षित हैं।

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

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

क्या पूरे प्रोजेक्ट से कुंजी जैसे सुरक्षा डेटा को अलग करना सुरक्षित है?

आमतौर पर, पर्यावरण चर का उपयोग किसी फ़ाइल में डेटा को निकालने के लिए किया जाता है, जैसे .env। एक अतिरिक्त कदम यह है कि ऐसी फाइलों का नाम .gitignore में जोड़ा जाए, जो सार्वजनिक रिपॉजिटरी में अपलोड करने के लिए git पुश कमांड्स के निष्पादन को रोकती हैं, जहां फाइल सभी के लिए खुली होगी।



यह सब अच्छा है, लेकिन .env फ़ाइलों को एन्क्रिप्ट नहीं किया गया है। क्रिएट रिएक्ट ऐप के मामले में, उन्हें ब्राउज़र में डेवलपर टूल विकल्प का उपयोग करके बिल्ड / स्टैटिक / जेएस डायरेक्टरी में चेक किया जा सकता है। यहां, उदाहरण के लिए, 0.chunk.js की जांच करते समय हम क्या पाते हैं।



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

निर्णय

क्लाइंट भाग के विपरीत, सर्वर एप्लिकेशन को संरक्षित किया जा सकता है ताकि महत्वपूर्ण डेटा हमलावरों के हाथों में न पड़े। ऐसा करने के लिए, आप प्रमाणीकरण और एक्सेस कंट्रोल, एन्क्रिप्शन और प्रोटोकॉल जैसे HTTPS और TLS प्राप्त करने के लिए Oauth का उपयोग कर सकते हैं।



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

एकीकृत दृष्टिकोण

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

यह "प्रौद्योगिकी द्वीप" पर भरोसा करने के लिए पर्याप्त नहीं है। सभी तत्वों को एक साथ जोड़ना आवश्यक है, यह समझना कि पूरा सिस्टम कैसे काम करेगा।

केवल इस मामले में आवेदन या सेवा सुरक्षित होगी।

• ऑनलाइन कोर्स "प्रोफेशन फ्रंटेंड-डेवलपर । "
• व्यावहारिक वार्षिक पाठ्यक्रम "पीएचपी-डेवलपर 0 से प्रो तक" ।
• ऑनलाइन पाठ्यक्रम पेशा "वेब डेवलपर" ।