कॉन्टेंट की सुरक्षा नीति (सीएसपी) से यह पक्का करने में मदद मिलती है कि पेज पर लोड किया गया कॉन्टेंट, साइट के मालिक के लिए भरोसेमंद हो. सीएसपी, क्रॉस-साइट स्क्रिप्टिंग (XSS) के हमलों को कम करते हैं, क्योंकि वे हमलावरों की इंजेक्ट की गई असुरक्षित स्क्रिप्ट को ब्लॉक कर सकते हैं. हालांकि, अगर सीएसपी को ज़रूरत के मुताबिक सख्त नहीं बनाया जाता है, तो उसे आसानी से बायपास किया जा सकता है. ज़्यादा जानकारी के लिए, कॉन्टेंट की सुरक्षा से जुड़ी सख्त नीति (सीएसपी) की मदद से, क्रॉस-साइट स्क्रिप्टिंग (XSS) को कम करना लेख पढ़ें. Lighthouse, मुख्य दस्तावेज़ पर लागू किए गए सीएसपी इकट्ठा करता है. साथ ही, अगर उन्हें बायपास किया जा सकता है, तो सीएसपी एवल्यूएटर से समस्याओं की रिपोर्ट करता है.
ऐसे सीएसपी के लिए ज़रूरी शर्तें जिन्हें बायपास नहीं किया जा सकता
यहां दिए गए तरीके अपनाकर, पक्का करें कि आपके सीएसपी को बायपास न किया जा सके. अगर सीएसपी को बायपास किया जा सकता है, तो Lighthouse गंभीर चेतावनी देगा.
सीएसपी, एक्सएसएस को टारगेट करता है
XSS को टारगेट करने के लिए, सीएसपी में script-src, object-src, और base-uri डायरेक्टिव शामिल होने चाहिए. सीएसपी में सिंटैक्स से जुड़ी गड़बड़ियां भी नहीं होनी चाहिए.
script-src और object-src, किसी पेज को असुरक्षित स्क्रिप्ट और असुरक्षित प्लगिन से सुरक्षित करते हैं. इसके अलावा, default-src का इस्तेमाल script-src और object-src जैसे कई डायरेक्टिव के बजाय, एक बड़ी नीति को कॉन्फ़िगर करने के लिए किया जा सकता है.
base-uri, बिना अनुमति वाले <base> टैग के इंजेक्शन को रोकता है. इन टैग का इस्तेमाल, सभी मिलते-जुलते यूआरएल (जैसे, स्क्रिप्ट) को हमलावर के कंट्रोल वाले डोमेन पर रीडायरेक्ट करने के लिए किया जा सकता है.
सीएसपी, अनुमति वाली सूची को बायपास करने से रोकने के लिए, नॉन्स या हैश का इस्तेमाल करता है
script-src के लिए अनुमति वाली सूची कॉन्फ़िगर करने वाला सीएसपी, इस बात पर भरोसा करता है कि भरोसेमंद डोमेन से मिलने वाले सभी जवाब सुरक्षित हैं और उन्हें स्क्रिप्ट के तौर पर चलाया जा सकता है. हालांकि, यह धारणा आधुनिक ऐप्लिकेशन के लिए सही नहीं है. JSONP इंटरफ़ेस और AngularJS लाइब्रेरी की कॉपी होस्ट करने जैसे कुछ सामान्य और नुकसान न पहुंचाने वाले पैटर्न की मदद से, हमलावर सीएसपी के दायरे से बाहर निकल सकते हैं.
असल में, ऐप्लिकेशन बनाने वाले लोगों को यह पता नहीं चलता कि अनुमति वाली script-src ज़्यादातर सूचियों को XSS बग की मदद से, हमलावर आसानी से गच्चा दे सकता है. साथ ही, स्क्रिप्ट इंजेक्शन से सुरक्षा की बहुत कम सुविधा मिलती है. इसके उलट, नॉन्स-आधारित और हैश-आधारित तरीके में इन समस्याओं का सामना नहीं करना पड़ता. साथ ही, इनसे ज़्यादा सुरक्षित नीति को अपनाना और उसे बनाए रखना आसान हो जाता है.
उदाहरण के लिए, यह कोड किसी भरोसेमंद डोमेन पर होस्ट किए गए JSONP एंडपॉइंट का इस्तेमाल करके, हमलावर की कंट्रोल वाली स्क्रिप्ट को इंजेक्ट करता है:
सीएसपी:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
सीएसपी को नॉन्स या हैश का इस्तेमाल करके, स्क्रिप्ट को अलग-अलग अनुमति देनी चाहिए. साथ ही, अनुमति वाली सूची के बजाय 'strict-dynamic' का इस्तेमाल करना चाहिए, ताकि उसे बायपास न किया जा सके.
सुरक्षित सीएसपी के लिए अन्य सुझाव
ज़्यादा सुरक्षा और काम करने के लिए, यहां दिए गए तरीके अपनाएं. अगर सीएसपी किसी सुझाव का पालन नहीं करता है, तो Lighthouse, 'मध्यम' गंभीरता वाली चेतावनी देगा.
सीएसपी रिपोर्टिंग कॉन्फ़िगर करना
रिपोर्टिंग डेस्टिनेशन कॉन्फ़िगर करने से, किसी भी तरह की गड़बड़ी को मॉनिटर करने में मदद मिलेगी. report-uri या report-to डायरेक्टिव का इस्तेमाल करके, रिपोर्टिंग डेस्टिनेशन सेट किया जा सकता है. फ़िलहाल, report-to सभी आधुनिक ब्राउज़र पर काम नहीं करता. इसलिए, हमारा सुझाव है कि आप दोनों का इस्तेमाल करें या सिर्फ़ report-uri का इस्तेमाल करें.
अगर कोई कॉन्टेंट सीएसपी का उल्लंघन करता है, तो ब्राउज़र कॉन्फ़िगर किए गए डेस्टिनेशन को एक रिपोर्ट भेजेगा. पक्का करें कि आपने इस डेस्टिनेशन पर, इन रिपोर्ट को मैनेज करने के लिए कोई ऐप्लिकेशन कॉन्फ़िगर किया हो.
एचटीटीपी हेडर में सीएसपी की जानकारी देना
सीएसपी को मेटा टैग में इस तरह से तय किया जा सकता है:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
हालांकि, अगर हो पाए, तो आपको एचटीटीपी रिस्पॉन्स हेडर में CSP की जानकारी देनी चाहिए. मेटा टैग से पहले इंजेक्शन करने पर, सीएसपी को बायपास कर दिया जाएगा. इसके अलावा, मेटा टैग के सीएसपी में frame-ancestors, sandbox, और रिपोर्टिंग का इस्तेमाल नहीं किया जा सकता.
पक्का करें कि CSP, पुराने सिस्टम के साथ काम करता हो
सभी ब्राउज़र, सीएसपी नॉन्स/हैश के साथ काम नहीं करते. इसलिए, हमारा सुझाव है कि आप unsafe-inline को फ़ॉलबैक के तौर पर जोड़ें, ताकि नीति का पालन न करने वाले ब्राउज़र पर भी यह काम कर सके. अगर ब्राउज़र में नॉन्स/हैश की सुविधा काम करती है, तो unsafe-inline को अनदेखा कर दिया जाएगा.
इसी तरह, strict-dynamic सभी ब्राउज़र पर काम नहीं करता. हमारा सुझाव है कि आप नीति का पालन न करने वाले ब्राउज़र के लिए, फ़ॉलबैक के तौर पर अनुमति वाली सूची सेट करें. strict-dynamic के साथ काम करने वाले ब्राउज़र में, अनुमति वाली सूची को अनदेखा कर दिया जाएगा.
सख्त सीएसपी बनाने का तरीका
यहां नॉन्स-आधारित नीति के साथ, सख्त सीएसपी का इस्तेमाल करने का उदाहरण दिया गया है.
सीएसपी:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123, हर बार पेज लोड होने पर सर्वर-साइड से जनरेट की गई कोई भी base64 स्ट्रिंग होगी. नॉन्स और strict-dynamic की वजह से, मॉडर्न ब्राउज़र में unsafe-inline और https: को अनदेखा कर दिया जाता है. स्ट्रिक्ट सीएसपी को अपनाने के बारे में ज़्यादा जानने के लिए, स्ट्रिक्ट सीएसपी की गाइड देखें.
Lighthouse और CSP Evaluator का इस्तेमाल करके, सीएसपी को संभावित तरीके से बायपास किए जाने की जांच की जा सकती है. अगर आपको मौजूदा पेजों को ब्रेक किए बिना, किसी नए सीएसपी की जांच करनी है, तो हेडर के नाम के तौर पर Content-Security-Policy-Report-Only का इस्तेमाल करके, सीएसपी को सिर्फ़ रिपोर्ट मोड में तय करें. इससे, report-to और report-uri के साथ कॉन्फ़िगर किए गए सभी रिपोर्टिंग डेस्टिनेशन पर, सीएसपी के उल्लंघनों की जानकारी भेजी जाएगी. हालांकि, इससे सीएसपी लागू नहीं होगा.