इस पेज का अनुवाद Cloud Translation API से किया गया है.

कॉन्टेंट की सुरक्षा के बारे में नीति

Mike West

Joe Medley

वेब का सुरक्षा मॉडल एक ही ऑरिजिन से जुड़ी नीति. कोड करें https://mybank.com से के पास केवल https://mybank.com की ऐक्सेस होनी चाहिए https://evil.example.com को डेटा का ऐक्सेस कभी नहीं दिया जाना चाहिए. हर ऑरिजिन को वेब से अलग रखा जाता है, ताकि डेवलपर एक सैंडबॉक्स बनाया जा सकता है, जिसमें जिसे बनाया और खेला जा सके. सैद्धांतिक रूप से, यह पूरी तरह से बहुत ही शानदार है. तय सीमा में तो हैकर ने सिस्टम को पलटने के लिए चतुर तरीके ढूंढ लिए हैं.

क्रॉस-साइट स्क्रिप्टिंग (XSS) हमले, उदाहरण के लिए, किसी साइट को धोखे से सही कॉन्टेंट के साथ नुकसान पहुंचाने वाला कोड डिलीवर करना. यह एक बहुत बड़ा क्योंकि ब्राउज़र किसी पेज पर दिखने वाले सारे कोड पर उस पेज के सुरक्षा स्रोत का कानूनी रूप से हिस्सा हो. कॉन्टेंट बनाने XSS चीट शीट यह उन पुराने तरीकों का क्रॉस-सेक्शन है जिनका इस्तेमाल कोई हमलावर कर सकता है ऐसा करने के लिए, मैलवेयर वाले कोड को इंजेक्ट किया जा सकता है. अगर हमलावर कोई भी कोड इंजेक्ट करता है, लेकिन यह काफ़ी गेम हो गया है: उपयोगकर्ता के सेशन का डेटा और वह जानकारी जिसे गोपनीय रखा जाना चाहिए, को हैक कर लिया जाता है और दोस्तों. अगर मुमकिन हो, तो हम उसे ठीक करना चाहेंगे.

इस खास जानकारी में सुरक्षा के ऐसे उपायों के बारे में बताया गया है जो खतरे को काफ़ी कम कर सकता है और मॉडर्न ब्राउज़र में XSS हमलों का असर: कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी).

कम शब्दों में कहा जाए तो

अनुमति वाले डोमेन की सूची का इस्तेमाल करके, क्लाइंट को बताएं कि आपके कारोबार के लिए किस तरह के विज्ञापन दिखाए जा सकते हैं और किस तरह के नहीं.
जानें कि कौनसे डायरेक्टिव उपलब्ध हैं.
उनके द्वारा लिए जाने वाले कीवर्ड जानें.
इनलाइन कोड और eval() को नुकसान पहुंचाने वाला माना जाता है.
नीति के उल्लंघन लागू करने से पहले अपने सर्वर को उनकी रिपोर्ट करें.

सोर्स की अनुमति वाली सूची

XSS हमलों का फ़ायदा पाने वाली समस्या की वजह से, ब्राउज़र अलग-अलग तरीकों से पहचान नहीं कर पाता स्क्रिप्ट के बीच में, जो आपके ऐप्लिकेशन का हिस्सा है और किसी तीसरे पक्ष ने नुकसान पहुंचाने के मकसद से डाला हो. उदाहरण के लिए, खोज बॉक्स में इस पेज के निचले हिस्से में, यहां से कोड को लोड और लागू किया जाता है इस पेज के ऑरिजिन के हिसाब से https://apis.google.com/js/plusone.js. बुध उस कोड पर विश्वास करें, लेकिन हम यह अपेक्षा नहीं कर सकते कि ब्राउज़र वह कोड apis.google.com का कोड शानदार है, जबकि apis.evil.example.com से मिला कोड शायद नहीं. ब्राउज़र, किसी भी पेज के कोड को आसानी से डाउनलोड और एक्ज़ीक्यूट करता है सोर्स पर ध्यान दिए बिना.

सर्वर से मिलने वाली हर चीज़ पर आंख बंद करके भरोसा करने के बजाय, सीएसपी Content-Security-Policy एचटीटीपी हेडर. इसकी मदद से, अनुमति वाली सूची बनाई जा सकती है भरोसेमंद कॉन्टेंट के सोर्स के बारे में बताता है. साथ ही, ब्राउज़र को सिर्फ़ एक्ज़ीक्यूट या रेंडर करने के लिए निर्देश देता है संसाधन भी मिलते हैं. भले ही, कोई हमलावर छेद करने के लिए उसे ढूंढ लेता है अगर स्क्रिप्ट इंजेक्ट की जाती है, तो स्क्रिप्ट, अनुमति वाली सूची से मैच नहीं करेगी. इसलिए, लागू किया गया.

हमें भरोसा है कि apis.google.com, मान्य कोड डिलीवर करेगा. साथ ही, हमें खुद पर भरोसा है आइए एक ऐसी नीति परिभाषित करें, जो स्क्रिप्ट को सिर्फ़ तब ही निष्पादित करने की अनुमति देती है, जब सोर्स इन दो में से किसी एक सोर्स से आता है:

Content-Security-Policy: script-src 'self' https://apis.google.com

आसान है, है न? जैसा कि आपने अनुमान लगा लिया होगा, script-src एक ऐसा डायरेक्टिव है जो किसी खास पेज के लिए, स्क्रिप्ट से जुड़े खास अधिकारों के सेट को कंट्रोल करता है. हमने बताया है 'self' स्क्रिप्ट के एक मान्य स्रोत के रूप में और https://apis.google.com कोई दूसरा. ब्राउज़र, वेब ब्राउज़र से JavaScript को सावधानी से डाउनलोड और एक्ज़ीक्यूट करता है apis.google.com ओवर एचटीटीपीएस और मौजूदा पेज के ऑरिजिन से भी देखे जा सकते हैं.

कंसोल में गड़बड़ी: स्क्रिप्ट 'http://evil.example.com/evil.js' को लोड करने से मना किया गया क्योंकि यह कॉन्टेंट की सुरक्षा के बारे में बनी इस नीति का उल्लंघन करता है: script-src 'self' https://apis.google.com

यह नीति तय होने पर, ब्राउज़र इसके बजाय गड़बड़ी की सूचना देता है किसी दूसरे सोर्स से स्क्रिप्ट लोड हो रही है. जब एक चालाक हमलावर हमला कर लेता है अपनी साइट में कोड इंजेक्ट करते हैं, तो वे हेडर के साथ आपको गड़बड़ी का मैसेज भेजेंगे उम्मीद से ज़्यादा सफलता नहीं मिली.

यह नीति कई तरह के संसाधनों पर लागू होती है

वैसे तो स्क्रिप्ट संसाधन सबसे ज़्यादा सुरक्षा जोखिम होते हैं, लेकिन सीएसपी एक बेहतर नीति वाले ऐसे डायरेक्टिव का सेट जो संसाधनों पर पूरा कंट्रोल देते हैं कि पेज को लोड होने की अनुमति है या नहीं. आप script-src को पहले ही देख चुके हैं. इसलिए, साफ़ तौर पर बताया जाना चाहिए.

चलिए, संसाधन से जुड़े बाकी डायरेक्टिव के बारे में फटाफट जानते हैं. नीचे दी गई सूची लेवल 2 तक डायरेक्टिव की स्थिति दिखाता है. लेवल 3 स्पेसिफ़िकेशन को पब्लिश कर दिया गया है, लेकिन इसे बड़े पैमाने पर लागू नहीं किया गया है ब्राउज़र खोलें.

base-uri उन यूआरएल पर पाबंदी लगाता है जो किसी पेज के <base> एलिमेंट में दिख सकते हैं.
child-src, कर्मचारियों और एम्बेड किए गए फ़्रेम के कॉन्टेंट के यूआरएल की सूची बनाता है. इसके लिए उदाहरण: child-src https://youtube.com से वीडियो एम्बेड करने की सुविधा चालू हो जाएगी YouTube है, लेकिन दूसरे ऑरिजिन से नहीं.
connect-src उन ऑरिजिन को सीमित करता है जिनसे कनेक्ट किया जा सकता है (XHR, WebSockets और EventSource).
font-src उन ऑरिजिन के बारे में बताता है जो वेब फ़ॉन्ट इस्तेमाल कर सकते हैं. Google की वेब फ़ॉन्ट को font-src https://themes.googleusercontent.com के ज़रिए चालू किया जा सकता है.
form-action में <form> टैग से सबमिट किए जाने वाले मान्य एंडपॉइंट की सूची दी गई है.
frame-ancestors ऐसे सोर्स के बारे में बताता है जो मौजूदा पेज को एम्बेड कर सकते हैं. यह डायरेक्टिव <frame>, <iframe>, <embed>, और <applet> टैग पर लागू होता है. यह डायरेक्टिव <meta> टैग में इस्तेमाल नहीं किया जा सकता. यह सिर्फ़ बिना एचटीएमएल वाले टैग पर लागू होता है संसाधन.
frame-src को लेवल 2 में बंद कर दिया गया था, लेकिन लेवल 3 में इसे पहले जैसा कर दिया गया है. अगर नहीं तो यह पहले की तरह child-src पर ही वापस आ जाएगा.
img-src उन ऑरिजिन के बारे में बताता है जहां से इमेज लोड की जा सकती हैं.
media-src उन ऑरिजिन पर पाबंदी लगाता है जिन्हें वीडियो और ऑडियो डिलीवर करने की अनुमति है.
object-src, Flash और अन्य प्लगिन को कंट्रोल करने की अनुमति देता है.
plugin-types किसी पेज पर लागू होने वाले प्लगिन के टाइप को सीमित करता है.
report-uri एक ऐसे यूआरएल के बारे में बताता है जिसमें ब्राउज़र तब रिपोर्ट भेजेगा, जब कोई कॉन्टेंट की सुरक्षा से जुड़ी नीति का उल्लंघन हुआ है. <meta> में इस डायरेक्टिव का इस्तेमाल नहीं किया जा सकता टैग.
स्टाइलशीट के लिए, style-src script-src का हिस्सा है.
upgrade-insecure-requests, उपयोगकर्ता एजेंट को यूआरएल स्कीम को फिर से लिखने का निर्देश देता है, एचटीटीपी को एचटीटीपीएस में बदलने के बारे में ज़्यादा जानें. यह डायरेक्टिव ऐसी वेबसाइटों के लिए है जिनमें बड़ी संख्या में पुराने यूआरएल को फिर से लिखना होगा.
worker-src एक सीएसपी लेवल 3 डायरेक्टिव है, जो उन यूआरएल को प्रतिबंधित करता है जो को एक वर्कर, शेयर्ड वर्कर या सर्विस वर्कर के तौर पर लोड किया जा सकता है. जुलाई 2017 तक, डायरेक्टिव में सीमित तौर पर लागू करने की कोशिश करते हैं.

डिफ़ॉल्ट रूप से, डायरेक्टिव बड़े पैमाने पर खुले होते हैं. अगर आप डायरेक्टिव के तौर पर, font-src को मान लें, तो वह डायरेक्टिव डिफ़ॉल्ट रूप से इस तरह काम करता है: हालांकि, आपने * को एक मान्य सोर्स के तौर पर दिखाया था (उदाहरण के लिए, कहीं भी, बिना किसी पाबंदी के).

आप default-src तय करके, इस डिफ़ॉल्ट तरीके को बदल सकते हैं डायरेक्टिव. यह डायरेक्टिव जिन्हें आप कुछ भी नहीं बताते हैं. आम तौर पर, यह ऐसे किसी भी निर्देश पर लागू होता है जो -src से खत्म होता है. अगर default-src को https://example.com पर सेट किया जाता है और ऐसा नहीं किया जा सकता font-src निर्देश का इस्तेमाल किया जाता है, तो आप यहां से फ़ॉन्ट लोड कर सकते हैं https://example.com के अलावा कहीं और नहीं. हमने अपनेscript-src पहले के उदाहरण दिए गए थे, जिसका मतलब है कि इमेज, फ़ॉन्ट वगैरह लोड किए जा सकते हैं किसी भी ऑरिजिन के लिए आज़माएं.

नीचे दिए गए निर्देश, default-src का इस्तेमाल फ़ॉलबैक के तौर पर नहीं करते हैं. याद रखें कि उन्हें सेट न कर पाना, किसी चीज़ को अनुमति देने के समान है.

base-uri
form-action
frame-ancestors
plugin-types
report-uri
sandbox

आप इनमें से कम या ज़्यादा निर्देशों का इस्तेमाल, अपने खास ऐप्लिकेशन के लिए बनाई गई है, जिसमें हर एक को एचटीटीपी हेडर में सेमीकोलन वाले डायरेक्टिव शामिल हों. पक्का करें कि आपने सभी को शामिल किया हो एक निर्देश में किसी खास तरह के ज़रूरी संसाधन शामिल करें. अगर आपने script-src https://host1.com; script-src https://host2.com जैसा कुछ दूसरे डायरेक्टिव को अनदेखा कर दिया जाएगा. ऐसा कुछ दोनों ऑरिजिन को सही तरीके से मान्य के तौर पर सेट करें:

script-src https://host1.com https://host2.com

उदाहरण के लिए, अगर आपके पास कोई ऐसा ऐप्लिकेशन है जो अपने सभी संसाधन कॉन्टेंट डिलीवरी नेटवर्क (जैसे, https://cdn.example.net) और जानें कि के लिए, किसी फ़्रेम किए गए कॉन्टेंट या प्लगिन की ज़रूरत नहीं होती, तो हो सकता है कि आपकी नीति जैसे:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

क्रियान्वयन विवरण

आपको X-WebKit-CSP और X-Content-Security-Policy हेडर अलग-अलग भाषाओं में दिखेंगे ट्यूटोरियल देखें. आगे से, आपको इन प्रीफ़िक्स को अनदेखा करना चाहिए हेडर. आधुनिक ब्राउज़र (IE को छोड़कर) बिना प्रीफ़िक्स वाले ब्राउज़र का इस्तेमाल करते हैं Content-Security-Policy हेडर. आपको इसी हेडर का इस्तेमाल करना चाहिए.

आप चाहे किसी भी हेडर का इस्तेमाल करें, नीति हर पेज के हिसाब से तय होती है: आपको अपनी पसंद के हर जवाब के साथ एचटीटीपी हेडर भेजना होगा सुरक्षित है या नहीं. इससे आपको बहुत सारी सुविधाएं मिलती हैं, ताकि खास पेजों के लिए नीति बनाई गई है. शायद इसका एक सेट आपकी साइट के पृष्ठों में +1 बटन है, जबकि अन्य में नहीं है: तो आप बटन कोड को केवल ज़रूरत होने पर लोड किया जाना चाहिए.

हर डायरेक्टिव में मौजूद सोर्स सूची में ज़रूरत के हिसाब से बदलाव किए जा सकते हैं. आप इसके हिसाब से स्रोत तय कर सकते हैं स्कीम (data:, https:) या सिर्फ़ होस्टनेम से जुड़ी रेंज (example.com, जो उस होस्ट पर किसी भी ऑरिजिन से मैच करता है: कोई भी स्कीम, कोई भी पोर्ट) पूरी तरह क्वालिफ़ाइड यूआरआई (https://example.com:443, जो सिर्फ़ एचटीटीपीएस से मेल खाता हो, लेकिन example.com, और सिर्फ़ पोर्ट 443). वाइल्डकार्ड स्वीकार किए जाते हैं, लेकिन सिर्फ़ स्कीम के तौर पर, पोर्ट या होस्टनेम की सबसे बाईं ओर मौजूद होने पर: *://*.example.com:* example.com के सभी सबडोमेन से मेल खाते हैं (लेकिन खुद example.com से नहीं). इनका इस्तेमाल करके किसी भी पोर्ट पर, किसी भी स्कीम का इस्तेमाल करें.

सोर्स सूची में चार कीवर्ड भी स्वीकार किए जाते हैं:

'none', आपकी उम्मीद के मुताबिक किसी भी चीज़ से मेल नहीं खाता.
'self' मौजूदा ऑरिजिन से मेल खाता है, लेकिन उसके सबडोमेन से नहीं.
'unsafe-inline', इनलाइन JavaScript और सीएसएस को अनुमति देता है. (हम इस बारे में थोड़ा और विस्तार से जानें.)
'unsafe-eval', eval जैसे टेक्स्ट-टू-JavaScript मैकेनिज़्म की अनुमति देता है. (हम इतना ही नहीं.)

इन कीवर्ड के लिए सिंगल कोट ज़रूरी हैं. उदाहरण के लिए, script-src 'self' (कोटेशन के साथ) मौजूदा होस्ट से JavaScript को चलाने की अनुमति देता है; script-src self (कोटेशन के बिना) "self" नाम के सर्वर से JavaScript को चलाने की अनुमति देता है (और न को मौजूदा होस्ट) जैसा भी होता है, जो शायद आपका मतलब नहीं है.

सैंडबॉक्सिंग

इसके बारे में बात करने लायक एक और डायरेक्टिव है: sandbox. बस थोड़ी सी अलग है, क्योंकि यह ऐसी कार्रवाइयों पर प्रतिबंध लगाता है पेज लोड हो सकने वाले संसाधनों के बजाय, पेज लोड होने में ज़्यादा समय ले सकता है. अगर sandbox डायरेक्टिव मौजूद है. पेज को लोड होते हुए माना जाता है इसे <iframe> में, sandbox एट्रिब्यूट के साथ शामिल किया गया है. ऐसे कई पेज पर असर: पेज को एक यूनीक ऑरिजिन पर ले जाना और पेज को खुलने से रोकना सबमिशन वगैरह. यह लेख में दी गई जानकारी से थोड़ी दूर है, लेकिन आपको सही सैंडबॉक्सिंग एट्रिब्यूट के बारे में पूरी जानकारी यहां मिल सकती है "सैंडबॉक्सिंग" सेक्शन में बताया गया है.

मेटा टैग

सीएसपी का पसंदीदा डिलीवरी तरीका एक एचटीटीपी हेडर है. हालांकि, यह मददगार साबित हो सकता है और का इस्तेमाल, सीधे मार्कअप में किसी पेज पर नीति सेट करने के लिए करें. इसके साथ <meta> टैग का इस्तेमाल करें एक http-equiv एट्रिब्यूट:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>

इसे frame-ancestors, report-uri या sandbox के लिए इस्तेमाल नहीं किया जा सकता.

इनलाइन कोड को नुकसान पहुंचाने वाला माना जाता है

यह साफ़ होना चाहिए कि सीएसपी, अनुमति वाले ऑरिजिन पर आधारित होता है, क्योंकि यह यह साफ़ तौर पर ब्राउज़र को यह निर्देश देने का तरीका बताता है कि वह संसाधनों के खास सेट को कैसे मैनेज करे स्वीकार नहीं करना चाहिए और बाकी को अस्वीकार करना चाहिए. ऑरिजिन के मुताबिक अनुमति वाली सूची में ये काम नहीं किए जाते, हालांकि, XSS हमलों से पैदा हुए सबसे बड़े खतरे को हल कर दें: इनलाइन स्क्रिप्ट इंजेक्शन. क्या कोई हमलावर ऐसा स्क्रिप्ट टैग डाल सकता है जिसमें सीधे तौर पर कुछ नुकसान पहुंचाने वाला कॉन्टेंट शामिल हो पेलोड (<script>sendMyDataToEvilDotCom();</script>), ब्राउज़र में इसे किसी वैध इनलाइन स्क्रिप्ट टैग. सीएसपी, इनलाइन स्क्रिप्ट को बैन करके इस समस्या को हल करता है: यह पक्का करने का यही एक तरीका है.

इस पाबंदी में, सीधे तौर पर script टैग में एम्बेड की गई स्क्रिप्ट के साथ-साथ, इनलाइन इवेंट हैंडलर और javascript: यूआरएल. आपको इसकी सामग्री को स्थानांतरित करना होगा script टैग को किसी बाहरी फ़ाइल में टैग करें और javascript: यूआरएल और <a ... onclick="[JAVASCRIPT]"> को सही addEventListener() कॉल से बदल दें. उदाहरण के लिए, यहां दिए गए जवाबों में बदलाव किया जा सकता है:

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

इससे मिलता-जुलता है:

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

दोबारा लिखे गए कोड के ऐसे कई फ़ायदे हैं जो इनके साथ बेहतर तरीके से काम नहीं करते CSP; यह सबसे सही तरीका है. इससे कोई फ़र्क़ नहीं पड़ता कि आपने सीएसपी का इस्तेमाल कैसे किया है. इनलाइन JavaScript संरचना और व्यवहार को ठीक उसी तरह मिलाता है जैसा आपको नहीं करना चाहिए. बाहरी रिसॉर्स, ब्राउज़र के लिए कैश मेमोरी में सेव करना आसान बनाते हैं. ये रिसॉर्स, ब्राउज़र के लिए समझने में आसान होते हैं डेवलपर के साथ मिलकर काम कर सकते हैं. इससे बेहतर लिखें कोड का उपयोग करें.

इनलाइन स्टाइल को इसी तरह से इस्तेमाल किया जाता है: style एट्रिब्यूट और style, दोनों टैग को बाहरी स्टाइलशीट में एक साथ मिला देना चाहिए, ताकि कई तरह के आत्मविश्वास से भरे डेटा बाहर निकाले जाने के ऐसे तरीके जिन्हें सीएसएस चालू करता है.

अगर आपके पास इनलाइन स्क्रिप्ट और स्टाइल होना ज़रूरी है, तो इसे चालू किया जा सकता है script-src या style-src में 'unsafe-inline' को अनुमति वाले सोर्स के तौर पर जोड़कर डायरेक्टिव. नॉन्स या हैश का भी इस्तेमाल किया जा सकता है (नीचे देखें), लेकिन आपको ऐसा नहीं करना चाहिए. इनलाइन स्क्रिप्ट को बंद करना, सीएसपी के लिए सबसे बड़ी सुरक्षा है और इनलाइन शैली को प्रतिबंधित करना आपके ऐप्लिकेशन को उसी तरह सख्त करता है. यह थोड़ा-बहुत सभी कोड को ट्रांसफ़र करने के बाद चीज़ें ठीक से काम करें, यह पक्का करने के लिए पूरी कोशिश करें आउट-ऑफ़-लाइन, लेकिन यह एक समझौता है. इसे बनाने में कोई दिक्कत नहीं है.

अगर आपको इसका इस्तेमाल करना ज़रूरी हो,

सीएसपी लेवल 2, इनलाइन स्क्रिप्ट के लिए पुराने सिस्टम के साथ काम करने की सुविधा देता है. इसकी मदद से, क्रिप्टोग्राफ़िक नॉन्स (नंबर) का इस्तेमाल करके, अनुमति वाली सूची में चुनिंदा इनलाइन स्क्रिप्ट जोड़ें एक बार उपयोग किया जाता है) या हैश होता है. हालांकि यह जटिल हो सकता है, लेकिन यह उपयोगी है चुटकी में.

नॉन्स का इस्तेमाल करने के लिए, अपने स्क्रिप्ट टैग को नॉन्स एट्रिब्यूट दें. इसका मान एक से मेल खाना चाहिए की सूची में शामिल है. उदाहरण के लिए:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

अब, nonce- कीवर्ड में जोड़े गए अपने script-src डायरेक्टिव में नॉन्स जोड़ें.

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

याद रखें कि हर पेज के अनुरोध के लिए नॉन्स को फिर से जनरेट करना होगा और उन्हें अनुमान लगाना मुश्किल होता है.

हैश भी इसी तरह से काम करते हैं. स्क्रिप्ट टैग में कोड जोड़ने के बजाय, स्क्रिप्ट का SHA हैश बनाएं और उसे script-src डायरेक्टिव में जोड़ें. उदाहरण के लिए, मान लें कि आपके पेज में यह शामिल था:

<script>
  alert('Hello, world.');
</script>

आपकी नीति में यह शामिल होगा:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

यहां ध्यान देने के लिए कुछ बातें बताई गई हैं. sha*- प्रीफ़िक्स एल्गोरिदम के बारे में बताता है जो हैश जनरेट करता है. ऊपर दिए गए उदाहरण में, sha256- का इस्तेमाल किया गया है. सीएसपी भी sha384- और sha512- का इस्तेमाल करता है. हैश जनरेट करते समय, इन्हें शामिल न करें <script> टैग. साथ ही, कैपिटल लेटर और खाली सफ़ेद जगह भी मायने रखते हैं, जैसे कि आगे या पीछे पीछे की खाली सफ़ेद जगह.

SHA के हैश जनरेट करने से जुड़ी Google की खोज की मदद से, किसी भी समस्या को हल किया जा सकता है भाषाओं की संख्या. Chrome 40 या इसके बाद के वर्शन का इस्तेमाल करके, DevTools खोलें और पेज को फिर से लोड करें. कंसोल टैब में गड़बड़ी के सही मैसेज दिखेंगे sha256 हैश इस्तेमाल करें.

मूल्यांकन भी करें

भले ही, हमला करने वाला व्यक्ति स्क्रिप्ट को सीधे इंजेक्ट न कर पाए, फिर भी वह उसे धोखा दे सकता है टेक्स्ट को एक्ज़ीक्यूटेबल JavaScript में बदलने के लिए नहीं कर सकते हैं और उन्हें अपनी ओर से लागू करेगा. eval(), नया फ़ंक्शन() , setTimeout([string], ...), और setInterval([string], ...) वे सभी वेक्टर हैं जिनके ज़रिए इंजेक्ट किया जाता है टेक्स्ट में कोई ऐसा काम हो सकता है जो अचानक नुकसान पहुंचाने वाला हो. सीएसपी की डिफ़ॉल्ट सेटिंग इन सभी वेक्टर को पूरी तरह से ब्लॉक कर दिया जाता है.

ऐप्लिकेशन बनाने के आपके तरीके पर, इसका कुछ असर पड़ा है:

भरोसा रखने के बजाय, आपको पहले से मौजूद JSON.parse के ज़रिए JSON को पार्स करना होगा eval. नेटिव JSON से जुड़ी कार्रवाइयां यहां उपलब्ध हैं IE8 के बाद से सभी ब्राउज़र पर और वे पूरी तरह से सुरक्षित है.
फ़िलहाल, जो setTimeout या setInterval कॉल किए जा रहे हैं उन्हें फिर से लिखें का इस्तेमाल करने के लिए, स्ट्रिंग की जगह इनलाइन फ़ंक्शन का इस्तेमाल किया जाता है. उदाहरण के लिए:

setTimeout("document.querySelector('a').style.display = 'none';", 10);

तो बेहतर होगा कि इसे इस तरह लिखा जाए:

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

रनटाइम के दौरान इनलाइन टेंप्लेट बनाने से बचें: कई टेंप्लेट लाइब्रेरी, रनटाइम के दौरान टेंप्लेट जनरेट करने की प्रोसेस को तेज़ करने के लिए, new Function() का इस्तेमाल बेहतर तरीके से करती हैं. यह है यह डाइनैमिक प्रोग्रामिंग का बेहतरीन तरीके से इस्तेमाल करता है. हालांकि, इसमें कुछ जोखिम हो सकता है जिसमें नुकसान पहुंचाने वाले टेक्स्ट का आकलन किया जा रहा हो. कुछ फ़्रेमवर्क, सीएसपी के साथ काम करते हैं, eval की गैर-मौजूदगी में एक मज़बूत पार्सर पर वापस जा सकता है. AngularJS का ng-csp डायरेक्टिव यह एक अच्छा उदाहरण है.

हालांकि, बेहतर विकल्प यह होगा कि टेंप्लेट में प्रीकंपाइलेशन (हैंडलबार यह करता है, उदाहरण के लिए). अपने टेंप्लेट को पहले से कंपाइल करने से, उपयोगकर्ता अनुभव को बेहतर बनाया जा सकता है सबसे तेज़ रनटाइम को लागू करने की क्षमता से ज़्यादा तेज़ है. साथ ही, यह ज़्यादा सुरक्षित भी है. अगर eval और इसके टेक्स्ट-टू-JavaScript ब्रेथन आपके ऐप्लिकेशन के लिए आवश्यक हैं, इसलिए आप इन्हें चालू करने के लिए, script-src में 'unsafe-eval' को अनुमति वाले सोर्स के तौर पर जोड़ें डायरेक्टिव के रूप में काम करता है, लेकिन हम इसके इस्तेमाल का सुझाव नहीं देते. एक्ज़ीक्यूट करने की सुविधा पर रोक लगाना स्ट्रिंग की वजह से किसी हमलावर के लिए बिना अनुमति के साइन इन करना और भी मुश्किल हो जाता है कोड दिखाई दे सकता है.

रिपोर्टिंग

सीएसपी की क्लाइंट-साइड गैर-भरोसेमंद संसाधनों को ब्लॉक करने की क्षमता आपके लिए एक बहुत बड़ी उपलब्धि है हालाँकि, बेहतर रहेगा कि कुछ सूचना न दी जाए सर्वर को वापस भेजा जाता है, ताकि आप अनुमति देने वाली गड़बड़ियों की पहचान करके उन्हें ठीक कर सकें नुकसान पहुंचाने के इरादे से डाला गया है. यहाँ तक, आप ब्राउज़र से किसी जगह के लिए, JSON फ़ॉर्मैट में हुई उल्लंघन की रिपोर्ट को POST पर सेट किया गया report-uri डायरेक्टिव में बताया गया है.

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

वे रिपोर्ट कुछ इस तरह दिखेंगी:

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

इसमें जानकारी का एक अच्छा हिस्सा है जो उल्लंघन की वजह. इसमें वह पेज भी शामिल है जिस पर उल्लंघन हुआ है. हुआ (document-uri), उस पेज का रेफ़रर (ध्यान दें कि एचटीटीपी से हेडर फ़ील्ड है, कुंजी की स्पेलिंग नहीं है), वह संसाधन जिसने पेज की नीति (blocked-uri), जिस निर्देश का उल्लंघन हुआ है (violated-directive) और पेज की पूरी नीति (original-policy) शामिल है.

रिपोर्ट-ओनली

अगर आपने अभी-अभी सीएसपी के साथ काम करना शुरू किया है, तो आपके लिए मौजूदा आपके ऐप्लिकेशन की स्थिति क्या है. पूरे डिप्लॉयमेंट की शुरुआत करने के लिए, ब्राउज़र को मॉनिटर करने के लिए कहा जा सकता है नीतियों के उल्लंघन की शिकायत करना, लेकिन पाबंदियों को लागू न करना. इसके बजाय Content-Security-Policy हेडर भेज रहे हैं, Content-Security-Policy-Report-Only हेडर.

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

'रिपोर्ट-ओनली मोड' में बताई गई नीति से, प्रतिबंधित संसाधनों को ब्लॉक नहीं किया जाएगा. हालांकि, आपकी बताई गई जगह पर उल्लंघन की रिपोर्ट भेजेगा. यहाँ तक कि आप भेजें भी दोनों हेडर इस्तेमाल करके, एक नीति को लागू करके दूसरी नीति को मॉनिटर किया जा सकता है. यह एक बहुत बढ़िया अपने ऐप्लिकेशन के सीएसपी में किए गए बदलावों के असर का आकलन करने का तरीका: चालू करें नीति के उल्लंघन की रिपोर्ट देख सकते हैं, उल्लंघन की रिपोर्ट पर नज़र रख सकते हैं, और ऐसी गड़बड़ियों को ठीक कर सकते हैं बढ़ाओ; जब आप इसके प्रभाव से संतुष्ट हो जाएं, तो नई नीति को लागू करना शुरू करें.

असल दुनिया में उपयोग

CSP 1 का इस्तेमाल Chrome, Safari, और Firefox में किया जा सकता है. हालांकि, इसकी सीमित सुविधाएं उपलब्ध हैं IE 10 में समर्थन करते हैं. आप caniuse.com पर जाकर खास जानकारी देखें. सीएसपी लेवल 2 तब से Chrome में उपलब्ध है वर्शन 40 है. Twitter और Facebook जैसी बड़ी साइटों ने हेडर का इस्तेमाल (Twitter की केस स्टडी को ध्यान से पढ़ा जा सकता है) और स्टैंडर्ड आर्किटेक्चर ताकि डिप्लॉय किए जा सकें.

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

इस्तेमाल का उदाहरण #1: सोशल मीडिया विजेट

Google का +1 बटन इसमें https://apis.google.com की एक स्क्रिप्ट शामिल है और<iframe> https://plusone.google.com. आपके पास एक ऐसी नीति होनी चाहिए जिसमें ये दोनों शामिल हों ऑरिजिन के बारे में ज़्यादा जानें. कम से कम नीति script-src https://apis.google.com; child-src https://plusone.google.com होगी. आपको इनकी ज़रूरत भी पड़ सकती है ताकि यह पक्का किया जा सके कि Google से मिलने वाले JavaScript के स्निपेट को बाहरी JavaScript फ़ाइल का होता है. अगर frame-src का इस्तेमाल करके आपने लेवल 1 के लिए नीति बनाई थी लेवल 2 में, आपको इसे बदलकर child-src करना था. अब इसकी ज़रूरत नहीं है में सीएसपी लेवल 3 में हैं.
Facebook का पसंद करें बटन में, इसे लागू करने के कई विकल्प मौजूद हैं. हमारा सुझाव है कि आप इसका इस्तेमाल जारी रखें <iframe> वर्शन का इस्तेमाल करें, क्योंकि इसे आपकी साइट के बाकी हिस्सों से सुरक्षित रूप से सैंडबॉक्स किया गया है. यह ठीक से काम करने के लिए child-src https://facebook.com डायरेक्टिव की ज़रूरत है. नोट जोड़ें कि, डिफ़ॉल्ट रूप से, Facebook से मिलने वाला <iframe> कोड रिलेटिव यूआरएल, //facebook.com. उसे साफ़ तौर पर एचटीटीपीएस तय करने के लिए बदलें: https://facebook.com. अगर आपको एचटीटीपी इस्तेमाल करने की ज़रूरत नहीं है, तो इसका इस्तेमाल करने की कोई ज़रूरत नहीं है.
Twitter का ट्वीट बटन स्क्रिप्ट और फ़्रेम की ऐक्सेस पर निर्भर करता है, दोनों https://platform.twitter.com. (इसी तरह Twitter, default; कोड को स्थानीय तौर पर कॉपी/पेस्ट करते समय, एचटीटीपीएस में जोड़ने के लिए उसमें बदलाव करें.) जब तक JavaScript स्निपेट को किसी दूसरे खाते में नहीं ले जाया जाता, तब तक आप script-src https://platform.twitter.com; child-src https://platform.twitter.com के साथ पूरी तरह से तैयार हैं जिसे Twitter एक बाहरी JavaScript फ़ाइल में उपलब्ध कराता है.
दूसरे प्लैटफ़ॉर्म की ज़रूरतें भी ऐसी होती हैं और इन्हें भी इसी तरह पूरा किया जा सकता है. हमारा सुझाव है कि आप 'none' का default-src सेट करें. इसके बाद, अपने कंसोल को देखें तय करें कि विजेट को काम करने के लिए आपको किन संसाधनों को चालू करने की ज़रूरत होगी.

एक से ज़्यादा विजेट शामिल करना आसान है: बस नीति को मिलाएं ऐसे डायरेक्टिव जो एक ही टाइप के सभी रिसॉर्स को एक साथ मर्ज करना याद रखते हैं डायरेक्टिव. अगर आपको तीनों सोशल मीडिया विजेट चाहिए, तो नीति इस तरह:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

इस्तेमाल का उदाहरण #2: लॉकडाउन

कुछ समय के लिए मान लें कि आपकी कोई बैंकिंग साइट है और आपको यह पक्का करना है कि लोड किए जा सकेंगे. इस स्थिति में, एक डिफ़ॉल्ट नीति से शुरू करें, जो सभी चीज़ों (default-src 'none') को ब्लॉक करती है और वहीं से तैयार होती है.

मान लें कि बैंक किसी सीडीएन से सभी इमेज, स्टाइल, और स्क्रिप्ट को https://cdn.mybank.net. साथ ही, यह XHR के ज़रिए https://api.mybank.com/ से कनेक्ट होता है डेटा के कई हिस्सों को हटा सकता है. फ़्रेम का उपयोग किया जाता है, लेकिन केवल साइट (कोई तीसरे पक्ष का ऑरिजिन नहीं). साइट पर कोई फ़्लैश नहीं है, कोई फ़ॉन्ट नहीं है अतिरिक्त. हम सबसे ज़्यादा पाबंदी वाला सीएसपी हेडर भेज सकते हैं:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

इस्तेमाल का उदाहरण #3: सिर्फ़ एसएसएल

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

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

भले ही https: की जानकारी default-src में दी गई है, लेकिन स्क्रिप्ट और स्टाइल डायरेक्टिव अपने-आप उस सोर्स को इनहेरिट नहीं करते. हर डायरेक्टिव पूरी तरह उस खास तरह के संसाधन के लिए डिफ़ॉल्ट को ओवरराइट कर देता है.

आने वाला समय

कॉन्टेंट की सुरक्षा के बारे में नीति का दूसरा लेवल उम्मीदवार के सुझाव. द डब्ल्यू3सी का वेब ऐप्लिकेशन सिक्योरिटी वर्किंग ग्रुप ने पहले ही स्पेसिफ़िकेशन के अगले अपडेट पर काम शुरू कर दिया है, कॉन्टेंट की सुरक्षा के लिए नीति का तीसरा लेवल.

अगर आपको इन सुविधाओं के बारे में बातचीत करनी है, तो public-webappsec@ ईमेल पाने वाले लोगों की सूची के संग्रह को हाइलाइट करें, या खुद का हिस्सा बनें.