कई वेब ऐप्लिकेशन को, उपयोगकर्ता के कंट्रोल वाला कॉन्टेंट दिखाना होता है. यह प्रोसेस, उपयोगकर्ता की अपलोड की गई इमेज (उदाहरण के लिए, प्रोफ़ाइल फ़ोटो) को दिखाने जैसी आसान हो सकती है या उपयोगकर्ता के कंट्रोल वाले एचटीएमएल को रेंडर करने जैसी मुश्किल हो सकती है. उदाहरण के लिए, वेब डेवलपमेंट ट्यूटोरियल. इसे सुरक्षित तरीके से करने में हमेशा मुश्किल होती है. इसलिए, हमने आसान और सुरक्षित समाधान ढूंढने की कोशिश की है. इन समाधानों को ज़्यादातर वेब ऐप्लिकेशन पर लागू किया जा सकता है.
भरोसेमंद नहीं लगने वाले कॉन्टेंट को अलग करने के लिए क्लासिक तरीके
उपयोगकर्ता के कंट्रोल वाले कॉन्टेंट को सुरक्षित तरीके से दिखाने के लिए, सैंडबॉक्स डोमेन का इस्तेमाल किया जा सकता है. इसका मूल मकसद यह है कि अगर आपके ऐप्लिकेशन का मुख्य डोमेन example.com है, तो exampleusercontent.com पर वह सारा कॉन्टेंट दिखाया जा सकता है जिस पर भरोसा नहीं किया जा सकता. ये दोनों डोमेन क्रॉस-साइट हैं. इसलिए, exampleusercontent.com पर मौजूद नुकसान पहुंचाने वाला कोई भी कॉन्टेंट, example.com पर असर नहीं डाल सकता.
इस तरीके का इस्तेमाल, अविश्वसनीय कॉन्टेंट को सुरक्षित तरीके से दिखाने के लिए किया जा सकता है. जैसे, इमेज, डाउनलोड, और एचटीएमएल. ऐसा लग सकता है कि इमेज या डाउनलोड के लिए, इसकी ज़रूरत नहीं है. हालांकि, ऐसा करने से कॉन्टेंट को चुराने से जुड़े जोखिमों से बचा जा सकता है. खास तौर पर, लेगसी ब्राउज़र में.
सैंडबॉक्स डोमेन का इस्तेमाल, इंडस्ट्री में बड़े पैमाने पर किया जाता है. साथ ही, ये लंबे समय से अच्छी तरह से काम कर रहे हैं. हालांकि, इनमें दो बड़ी समस्याएं हैं:
- ऐप्लिकेशन को अक्सर कॉन्टेंट के ऐक्सेस पर किसी एक उपयोगकर्ता की पाबंदी लगानी पड़ती है. इसके लिए, पुष्टि करने और अनुमति देने की सुविधा लागू करना ज़रूरी है. सैंडबॉक्स डोमेन, मुख्य ऐप्लिकेशन डोमेन के साथ कुकी शेयर नहीं करते हैं. इसलिए, इसे सुरक्षित तरीके से शेयर करना बहुत मुश्किल है. पुष्टि करने की सुविधा के साथ काम करने के लिए, साइटों को क्षमता वाले यूआरएल पर भरोसा करना होगा या उन्हें सैंडबॉक्स डोमेन के लिए, पुष्टि करने वाली अलग-अलग कुकी सेट करनी होंगी. दूसरा तरीका, खास तौर पर आधुनिक वेब पर समस्या पैदा करता है. इस वेब पर कई ब्राउज़र, क्रॉस-साइट कुकी पर डिफ़ॉल्ट रूप से पाबंदी लगाते हैं.
- यूज़र जनरेटेड कॉन्टेंट को मुख्य साइट से अलग रखा जाता है, लेकिन उसे दूसरे यूज़र जनरेटेड कॉन्टेंट से अलग नहीं रखा जाता. इससे, नुकसान पहुंचाने वाले उपयोगकर्ता कॉन्टेंट के सैंडबॉक्स डोमेन पर मौजूद अन्य डेटा पर हमला करने का खतरा बढ़ जाता है. उदाहरण के लिए, एक ही सोर्स का डेटा पढ़कर.
यह भी ध्यान देने वाली बात है कि सैंडबॉक्स डोमेन, फ़िशिंग के जोखिमों को कम करने में मदद करते हैं. ऐसा इसलिए, क्योंकि रिसॉर्स को अलग-अलग डोमेन में साफ़ तौर पर सेगमेंट किया जाता है.
उपयोगकर्ता का कॉन्टेंट दिखाने के लिए आधुनिक समाधान
समय के साथ वेब का दायरा बढ़ता गया है. अब अविश्वसनीय कॉन्टेंट को दिखाने के लिए, आसान और ज़्यादा सुरक्षित तरीके उपलब्ध हैं. इस समस्या को हल करने के कई तरीके हैं. इसलिए, हम दो ऐसे समाधानों के बारे में बताएंगे जो फ़िलहाल Google में बड़े पैमाने पर इस्तेमाल किए जा रहे हैं.
पहला तरीका: इनऐक्टिव उपयोगकर्ता का कॉन्टेंट दिखाना
अगर किसी साइट को सिर्फ़ ऐसे कॉन्टेंट को दिखाना है जो उपयोगकर्ता ने ऐक्सेस नहीं किया है, तो अब ऐसा अलग सैंडबॉक्स डोमेन के बिना भी किया जा सकता है. जैसे, इमेज और डाउनलोड. यह कॉन्टेंट, एचटीएमएल या JavaScript नहीं होता. इसके दो मुख्य चरण हैं:
Content-Typeहेडर को हमेशा किसी ऐसे एमआईएमई टाइप पर सेट करें जो सभी ब्राउज़र पर काम करता हो और जिसमें ऐक्टिव कॉन्टेंट न हो. अगर आपको इस बारे में कोई संदेह है, तोapplication/octet-streamको चुनें.- इसके अलावा, रिस्पॉन्स हेडर को हमेशा सेट करें, ताकि यह पक्का किया जा सके कि ब्राउज़र रिस्पॉन्स को पूरी तरह से अलग कर दे.
| रिस्पॉन्स हेडर | मकसद |
|---|---|
X-Content-Type-Options: nosniff |
कॉन्टेंट को चुराने से रोकता है |
Content-Disposition: attachment; filename="download" |
रेंडर करने के बजाय, डाउनलोड को ट्रिगर करता है |
Content-Security-Policy: sandbox |
कॉन्टेंट को सैंडबॉक्स में डालता है, जैसे कि उसे किसी दूसरे डोमेन पर दिखाया गया हो |
Content-Security-Policy: default-src ‘none' |
JavaScript को चलाने की सुविधा बंद कर देता है. साथ ही, किसी भी सब-रिसॉर्स को शामिल नहीं करता |
Cross-Origin-Resource-Policy: same-site |
पेज को क्रॉस-साइट में शामिल होने से रोकता है |
हेडर के इस कॉम्बिनेशन से यह पक्का होता है कि रिस्पॉन्स को आपके ऐप्लिकेशन से सिर्फ़ सब-रिसॉर्स के तौर पर लोड किया जा सकता है या उपयोगकर्ता उसे फ़ाइल के तौर पर डाउनलोड कर सकता है. इसके अलावा, हेडर, CSP सैंडबॉक्स हेडर और default-src पाबंदी की मदद से, ब्राउज़र बग से कई लेयर की सुरक्षा देते हैं. कुल मिलाकर, ऊपर बताए गए सेटअप से यह भरोसा बढ़ जाता है कि इस तरह से दिए गए जवाबों से इंजेक्शन या अलगाव से जुड़ी समस्याएं नहीं हो सकतीं.
मज़बूत सुरक्षा
ऊपर दिया गया तरीका, आम तौर पर XSS से बचाव के लिए काफ़ी है. हालांकि, सुरक्षा को और बेहतर बनाने के लिए, कई और तरीके भी अपनाए जा सकते हैं:
- IE11 के साथ काम करने के लिए,
X-Content-Security-Policy: sandboxहेडर सेट करें. - एंडपॉइंट को एम्बेड होने से रोकने के लिए,
Content-Security-Policy: frame-ancestors 'none'हेडर सेट करें. - उपयोगकर्ता के कॉन्टेंट को अलग सबडोमेन पर सैंडबॉक्स में डालने के लिए:
- उपयोगकर्ता के कॉन्टेंट को अलग-अलग सबडोमेन पर दिखाना. उदाहरण के लिए, Google
product.usercontent.google.comजैसे डोमेन का इस्तेमाल करता है. - क्रॉस-ऑरिजिन आइसोलेशन चालू करने के लिए,
Cross-Origin-Opener-Policy: same-originऔरCross-Origin-Embedder-Policy: require-corpको सेट करें.
- उपयोगकर्ता के कॉन्टेंट को अलग-अलग सबडोमेन पर दिखाना. उदाहरण के लिए, Google
दूसरा तरीका: सक्रिय उपयोगकर्ताओं को कॉन्टेंट दिखाना
सैंडबॉक्स डोमेन के क्लासिक तरीके की कमियों के बिना भी, एचटीएमएल या एसवीजी इमेज जैसे ऐक्टिव कॉन्टेंट को सुरक्षित तरीके से दिखाया जा सकता है.
सबसे आसान विकल्प यह है कि ब्राउज़र को रिस्पॉन्स को अलग करने के लिए कहने के लिए, Content-Security-Policy: sandbox हेडर का फ़ायदा लें. फ़िलहाल, सभी वेब ब्राउज़र सैंडबॉक्स किए गए दस्तावेज़ों के लिए प्रोसेस अलगाव की सुविधा लागू नहीं करते. हालांकि, ब्राउज़र प्रोसेस मॉडल को लगातार बेहतर बनाने से, सैंडबॉक्स किए गए कॉन्टेंट को एम्बेड किए गए ऐप्लिकेशन से अलग करने की सुविधा बेहतर हो सकती है. अगर SpectreJS और रेंडरर से जुड़ी समस्या वाले हमले आपके खतरे के मॉडल से बाहर हैं, तो सीएसपी सैंडबॉक्स का इस्तेमाल करना एक बेहतर विकल्प हो सकता है.
Google ने एक ऐसा समाधान तैयार किया है जो सैंडबॉक्स डोमेन के कॉन्सेप्ट को आधुनिक बनाकर, भरोसेमंद नहीं होने वाले चालू कॉन्टेंट को पूरी तरह से अलग कर सकता है. इसका मुख्य मकसद यह है:
- सार्वजनिक सफ़िक्स की सूची में जोड़ा गया नया सैंडबॉक्स डोमेन बनाएं. उदाहरण के लिए, पीएसएल में
exampleusercontent.comजोड़कर, यह पक्का किया जा सकता है किfoo.exampleusercontent.comऔरbar.exampleusercontent.comक्रॉस-साइट हैं और इसलिए, दोनों एक-दूसरे से पूरी तरह से अलग हैं. *.exampleusercontent.com/shimसे मैच होने वाले सभी यूआरएल, किसी स्टैटिक शिम फ़ाइल पर रीडायरेक्ट हो जाते हैं. इस शिम फ़ाइल में एक छोटा एचटीएमएल और JavaScript स्निपेट होता है, जोmessageइवेंट हैंडलर को सुनता है और उसे मिलने वाले किसी भी कॉन्टेंट को रेंडर करता है.- इसका इस्तेमाल करने के लिए, प्रॉडक्ट
$RANDOM_VALUE.exampleusercontent.com/shimके लिए कोई iframe या पॉप-अप बनाता है. साथ ही,postMessageका इस्तेमाल करके, रेंडरिंग के लिए अविश्वसनीय कॉन्टेंट को शिम पर भेजता है. - रेंडर किए गए कॉन्टेंट को ब्लॉब में बदल दिया जाता है और सैंडबॉक्स किए गए iframe में रेंडर किया जाता है.
क्लासिक सैंडबॉक्स डोमेन के तरीके की तुलना में, इससे यह पक्का होता है कि सारा कॉन्टेंट किसी यूनीक साइट पर पूरी तरह से अलग हो. साथ ही, रेंडर किए जाने वाले डेटा को मुख्य ऐप्लिकेशन से वापस पाने की सुविधा होने पर, अब क्षमता वाले यूआरएल का इस्तेमाल करना ज़रूरी नहीं है.
नतीजा
इन दोनों समाधानों की मदद से, googleusercontent.com जैसे क्लासिक सैंडबॉक्स डोमेन से, तीसरे पक्ष की कुकी को ब्लॉक करने की सुविधा के साथ काम करने वाले ज़्यादा सुरक्षित समाधानों पर माइग्रेट किया जा सकता है. Google ने इन समाधानों का इस्तेमाल करने के लिए, पहले ही कई प्रॉडक्ट माइग्रेट कर लिए हैं. साथ ही, अगले साल और भी प्रॉडक्ट माइग्रेट करने की योजना बनाई गई है.