CORS, CSP, HTTPS, HSTS: वेब सुरक्षा तकनीकों के बारे में

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

दो बुनियादी वेब सुरक्षा अवधारणाएँ

▍100% सुरक्षा एक मिथक है

सुरक्षा दुनिया में, "हैकिंग के खिलाफ 100% सुरक्षा" जैसी कोई चीज नहीं है। अगर कोई आपको इस स्तर के संरक्षण के बारे में बताता है, तो सचेत रहें कि वह गलत है।

संरक्षण का स्तर पर्याप्त नहीं है

मान लीजिए कि किसी का मानना ​​है कि CSP को लागू करने से, उसने अपनी परियोजना को XSS हमलों से पूरी तरह से बचा लिया। शायद किसी को लगता है कि पूर्ण सुरक्षा किसी दिए गए के रूप में मौजूद नहीं है, लेकिन ऊपर वर्णित एक जैसे विचार किसी को भी देख सकते हैं। अगर हम प्रोग्रामर के बारे में बात करते हैं जिन्होंने सुरक्षा के मुद्दों को समझने का फैसला किया है, तो शायद इस तरह के विचारों का कारण यह है कि प्रोग्राम कोड लिखते समय, वे मुख्य रूप से "ब्लैक" और "व्हाइट" जैसी अवधारणाओं के साथ काम करते हैं, 1 और 0, "सत्य" और "असत्य"। लेकिन सुरक्षा इतनी सरल नहीं है।

वेब सुरक्षा प्रौद्योगिकी

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

▍CORS

क्या आपने कभी ऐसी त्रुटि देखी है:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. 

इस तरह का सामना करते हुए, आप सोचते हैं कि आप निश्चित रूप से पहले नहीं हैं जिनके साथ ऐसा हुआ है। Googling, आपको पता चलता है कि इस समस्या को हल करने के लिए, यह किसी प्रकार के विस्तार को स्थापित करने के लिए पर्याप्त है। अच्छा, यह अद्भुत नहीं है? हालाँकि, CORS तकनीक (क्रॉस-ऑरिजनल रिसोर्स शेयरिंग, विभिन्न स्रोतों के बीच संसाधनों को साझा करना) डेवलपर्स के साथ हस्तक्षेप करने के लिए मौजूद नहीं है, लेकिन उनकी परियोजनाओं की सुरक्षा के लिए।

यह समझने के लिए कि CORS वेब परियोजनाओं की सुरक्षा कैसे करता है, हम पहले कुकीज़ के बारे में बात करेंगे, विशेष रूप से, कुकीज़ उपयोगकर्ताओं को प्रमाणित करने के लिए उपयोग की जाती हैं। इन कुकीज़ का उपयोग उस समय किया जाता है जब एक निश्चित वेब संसाधन के साथ काम करते हुए सर्वर को सूचित किया जाता है कि उपयोगकर्ता लॉग इन है। वे स्वचालित रूप से संबंधित सर्वर पर चल रहे अनुरोधों के साथ भेजे जाते हैं।

मान लीजिए कि आप अपने फेसबुक अकाउंट में लॉग इन हैं, और फेसबुक ऑथेंटिकेशन कुकीज़ का उपयोग करता है। इंटरनेट पर काम करते हुए, आप लिंक bit.ly/r43nugi पर क्लिक करते हैं, आप एक दुर्भावनापूर्ण वेबसाइट पर पुनर्निर्देशित होते हैं, कहते हैं, superevilwebsite.rocks तरह कुछ। इस साइट पर पृष्ठ के साथ डाउनलोड की गई स्क्रिप्ट आपके प्रमाणीकरण कुकी का उपयोग करके facebook.com लिए क्लाइंट अनुरोध करती है।

CORS के बिना एक दुनिया में, superevilwebsite.rocks एक स्क्रिप्ट गुप्त रूप से आपकी FB प्रोफ़ाइल में बदलाव कर सकती है, सभी आगामी परिणामों के साथ, कुछ जानकारी चोरी कर सकती है। ऐसी दुनिया में, एक "महामारी superevilwebsite.rocks" आसानी से उत्पन्न हो सकती है, जब उपयोगकर्ता के खाता प्रबंधन पर कब्जा करने वाली एक स्क्रिप्ट अपने पृष्ठ पर एक लिंक प्रकाशित करती है, जिसके बाद इस उपयोगकर्ता के मित्र "संक्रमित" हो जाते हैं, और उनके पृष्ठों पर प्रकाशित लिंक के माध्यम से, एक महामारी। अंततः फेसबुक के सभी को शामिल किया गया।

हालाँकि, ऐसी दुनिया में जहां CORS मौजूद है, Facebook केवल facebook.com से खाता डेटा को संशोधित करने के लिए अनुरोध करेगा। दूसरे शब्दों में, साइट का प्रशासन विभिन्न स्रोतों के बीच संसाधनों के बंटवारे को सीमित करेगा।

यहां आपके पास निम्नलिखित प्रश्न हो सकते हैं: "लेकिन superevilwebsite.rocks केवल अपने अनुरोधों में स्रोत हेडर को बदल सकते हैं और वे facebook.com से आएंगे?"

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

"क्या होगा अगर superevilwebsite.rocks सर्वर से एक समान अनुरोध करता है?", आप पूछते हैं।

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

▍CSP

सीएसपी (कंटेंट सिक्योरिटी पॉलिसी, कंटेंट प्रोटेक्शन पॉलिसी) क्या है, इसे समझने के लिए, आपको सबसे आम वेब भेद्यताओं में से एक के बारे में बात करनी होगी। यह XSS (क्रॉस-साइट स्क्रिप्टिंग, क्रॉस-साइट स्क्रिप्टिंग) के बारे में है।

XSS हमले करते समय, हमलावर एक विशेष साइट के क्लाइंट भाग में विशेष जावास्क्रिप्ट कोड इंजेक्ट करता है। आप सोच सकते हैं: “अच्छा, यह स्क्रिप्ट क्या करेगी? पृष्ठ तत्वों के रंग बदलें? "

मान लीजिए कि जिस साइट पर आप जा रहे हैं, उसके पृष्ठों में किसी ने सफलतापूर्वक अपनी जेएस स्क्रिप्ट को एम्बेड किया है। एक समान स्क्रिप्ट क्या कर सकती है? वास्तव में, बहुत सी चीजें:

• यह अन्य साइटों के लिए HTTP अनुरोध कर सकता है, यह दिखावा करता है कि आप उन्हें कर रहे हैं।
• वह आपको एक ऐसी साइट पर पुनर्निर्देशित कर सकता है, जो ठीक उसी तरह दिखाई देती है जैसे आप लॉग इन हैं, लेकिन डिज़ाइन किया गया है, उदाहरण के लिए, क्रेडेंशियल्स चुराने के लिए।
• यह उन पृष्ठों में <script> टैग जोड़ने में सक्षम है जिनमें कुछ जावास्क्रिप्ट कोड हैं या जिन्हें किसी प्रकार की JS फ़ाइलों को लोड करने के लिए डिज़ाइन किया गया है।
• वह पृष्ठ पर एक <iframe> तत्व जोड़ सकता है, जो उदाहरण के लिए, साइट में प्रवेश करने के लिए नाम और पासवर्ड दर्ज करने के लिए बिल्कुल फ़ील्ड जैसा दिखेगा। इस मामले में, ऐसे डेटा दर्ज करने के लिए ये फ़ील्ड छिपाए जाएंगे।

वास्तव में, एक XSS हमले को सफलतापूर्वक अंजाम देने के लिए एक हमलावर के लिए खुलने वाली संभावनाएं अनंत हैं।

सामग्री सुरक्षा नीति निम्न प्रतिबंधों को लागू करके इसे रोकने का प्रयास करती है:

• <iframe> में जो खोला जा सकता है, उस पर सीमाएं।
• सीमाएं जिस पर शैली पत्रक लोड किए जा सकते हैं।
• किन प्रश्नों पर सीमाएं निभाई जा सकती हैं।

CSP कैसे काम करता है?

जब आप लिंक पर क्लिक करते हैं या ब्राउज़र के एड्रेस बार में वेबसाइट URL दर्ज करते हैं, तो ब्राउज़र GET अनुरोध करता है। अनुरोध सर्वर पर आता है, जो HTTP हेडर के साथ ब्राउज़र में कुछ एचटीएमएल कोड पास करता है। यदि आप इन शीर्षकों को देखने में रुचि रखते हैं, तो ब्राउज़र डेवलपर टूल में नेटवर्क टैब खोलें और कई साइटों पर जाएं। प्रतिक्रिया हैडर कुछ इस तरह दिख सकता है:

 content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm; 

यह facebook.com सामग्री सुरक्षा नीति है। इसे और अधिक पठनीय रूप में परिवर्तित करें:

 content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm; 

यहाँ प्रस्तुत सीएसपी निर्देशों पर विचार करें:

• default-src - स्पष्ट रूप से सेट नहीं की गई सभी चीज़ों को प्रतिबंधित करता है।
• script-src - डाउनलोड करने योग्य स्क्रिप्ट पर प्रतिबंध का परिचय देता है।
• स्टाइल- style-src - लोड की गई स्टाइल शीट पर प्रतिबंध लगाता है।
• connect-src - उन URL पर प्रतिबंध लगाता है जिनसे संसाधन स्क्रिप्टिंग इंटरफेस, जैसे कि, XHR , ajax , और इसी तरह का उपयोग करके लोड किए जा सकते हैं।

ध्यान दें, वास्तव में, ऐसे कई निर्देश हैं। ब्राउज़र CSP हेडर पढ़ता है और लोड की गई HTML फ़ाइल के भीतर उचित नियम लागू करता है। उचित रूप से कॉन्फ़िगर किए गए निर्देश केवल उन कार्यों को अनुमति देते हैं जो पृष्ठ के सही संचालन के लिए आवश्यक हैं।

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

▍HTTPS

निश्चित रूप से आपने HTTPS (HTTP Secure) के बारे में सुना है। शायद आप कुछ इस तरह से आए हैं: "अगर मैं सिर्फ साइट पर गेम खेलता हूं तो मुझे HTTPS के बारे में चिंता क्यों करनी चाहिए?" या, शायद, आप निम्नलिखित विचार के साथ आए: “यदि आपके पास HTTPS नहीं है, तो यह सिर्फ पागल है। यार्ड में 2018 वर्ष! किसी को भी विश्वास नहीं है जो कहते हैं कि HTTPS के साथ विवादित हो सकता है।

आपने सुना होगा कि क्रोम अब एचटीटीपीएस का उपयोग नहीं करने पर साइट को असुरक्षित के रूप में चिह्नित करता है।

HTTPS और HTTP के बीच मुख्य अंतर यह है कि, HTTPS के माध्यम से डेटा संचारित करते समय, उन्हें एन्क्रिप्ट किया जाता है, लेकिन HTTP के माध्यम से प्रसारित करते समय, वे नहीं होते हैं।

मूल्यवान डेटा स्थानांतरित करते समय यह ध्यान देने योग्य क्यों है? बात यह है कि जब एक असुरक्षित संचार चैनल के माध्यम से डेटा एक्सचेंज का आयोजन किया जाता है, तो MITM हमले की संभावना है (मैन इन द मिडिल, एक मध्यस्थ हमला, या मध्य हमले में एक आदमी)।

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

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

▍HSTS

HSTS तकनीक (HTTP स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी, HTTPS प्रोटोकॉल के माध्यम से एक सुरक्षित कनेक्शन के जबरन सक्रियण का तंत्र) काफी सरल है। एक उदाहरण के रूप में, फिर से संबंधित फेसबुक हेडर पर विचार करें:

 strict-transport-security: max-age=15552000; preload 

आइए इसका विश्लेषण करें:

• max-age वह समय निर्धारित करता है जिसके दौरान ब्राउज़र को उपयोगकर्ता को HTTPS के माध्यम से वेबसाइट के साथ काम करने के लिए बाध्य करना चाहिए।
• preload - हमारे उद्देश्यों के लिए यह महत्वपूर्ण नहीं है।

यह शीर्षलेख केवल तभी लागू होता है यदि आप HTTPS का उपयोग करके साइट तक पहुँच रहे हैं। यदि आप HTTP के माध्यम से साइट के साथ काम करते हैं, तो यह हेडर अनदेखा है। इसका कारण काफी सरल है: HTTP संचार इतना कमजोर है कि इस तरह के हेडर पर भरोसा नहीं किया जा सकता है।

हम फिर से फेसबुक उदाहरण का उपयोग एचएसटीएस तंत्र की व्यावहारिक उपयोगिता को प्रदर्शित करने के लिए करते हैं। मान लीजिए कि आप पहली बार facebook.com पर लॉग-इन करते हैं और जानते हैं कि HTTPS HTTP से अधिक सुरक्षित है, इसलिए आप इस लिंक का उपयोग करें: https://facebook.com । जब आपका ब्राउज़र HTML कोड प्राप्त करता है, तो यह एक हेडर भी प्राप्त करता है जो ब्राउज़र को बताता है कि यह आपको भविष्य के अनुरोध करते समय HTTPS पर स्विच करने के लिए मजबूर करना चाहिए। एक महीने के बाद, कोई आपको फेसबुक, http://facebook.com एक HTTP लिंक भेजता है, और आप उस पर क्लिक करते हैं। चूंकि माह max-age निर्देश द्वारा निर्दिष्ट 15552000 सेकंड की अवधि से कम है, इसलिए ब्राउज़र संभावित MITM हमले को रोकने के लिए HTTPS के माध्यम से एक अनुरोध भेजेगा।

परिणाम

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

प्रिय पाठकों! क्या आपने वेब डेवलपर्स से असंगत सुरक्षा चिंताओं का सामना किया है?