कई वेब ऐप्लिकेशन को, उपयोगकर्ता के कंट्रोल वाला कॉन्टेंट दिखाना होता है. यह उपयोगकर्ता की ओर से अपलोड की गई इमेज (उदाहरण के लिए, प्रोफ़ाइल फ़ोटो) दिखाने जितना आसान या उपयोगकर्ता के कंट्रोल वाले एचटीएमएल (उदाहरण के लिए, वेब डेवलपमेंट ट्यूटोरियल) को रेंडर करने जितना मुश्किल हो सकता है. इसे सुरक्षित तरीके से करना हमेशा से ही मुश्किल रहा है. इसलिए, हमने ऐसे आसान और सुरक्षित समाधान तैयार किए हैं जिन्हें ज़्यादातर तरह के वेब ऐप्लिकेशन पर लागू किया जा सकता है.
भरोसेमंद न माने जाने वाले कॉन्टेंट को अलग करने के लिए क्लासिक समाधान
उपयोगकर्ता के कंट्रोल में मौजूद कॉन्टेंट को सुरक्षित तरीके से दिखाने के लिए, सैंडबॉक्स डोमेन का इस्तेमाल किया जाता है. इसका मतलब यह है कि अगर आपके ऐप्लिकेशन का मुख्य डोमेन example.com है, तो exampleusercontent.com पर सभी ऐसे कॉन्टेंट को दिखाया जा सकता है जिस पर भरोसा नहीं किया जा सकता. ये दोनों डोमेन क्रॉस-साइट हैं. इसलिए, exampleusercontent.com पर मौजूद किसी भी नुकसान पहुंचाने वाले कॉन्टेंट का असर example.com पर नहीं पड़ेगा.
इस तरीके का इस्तेमाल, सभी तरह के ऐसे कॉन्टेंट को सुरक्षित तरीके से दिखाने के लिए किया जा सकता है जिस पर भरोसा नहीं किया जा सकता. जैसे, इमेज, डाउनलोड, और एचटीएमएल. ऐसा हो सकता है कि आपको इमेज या डाउनलोड के लिए इसका इस्तेमाल करना ज़रूरी न लगे. हालांकि, ऐसा करने से कॉन्टेंट स्निफ़िंग से जुड़े जोखिमों से बचा जा सकता है. खास तौर पर, लेगसी ब्राउज़र में.
सैंडबॉक्स डोमेन का इस्तेमाल, इंडस्ट्री में बड़े पैमाने पर किया जाता है. साथ ही, ये लंबे समय से अच्छी तरह से काम कर रहे हैं. हालांकि, इनके दो बड़े नुकसान हैं:
- ऐप्लिकेशन को अक्सर कॉन्टेंट का ऐक्सेस सिर्फ़ एक उपयोगकर्ता तक सीमित रखना होता है. इसके लिए, पुष्टि करने और अनुमति देने की प्रोसेस लागू करनी होती है. सैंडबॉक्स डोमेन, मुख्य ऐप्लिकेशन डोमेन के साथ कुकी शेयर नहीं करते हैं. इसलिए, ऐसा सुरक्षित तरीके से करना बहुत मुश्किल होता है. पुष्टि करने की सुविधा के लिए, साइटों को क्षमता वाले यूआरएल पर भरोसा करना होगा. इसके अलावा, उन्हें सैंडबॉक्स डोमेन के लिए पुष्टि करने वाली अलग-अलग कुकी सेट करनी होंगी. यह दूसरा तरीका, मॉडर्न वेब में खास तौर पर समस्या पैदा करता है. ऐसा इसलिए, क्योंकि कई ब्राउज़र डिफ़ॉल्ट रूप से क्रॉस-साइट कुकी को सीमित करते हैं.
- यूज़र कॉन्टेंट को मुख्य साइट से अलग रखा जाता है. हालांकि, इसे अन्य यूज़र कॉन्टेंट से अलग नहीं रखा जाता. इससे, सैंडबॉक्स डोमेन पर मौजूद अन्य डेटा पर, उपयोगकर्ता के दुर्भावनापूर्ण कॉन्टेंट के हमले का खतरा बढ़ जाता है. उदाहरण के लिए, एक ही ऑरिजिन का डेटा पढ़कर.
यह भी ध्यान देने वाली बात है कि सैंडबॉक्स डोमेन, फ़िशिंग के जोखिमों को कम करने में मदद करते हैं. ऐसा इसलिए, क्योंकि संसाधनों को अलग-अलग डोमेन पर सेगमेंट किया जाता है.
उपयोगकर्ता के कॉन्टेंट को दिखाने के लिए आधुनिक समाधान
समय के साथ वेब में बदलाव हुआ है. अब ऐसे कॉन्टेंट को दिखाने के लिए, ज़्यादा आसान और सुरक्षित तरीके उपलब्ध हैं. इसके लिए कई अलग-अलग तरीके हैं. इसलिए, हम Google में इस्तेमाल किए जाने वाले दो समाधानों के बारे में बताएंगे.
पहला तरीका: ऐक्टिव न रहने वाले उपयोगकर्ता का कॉन्टेंट दिखाना
अगर किसी साइट को सिर्फ़ ऐसे उपयोगकर्ता का कॉन्टेंट दिखाना है जो अब सक्रिय नहीं है (जैसे, इमेज और डाउनलोड किया गया कॉन्टेंट, जो एचटीएमएल या JavaScript नहीं है), तो अब इसे अलग किए गए सैंडबॉक्स डोमेन के बिना सुरक्षित तरीके से किया जा सकता है. इसके दो मुख्य चरण हैं:
Content-Typeहेडर को हमेशा ऐसे जाने-माने MIME टाइप पर सेट करें जो सभी ब्राउज़र के साथ काम करता हो और जिसमें ऐक्टिव कॉन्टेंट न हो. अगर आपको किसी बात को लेकर शक है, तो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का इस्तेमाल करके, रेंडर करने के लिए अविश्वासनीय कॉन्टेंट को शिम पर भेजता है. - रेंडर किए गए कॉन्टेंट को Blob में बदल दिया जाता है और उसे सैंडबॉक्स किए गए iframe में रेंडर किया जाता है.
क्लासिक सैंडबॉक्स डोमेन के मुकाबले, इससे यह पक्का होता है कि सभी कॉन्टेंट को किसी यूनीक साइट पर पूरी तरह से अलग रखा गया है. साथ ही, मुख्य ऐप्लिकेशन को रेंडर किए जाने वाले डेटा को वापस पाने की सुविधा देने से, अब क्षमता वाले यूआरएल का इस्तेमाल करना ज़रूरी नहीं है.
नतीजा
इन दोनों समाधानों की मदद से, googleusercontent.com जैसे क्लासिक सैंडबॉक्स डोमेन से ज़्यादा सुरक्षित समाधानों पर माइग्रेट किया जा सकता है. ये समाधान, तीसरे पक्ष की कुकी को ब्लॉक करने की सुविधा के साथ काम करते हैं. Google ने पहले ही कई प्रॉडक्ट को इन समाधानों का इस्तेमाल करने के लिए माइग्रेट कर दिया है. साथ ही, अगले साल के लिए और माइग्रेशन की योजना बनाई है.