कई वेब ऐप्लिकेशन को उपयोगकर्ता के कंट्रोल वाली सामग्री दिखाने की ज़रूरत होती है. यह उपयोगकर्ता की अपलोड की गई इमेज (उदाहरण के लिए, प्रोफ़ाइल फ़ोटो) दिखाने जितना आसान हो सकता है. इसके अलावा, यह उपयोगकर्ता के कंट्रोल किए जाने वाले एचटीएमएल को रेंडर करने जितना मुश्किल भी हो सकता है. जैसे, वेब डेवलपमेंट ट्यूटोरियल. सुरक्षित रूप से ऐसा करना हमेशा से मुश्किल रहा है, इसलिए हमने आसान, लेकिन सुरक्षित समाधान ढूंढने के लिए काम किया है, जिन्हें ज़्यादातर प्रकार के वेब ऐप्लिकेशन पर लागू किया जा सकता है.
गैर-भरोसेमंद कॉन्टेंट को अलग करने के लिए क्लासिक समाधान
उपयोगकर्ता के कंट्रोल वाले कॉन्टेंट को सुरक्षित तरीके से दिखाने का क्लासिक तरीका, सैंडबॉक्स डोमेन का इस्तेमाल करना है. मूल विचार यह है कि अगर आपके ऐप्लिकेशन का मुख्य डोमेन 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 |
पेज को क्रॉस-साइट शामिल किए जाने से रोकता है |
हेडर का यह कॉम्बिनेशन यह पक्का करता है कि रिस्पॉन्स को सिर्फ़ आपके ऐप्लिकेशन से सबरिसॉर्स के तौर पर लोड किया जा सके या उपयोगकर्ता फ़ाइल के तौर पर डाउनलोड कर सके. साथ ही, सीएसपी सैंडबॉक्स हेडर और 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
दूसरा तरीका: सक्रिय उपयोगकर्ता का कॉन्टेंट दिखाना
सक्रिय कॉन्टेंट (उदाहरण के लिए, एचटीएमएल या SVG इमेज) को सुरक्षित तरीके से पेश करना, क्लासिक सैंडबॉक्स डोमेन तरीके की कमज़ोरियों के बिना भी किया जा सकता है.
सबसे आसान विकल्प यह है कि Content-Security-Policy: sandbox हेडर का इस्तेमाल करके, ब्राउज़र को रिस्पॉन्स को अलग करने का निर्देश दिया जा सके. फ़िलहाल, सभी वेब ब्राउज़र सैंडबॉक्स दस्तावेज़ों के लिए प्रोसेस आइसोलेशन को लागू नहीं करते. हालांकि, ब्राउज़र प्रोसेस मॉडल को बेहतर बनाने से, सैंडबॉक्स किए गए कॉन्टेंट को ऐप्लिकेशन एम्बेड करने से अलग करने में मदद मिल सकती है. अगर SpectreJS और रेंडरर कॉम्प्रोम हमले, आपके खतरे वाले मॉडल के दायरे में नहीं आते हैं, तो सीएसपी सैंडबॉक्स का इस्तेमाल करना काफ़ी हो सकता है.
Google में, हमने एक ऐसा समाधान तैयार किया है जो सैंडबॉक्स डोमेन के सिद्धांत को आधुनिक बनाकर, गैर-भरोसेमंद ऐक्टिव कॉन्टेंट को पूरी तरह से अलग कर सकता है. इसका मुख्य मकसद है:
- एक नया सैंडबॉक्स डोमेन बनाएं, जिसे सार्वजनिक सफ़िक्स सूची में जोड़ा गया हो. उदाहरण के लिए,
exampleusercontent.comको पीएसएल में जोड़कर, यह पक्का किया जा सकता है किfoo.exampleusercontent.comऔरbar.exampleusercontent.comक्रॉस-साइट हैं और एक-दूसरे से पूरी तरह अलग हैं. *.exampleusercontent.com/shimसे मेल खाने वाले सभी यूआरएल को स्टैटिक शिम फ़ाइल पर ले जाया जाता है. इस शिम फ़ाइल में एक छोटा एचटीएमएल और JavaScript स्निपेट होता है, जोmessageइवेंट हैंडलर को सुनता है और मिलने वाले हर कॉन्टेंट को रेंडर करता है.- इसका इस्तेमाल करने के लिए, प्रॉडक्ट या तो iframe या
$RANDOM_VALUE.exampleusercontent.com/shimके लिए पॉप-अप बनाता है. साथ ही, रेंडरिंग के लिए गैर-भरोसेमंद कॉन्टेंट को शिम में भेजने के लिए,postMessageका इस्तेमाल करता है. - रेंडर किया गया कॉन्टेंट, ब्लॉब में बदल जाता है और सैंडबॉक्स किए गए iframe में रेंडर हो जाता है.
क्लासिक सैंडबॉक्स डोमेन की तुलना में, यह पक्का करता है कि सारा कॉन्टेंट एक यूनीक साइट पर पूरी तरह से अलग-अलग हो. साथ ही, रेंडर किए जाने वाले डेटा को वापस पाने के लिए, ऐप्लिकेशन के मुख्य फ़ंक्शन का इस्तेमाल करने से, अब क्षमता वाले यूआरएल का इस्तेमाल करना ज़रूरी नहीं है.
नतीजा
इन दो समाधानों की मदद से, googleusercontent.com जैसे क्लासिक सैंडबॉक्स डोमेन से ज़्यादा सुरक्षित समाधान को माइग्रेट किया जा सकता है. ये ऐसे समाधान हैं जो तीसरे पक्ष की कुकी ब्लॉक करने की सुविधा के साथ काम करते हैं. Google में, हम इन समाधानों का इस्तेमाल करने के लिए पहले ही कई प्रॉडक्ट माइग्रेट कर चुके हैं. साथ ही, अगले साल हम और भी प्रॉडक्ट माइग्रेट करने की योजना बना रहे हैं.