आप जैसे पाठक MUO का समर्थन करने में मदद करते हैं। जब आप हमारी साइट पर लिंक का उपयोग करके खरीदारी करते हैं, तो हम संबद्ध कमीशन अर्जित कर सकते हैं।
जब आप किसी वेबसाइट पर जाना चाहते हैं, तो आपके द्वारा उपयोग किया जाने वाला इंटरनेट ब्राउज़र उस साइट से कुछ डेटा प्राप्त करता है। नतीजतन, आपके डिवाइस और वेबसाइट के बीच एक संवाद होता है। यह HTTP नामक प्रोटोकॉल के साथ होता है। इस बातचीत में दखल देकर सुरक्षा के कुछ अतिरिक्त उपाय किए जा सकते हैं।
यदि आप एक वेबसाइट चला रहे हैं या एक वेब डेवलपर के रूप में करियर बनाने का लक्ष्य बना रहे हैं, तो HTTP सुरक्षा हेडर आपके लिए अमूल्य हैं, क्योंकि वे उपयोगकर्ता और वेबसाइट दोनों की सुरक्षा में सक्रिय भूमिका निभाते हैं।
HTTP सख्त-परिवहन-सुरक्षा (HSTS) क्या है?
HTTP सख्त परिवहन सुरक्षा (HSTS) उपयोगकर्ताओं को उनके ब्राउज़र में किए जाने वाले हर अनुरोध के लिए HTTPS का उपयोग करने के लिए बाध्य करती है। डाउनग्रेड जैसे साइबर हमलों से निपटने और सभी ट्रैफ़िक की सुरक्षा सुनिश्चित करने का यह एक ठोस तरीका है।
HSTS को सक्रिय करना बहुत आसान है। क्लाइंट और सर्वर के बीच संवाद पर विचार करें। जब आप अपने ब्राउज़र के माध्यम से किसी साइट तक पहुँचने का प्रयास करते हैं, तो आप ग्राहक होते हैं। आप जिस साइट को खोलना चाहते हैं, वह सर्वर पर निर्भर करती है। आपका लक्ष्य सर्वर को बताना है, "मैं इस साइट को खोलना चाहता हूं"। यह एक रिक्वेस्ट ऑपरेशन है। दूसरी ओर, यदि आप वांछित शर्तों को पूरा करते हैं तो सर्वर आपको साइट पर निर्देशित करता है।
इस नमूना HTTP हैडर फ़्लैग के संबंध में इसे ध्यान में रखें:
सख्त-परिवहन-सुरक्षा: अधिकतम आयु = 16070200;
जब आप इस ध्वज को HTTP प्रतिसाद की शीर्ष लेख जानकारी में जोड़ते हैं, तो सभी उपयोगकर्ता-जनित अनुरोध HTTPS बन जाएंगे। उपयोगकर्ता यहां जो कुछ भी लिखता है, ब्राउज़र स्वचालित रूप से HTTPS के रूप में प्रोटोकॉल का मूल्यांकन करेगा और एक सुरक्षित कनेक्शन स्थापित करेगा।
एचएसटीएस का उपयोग कैसे करें
कोड परत में यह सभी HTTP शीर्ष लेख जानकारी जोड़ने के बजाय, आप इसे Apache, IIS, Nginx, Tomcat, और अन्य वेब सर्वर अनुप्रयोगों पर कर सकते हैं।
अपाचे में HSTS को सक्षम करने के लिए:
लोड मॉड्यूल हेडर_मॉड्यूल मॉड्यूल/mod_headers.so
<वर्चुअलहोस्ट *: 443>
हैडर हमेशा तय करनाकठोर-परिवहन-सुरक्षा "अधिकतम आयु = 2592000; उपडोमेन शामिल करें"
</VirtualHost>
Nginx में HSTS को सक्षम करने के लिए:
add_header सख्त-परिवहन-सुरक्षा अधिकतम-आयु = 2592000; उपडोमेन शामिल करें
IIS web.config के साथ HSTS को सक्षम करने के लिए:
<system.webServer>
<httpProtocol>
<कस्टम हेडर>
<नाम जोड़ें ="सख्त-परिवहन-सुरक्षा" मूल्य ="अधिकतम आयु = 63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
क्लाउडफ्लेयर यूजर्स के लिए
क्लाउडफ्लेयर अपनी कीलेस एसएसएल सेवा के साथ सभी के लिए मुफ्त एचटीटीपीएस सेवा प्रदान करता है; HSTS प्रीलोड के लिए आवेदन करने से पहले, आपको पता होना चाहिए कि आपका प्रमाणपत्र आपका नहीं है। बहुत सी साइटें एसएसएल प्रमाणपत्रों का उपयोग करती हैं क्योंकि वे डेटा को सुरक्षित रखने का आसान तरीका हैं.
हालाँकि, अब क्लाउडफ्लेयर एचएसटीएस सुविधा का समर्थन करता है. आप वेब सर्वर पर कॉन्फ़िगरेशन के साथ संघर्ष किए बिना क्लाउडफ्लेयर वेब इंटरफेस के माध्यम से प्रीलोड सहित सभी एचएसटीएस सुविधाओं को सक्रिय कर सकते हैं।
एक्स-फ़्रेम-विकल्प क्या है?
X-Frame-Options सभी आधुनिक ब्राउज़रों द्वारा समर्थित एक सुरक्षा हैडर है। X-Frame-Options का उद्देश्य क्लिकजैकिंग जैसी क्लिक चोरी से बचाव करना है। जैसा कि नाम से पता चलता है, यह एक कमजोर इनलाइन फ्रेम के काम करने के बारे में है, जिसे आईफ्रेम भी कहा जाता है। ये उस साइट के तत्व हैं जो "पैरेंट" साइट के भीतर एक अन्य HTML पृष्ठ एम्बेड करते हैं, ताकि आप अपनी साइट पर अन्य स्रोतों से सामग्री का उपयोग कर सकें। लेकिन हमलावर अपने नियंत्रण में iframes का उपयोग करते हैं ताकि उपयोगकर्ता उन कार्यों को कर सकें जो वे नहीं करना चाहते हैं।
इस कारण से, आपको हमलावरों को साइट पर iframes खोजने से रोकने की आवश्यकता है।
एक्स-फ्रेम-विकल्प का उपयोग कहाँ और कैसे करें?
X-Frame-Options क्या करता है, कुछ डेवलपर JavaScript जैसी भाषाओं के साथ ऐसा करने का प्रयास करते हैं। यह पूरी तरह गलत नहीं है। हालाँकि, अभी भी एक जोखिम है क्योंकि कई पहलुओं में लिखे गए कोड पर्याप्त नहीं हैं। इसलिए इस कार्य को आपके द्वारा उपयोग किए जा रहे इंटरनेट ब्राउज़र पर छोड़ना बुद्धिमानी होगी।
हालाँकि, एक डेवलपर के रूप में, X-Frame-Options के बारे में जानने के लिए तीन पैरामीटर हैं:
- अस्वीकार करना: पृष्ठ को किसी भी iframe में बुलाए जाने से पूरी तरह रोकें.
- सेमोरिगिन: अपने डोमेन के अलावा किसी अन्य डोमेन को iframe में कॉल करने से रोकें.
- अनुमति दें-उरी से: पैरामीटर के रूप में दिए गए URI के iframe कॉल स्वीकार करें। दूसरों को ब्लॉक करें।
यहां ही सेमोरिगिन विशेषता अधिक सामने आती है। क्योंकि जब आप अपने अलग-अलग सबडोमेन में एप्लिकेशन को एक दूसरे के भीतर iframes के साथ कॉल कर सकते हैं, तो आप उन्हें हमलावर के नियंत्रण वाले डोमेन पर कॉल करने से रोक सकते हैं।
यहाँ इसके उदाहरण दिए गए हैं कि आप NGINX, Apache, और IIS के साथ SAMEORIGIN और X-Frame-Options का उपयोग कैसे कर सकते हैं:
Nginx के लिए X-Frame-Options SAMEORIGIN का उपयोग करना:
add_header X-Frame-Options SAMEORIGIN;
Apache के लिए X-Frame-Options SAMEORIGIN का उपयोग करना:
शीर्षलेख हमेशा X-फ़्रेम-विकल्प SAMEORIGIN संलग्न करें
IIS के लिए X-Frame-Options SAMEORIGIN का उपयोग करना:
<httpProtocol>
<कस्टम हेडर>
<नाम जोड़ें ="एक्स फ़्रेम-विकल्पों को" मूल्य ="सेमोरिगिन" />
</customHeaders>
</httpProtocol>
केवल SAMEORIGIN हैडर जोड़ने से ही आपके आगंतुकों को अधिक सुरक्षा मिलेगी।
एक्स-एक्सएसएस-संरक्षण क्या है?
एक्स-एक्सएसएस-प्रोटेक्शन हेडर जानकारी का उपयोग करके उपयोगकर्ता को एक्सएसएस हमलों से बचाया जा सकता है। सबसे पहले, आपको खत्म करने की जरूरत है एक्सएसएस भेद्यताएं आवेदन पक्ष पर। कोड-आधारित सुरक्षा प्रदान करने के बाद, ब्राउज़रों में XSS भेद्यता के खिलाफ आगे के उपाय, यानी X-XSS-प्रोटेक्शन हेडर की आवश्यकता होती है।
एक्स-एक्सएसएस-प्रोटेक्शन का उपयोग कैसे करें
आधुनिक ब्राउज़र एप्लिकेशन-जनित सामग्री को फ़िल्टर करके संभावित XSS पेलोड का पता लगा सकते हैं। एक्स-एक्सएसएस-प्रोटेक्शन हेडर जानकारी के साथ इस सुविधा को सक्रिय करना संभव है।
Nginx में X-XSS-Protection हैडर को सक्षम करने के लिए:
add_header X-Frame-X-XSS-Protection 1;
अपाचे में एक्स-एक्सएसएस-प्रोटेक्शन हेडर को सक्षम करने के लिए:
हैडर हमेशा एक्स-एक्सएसएस-प्रोटेक्शन 1 संलग्न करें
आईआईएस में एक्स-एक्सएसएस-प्रोटेक्शन हेडर को सक्षम करने के लिए:
<httpProtocol>
<कस्टम हेडर>
<नाम जोड़ें ="एक्स-XSS-संरक्षण" मूल्य ="1" />
</customHeaders>
</httpProtocol>
XSS हमले के साथ कोड ब्लॉक को डिफ़ॉल्ट रूप से चलने से रोकने के लिए, आप कुछ इस तरह का उपयोग कर सकते हैं:
एक्स-एक्सएसएस-संरक्षण: 1; मोड = ब्लॉक
यदि कोई संभावित खतरनाक स्थिति है और आप सभी सामग्री को प्रदर्शित होने से रोकना चाहते हैं तो यह मामूली परिवर्तन करने की आवश्यकता है।
एक्स-सामग्री-प्रकार-विकल्प क्या है?
वेब एप्लिकेशन द्वारा उन्हें प्रस्तुत की गई सामग्री पर ब्राउज़र MIME टाइप स्नीफिंग नामक एक विश्लेषण करते हैं। उदाहरण के लिए, यदि पीडीएफ फाइल या पीएनजी फाइल तक पहुंच के लिए अनुरोध है, तो HTTP प्रतिक्रिया पर विश्लेषण करने वाले ब्राउज़र फ़ाइल प्रकार का अनुमान लगाते हैं।
जेपीईजी एक्सटेंशन वाली फ़ाइल पर विचार करें लेकिन वास्तव में टेक्स्ट/एचटीएमएल सामग्री है। एक्सटेंशन का उपयोग करने और अपलोड मॉड्यूल में सुरक्षा पास करने के बाद, फ़ाइल सफलतापूर्वक अपलोड हो जाती है। अपलोड की गई फ़ाइल को URL के माध्यम से कॉल किया जाता है और परिणामस्वरूप MIME प्रकार स्नीफिंग पाठ/HTML लौटाता है। यह सामग्री को HTML के रूप में प्रस्तुत करता है। तभी XSS भेद्यता होती है।
इसलिए आपको ब्राउज़रों को MIME टाइप स्नीफिंग द्वारा सामग्री पर निर्णय लेने से रोकने की आवश्यकता है। ऐसा करने के लिए, आप nosniff का उपयोग कर सकते हैं।
Nginx के लिए X-Content-Type-Options हैडर:
add_header एक्स-सामग्री-प्रकार-विकल्प जानकारी;
अपाचे के लिए एक्स-कंटेंट-टाइप-ऑप्शंस हेडर:
हैडर हमेशा एक्स-कंटेंट-टाइप-ऑप्शन नॉटिफ
आईआईएस के लिए एक्स-सामग्री-प्रकार-विकल्प शीर्षलेख:
<httpProtocol>
<कस्टम हेडर>
<नाम जोड़ें ="एक्स-सामग्री-प्रकार-विकल्प" मूल्य ="nosniff" />
</customHeaders>
</httpProtocol>
HttpOnly कुकी फ़्लैग क्या है?
वेब एप्लिकेशन सत्र आईडी के माध्यम से उपयोगकर्ताओं के सत्र को ट्रैक करते हैं। ब्राउज़र इसे संग्रहीत करेगा और स्वचालित रूप से इसे कुकी के दायरे में प्रत्येक HTTP अनुरोध में जोड़ देगा।
यह संभव है प्रयोजनों के लिए कुकीज़ का उपयोग करने के लिए हालाँकि, सत्र कुंजी के हस्तांतरण के अलावा। हैकर्स उपरोक्त XSS भेद्यता या क्रॉस-साइट अनुरोध जालसाजी (CSRF) हमले के माध्यम से उपयोगकर्ता डेटा का पता लगा सकते हैं। तो सुरक्षा की दृष्टि से कौन सी कुकीज़ सबसे महत्वपूर्ण हैं?
उदाहरण के तौर पर आप छवि गैलरी में आपके द्वारा क्लिक की गई अंतिम छवि में निहित जानकारी पर विचार कर सकते हैं। इस तरह, HTTP ट्रैफ़िक कम होता है और लोड का एक हिस्सा क्लाइंट-साइड स्क्रिप्टिंग के साथ उपयोगकर्ता के इंटरनेट ब्राउज़र द्वारा हल किया जा सकता है।
वह है वहां केवल Http अंदर आता है। नीचे एक उदाहरण दिया गया है कि कुकी असाइनमेंट कैसा होना चाहिए:
तय करना-कुकी: उपयोगकर्ता=t=cdabe8a1c2153d726; पथ = /; केवल Http
में भेजे गए HttpOnly मान पर ध्यान दें सेट-कुकी कार्यवाही। ब्राउज़र इसे देखेगा और कुकी के माध्यम से एक्सेस किए जाने पर HttpOnly फ़्लैग वाले मानों को संसाधित नहीं करेगा दस्तावेज़.कुकी चर। सेट-कुकी प्रक्रिया में प्रयुक्त एक अन्य ध्वज सुरक्षित ध्वज है। यह इंगित करता है कि कुकी मान केवल HTTPS अनुरोधों के लिए हेडर में जोड़ा जाएगा। ई-कॉमर्स साइटें आमतौर पर इसका उपयोग करती हैं क्योंकि वे नेटवर्क ट्रैफ़िक को कम करना और प्रदर्शन को बढ़ाना चाहती हैं।
इस पद्धति का उपयोग करके, आप उपयोगकर्ता के महत्वपूर्ण डेटा जैसे उपयोगकर्ता नाम, पासवर्ड और क्रेडिट कार्ड की जानकारी को छुपा सकते हैं। लेकिन एक समस्या है। लॉगिन प्रक्रिया को पूरा करने वाले उपयोगकर्ताओं को सुरक्षित फ़्लैग के बिना एक कुकी मान असाइन किया जाता है। उपयोगकर्ता के पास सत्र कुंजी हो सकती है जब वे गैर-HTTPS लिंक के लिए HTTP अनुरोध करते हैं। सुरक्षित ध्वज जोड़ना आसान है:
तय करना-कुकी: उपयोगकर्ता=t=cdabe8a1c2153d726; पथ = /; सुरक्षित
आपको केवल Http का उपयोग कब नहीं करना चाहिए? यदि आप जावास्क्रिप्ट पर भरोसा करते हैं, तो आपको सावधान रहना चाहिए क्योंकि इससे आपकी साइट कम सुरक्षित हो सकती है।
व्यापक वेब सुरक्षा के लिए छोटे कदम काम करते हैं
वेब एप्लिकेशन की सुरक्षा बढ़ाने के लिए आपको उन्नत सॉफ़्टवेयर और सर्वर ज्ञान की आवश्यकता नहीं है। केवल कुछ पंक्तियों को बदलकर आप कुछ गंभीर आक्रमणों को रोक सकते हैं। बेशक, यह काफी नहीं है। हालाँकि, यह वेबसाइट सुरक्षा के लिए एक छोटा लेकिन प्रभावी कदम है। ज्ञान सबसे अच्छा निवारक है, इसलिए HTTPS स्थानांतरण के दौरान डेटा की सुरक्षा कैसे करता है, इसकी सूक्ष्म बारीकियों को जानना भी उपयोगी है।