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