सैंडबॉक्स किए गए IFrames में सुरक्षित तरीके से खेलें

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

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

कम से कम अधिकार

असल में, हम ऐसे तरीके की तलाश कर रहे हैं जिससे हम एम्बेड किए गए कॉन्टेंट को सिर्फ़ उतना ऐक्सेस दें जितना उसे काम करने के लिए ज़रूरी है. अगर किसी विजेट को नई विंडो पॉप-अप करने की ज़रूरत नहीं है, तो window.open का ऐक्सेस हटाने से कोई नुकसान नहीं होगा. अगर ऐप्लिकेशन को फ़्लैश की ज़रूरत नहीं है, तो प्लग इन के साथ काम करने की सुविधा बंद करने से कोई समस्या नहीं होनी चाहिए. कम से कम अनुमति के सिद्धांत का पालन करने पर, हम ज़्यादा से ज़्यादा सुरक्षित रहते हैं. साथ ही, हम उन सभी सुविधाओं को ब्लॉक कर देते हैं जो सीधे तौर पर उस फ़ंक्शन से जुड़ी नहीं होती जिसका इस्तेमाल हमें करना है. इसकी वजह से, अब हमें इस बात पर पूरी तरह भरोसा नहीं करना पड़ता कि एम्बेड किए गए कॉन्टेंट का कोई हिस्सा, उन सुविधाओं का फ़ायदा नहीं लेगा जिनका इस्तेमाल उसे नहीं करना चाहिए. इसके पास,

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

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

भरोसा करें, लेकिन पुष्टि करें

Twitter के "ट्वीट करें" बटन से, इस सुविधा के बारे में पता चलता है कि सैंडबॉक्स की मदद से, अपनी साइट पर इस सुविधा को ज़्यादा सुरक्षित तरीके से जोड़ा जा सकता है. Twitter की मदद से, इस कोड का इस्तेमाल करके iframe के ज़रिए बटन को जोड़ा जा सकता है:

<iframe src="https://platform.twitter.com/widgets/tweet_button.html"
        style="border: 0; width:130px; height:20px;"></iframe>

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

सैंडबॉक्सिंग, व्हाइटलिस्ट के आधार पर काम करती है. हम सभी अनुमतियों को हटाकर शुरू करते हैं. इसके बाद, सैंडबॉक्स के कॉन्फ़िगरेशन में खास फ़्लैग जोड़कर, अलग-अलग सुविधाओं को फिर से चालू करते हैं. हमने Twitter विजेट के लिए, JavaScript, पॉप-अप, फ़ॉर्म सबमिशन, और twitter.com की कुकी चालू करने का फ़ैसला लिया है. ऐसा करने के लिए, iframe में sandbox एट्रिब्यूट जोड़ें और इसकी वैल्यू के तौर पर यह जानकारी दें:

<iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
    src="https://platform.twitter.com/widgets/tweet_button.html"
    style="border: 0; width:130px; height:20px;"></iframe>

हो गया. हमने फ़्रेम को ज़रूरी सभी सुविधाएं दी हैं. साथ ही, ब्राउज़र उन सभी विशेषाधिकारों का ऐक्सेस देने से मना कर देगा जिन्हें हमने sandbox एट्रिब्यूट की वैल्यू के ज़रिए साफ़ तौर पर नहीं दिया है.

सुविधाओं को बेहतर तरीके से कंट्रोल करना

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

अगर किसी iframe में सैंडबॉक्स एट्रिब्यूट की वैल्यू खाली है, तो फ़्रेम किए गए दस्तावेज़ को पूरी तरह से सैंडबॉक्स कर दिया जाएगा. साथ ही, उस पर ये पाबंदियां लागू होंगी:

  • फ़्रेम किए गए दस्तावेज़ में JavaScript काम नहीं करेगा. इसमें स्क्रिप्ट टैग के ज़रिए साफ़ तौर पर लोड की गई JavaScript के साथ-साथ, इनलाइन इवेंट हैंडलर और javascript: यूआरएल भी शामिल हैं. इसका मतलब यह भी है कि noscript टैग में मौजूद कॉन्टेंट ठीक वैसा ही दिखेगा, जैसे कि उपयोगकर्ता ने खुद स्क्रिप्ट बंद की हो.
  • फ़्रेम किया गया दस्तावेज़, एक यूनीक ऑरिजिन में लोड होता है. इसका मतलब है कि एक ही ऑरिजिन की सभी जांचें पूरी नहीं होंगी. यूनीक ऑरिजिन, किसी भी दूसरे ऑरिजिन से मैच नहीं करते. अन्य असर के अलावा, इसका मतलब है कि दस्तावेज़ के पास किसी भी ऑरिजिन की कुकी या किसी अन्य स्टोरेज मेकेनिज्म (DOM स्टोरेज, इंडेक्स किया गया डीबी वगैरह) में सेव किए गए डेटा का ऐक्सेस नहीं है.
  • फ़्रेम किए गए दस्तावेज़ से नई विंडो या डायलॉग नहीं बनाए जा सकते. उदाहरण के लिए, window.open या target="_blank" का इस्तेमाल करके.
  • फ़ॉर्म सबमिट नहीं किए जा सकते.
  • प्लग इन लोड नहीं होंगे.
  • फ़्रेम किया गया दस्तावेज़, सिर्फ़ अपने पेज पर नेविगेट कर सकता है, न कि अपने टॉप-लेवल पेरंट पर. window.top.location सेट करने पर, एक अपवाद दिखेगा. साथ ही, target="_top" वाले लिंक पर क्लिक करने से कोई असर नहीं पड़ेगा.
  • अपने-आप ट्रिगर होने वाली सुविधाएं ब्लॉक हो जाती हैं. जैसे, फ़ॉर्म के अपने-आप फ़ोकस होने वाले एलिमेंट, अपने-आप चलने वाले वीडियो वगैरह.
  • पॉइंटर लॉक नहीं मिल सकता.
  • फ़्रेम किए गए दस्तावेज़ में मौजूद iframes पर seamless एट्रिब्यूट को अनदेखा किया जाता है.

यह नीति काफ़ी सख्त है. हालांकि, पूरी तरह से सैंडबॉक्स किए गए iframe में लोड किए गए दस्तावेज़ से, असल में बहुत कम खतरा होता है. हालांकि, यह बहुत काम का नहीं है: हो सकता है कि कुछ स्टैटिक कॉन्टेंट के लिए, आपको पूरे सैंडबॉक्स की ज़रूरत न पड़े, लेकिन ज़्यादातर मामलों में आपको कुछ ढील देनी होगी.

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

  • allow-forms, फ़ॉर्म सबमिट करने की अनुमति देता है.
  • allow-popups से पॉप-अप दिखाने की अनुमति मिलती है.
  • allow-pointer-lock की मदद से, पॉइंटर लॉक किया जा सकता है.
  • allow-same-origin की मदद से, दस्तावेज़ के ऑरिजिन को बनाए रखा जा सकता है. https://example.com/ से लोड किए गए पेजों के पास, उस ऑरिजिन के डेटा का ऐक्सेस बना रहेगा.
  • allow-scripts से JavaScript को चलाने की अनुमति मिलती है. साथ ही, इससे सुविधाओं को अपने-आप ट्रिगर होने की अनुमति भी मिलती है, क्योंकि JavaScript की मदद से उन्हें लागू करना आसान होता है.
  • allow-top-navigation की मदद से, दस्तावेज़ को फ़्रेम से बाहर निकाला जा सकता है. इसके लिए, टॉप-लेवल विंडो पर नेविगेट करें.

इन बातों को ध्यान में रखते हुए, हम यह आकलन कर सकते हैं कि ऊपर दिए गए ट्विटर के उदाहरण में, सैंडबॉक्सिंग फ़्लैग का खास सेट क्यों इस्तेमाल किया गया:

  • allow-scripts ज़रूरी है, क्योंकि फ़्रेम में लोड किया गया पेज, उपयोगकर्ता के इंटरैक्शन से निपटने के लिए कुछ JavaScript चलाता है.
  • allow-popups की वैल्यू देना ज़रूरी है, क्योंकि यह बटन ट्वीट करने के लिए एक फ़ॉर्म को नई विंडो में पॉप-अप करता है.
  • allow-forms की वैल्यू देना ज़रूरी है, क्योंकि ट्वीट करने के लिए फ़ॉर्म सबमिट किया जा सकता है.
  • allow-same-origin ज़रूरी है, क्योंकि ऐसा न करने पर, twitter.com की कुकी को ऐक्सेस नहीं किया जा सकेगा. साथ ही, उपयोगकर्ता फ़ॉर्म पोस्ट करने के लिए लॉग इन नहीं कर पाएगा.

ध्यान देने वाली एक अहम बात यह है कि किसी फ़्रेम पर लागू किए गए सैंडबॉक्सिंग फ़्लैग, सैंडबॉक्स में बनाई गई किसी भी विंडो या फ़्रेम पर भी लागू होते हैं. इसका मतलब है कि हमें फ़्रेम के सैंडबॉक्स में allow-forms जोड़ना होगा. भले ही, फ़ॉर्म सिर्फ़ उस विंडो में मौजूद हो जिसमें फ़्रेम पॉप-अप होता है.

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

अलग-अलग प्रिविलेज

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

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

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

eval() को सुरक्षित तरीके से सैंडबॉक्स करना

सैंडबॉक्सिंग और postMessage एपीआई की मदद से, इस मॉडल को वेब पर लागू करना आसान है. आपके ऐप्लिकेशन के कुछ हिस्से, सैंडबॉक्स किए गए iframe में हो सकते हैं. साथ ही, पैरंट दस्तावेज़, मैसेज पोस्ट करके और जवाबों को सुनकर, उनके बीच बातचीत को ब्रोकर कर सकता है. इस तरह के स्ट्रक्चर से यह पक्का होता है कि ऐप्लिकेशन के किसी भी हिस्से में एक्सप्लॉइट होने पर, कम से कम नुकसान हो. इससे आपको इंटिग्रेशन पॉइंट बनाने के लिए भी मजबूर होना पड़ता है. इससे आपको यह पता चलता है कि इनपुट और आउटपुट की पुष्टि करने के लिए आपको कहां सावधानी बरतनी है. आइए, एक खिलौने के उदाहरण से देखते हैं कि यह कैसे काम करता है.

Evalbox एक दिलचस्प ऐप्लिकेशन है, जो किसी स्ट्रिंग को JavaScript के तौर पर इस्तेमाल करता है. वाह, है न? यह वही है जिसका आपको इतने सालों से इंतज़ार था. यह एक काफ़ी खतरनाक ऐप्लिकेशन है. ऐसा इसलिए है, क्योंकि किसी भी JavaScript को चलाने की अनुमति देने का मतलब है कि ऑरिजिन का कोई भी डेटा ऐक्सेस किया जा सकता है. हम 'बुरी चीज़ें™' होने के जोखिम को कम करेंगे. इसके लिए, हम यह पक्का करेंगे कि कोड को सैंडबॉक्स में चलाया जाए. इससे कोड काफ़ी सुरक्षित हो जाता है. हम कोड को अंदर से बाहर की ओर पढ़ेंगे. इसके लिए, हम फ़्रेम के कॉन्टेंट से शुरू करेंगे:

<!-- frame.html -->
<!DOCTYPE html>
<html>
    <head>
    <title>Evalbox's Frame</title>
    <script>
        window.addEventListener('message', function (e) {
        var mainWindow = e.source;
        var result = '';
        try {
            result = eval(e.data);
        } catch (e) {
            result = 'eval() threw an exception.';
        }
        mainWindow.postMessage(result, event.origin);
        });
    </script>
    </head>
</html>

फ़्रेम में, हमारे पास एक छोटा दस्तावेज़ होता है. यह window ऑब्जेक्ट के message इवेंट में हुक करके, अपने पैरंट से मैसेज सुनता है. जब भी माता-पिता, iframe के कॉन्टेंट पर postMessage को लागू करते हैं, तो यह इवेंट ट्रिगर हो जाएगा. इससे हमें उस स्ट्रिंग का ऐक्सेस मिल जाएगा जिसे माता-पिता को लागू करना है.

हैंडलर में, हम इवेंट का source एट्रिब्यूट लेते हैं, जो पैरंट विंडो होती है. हम इसका इस्तेमाल, अपनी मेहनत के नतीजे वापस अपलोड करने के लिए करेंगे. इसके बाद, हम eval() में दिया गया डेटा डालकर, ज़रूरी काम करेंगे. इस कॉल को try ब्लॉक में रखा गया है, क्योंकि सैंडबॉक्स किए गए iframe में, पाबंदी वाले ऑपरेशन अक्सर DOM अपवाद जनरेट करेंगे. हम उन अपवादों को पकड़कर, गड़बड़ी का एक आसान मैसेज दिखाएंगे. आखिर में, हम नतीजे को पैरंट विंडो पर पोस्ट करते हैं. यह बहुत आसान है.

पैरंट भी इसी तरह आसान है. हम कोड के लिए textarea और उसे चलाने के लिए button के साथ एक छोटा यूज़र इंटरफ़ेस (यूआई) बनाएंगे. साथ ही, हम सैंडबॉक्स किए गए iframe के ज़रिए frame.html को खींचेंगे, ताकि सिर्फ़ स्क्रिप्ट को चलाया जा सके:

<textarea id='code'></textarea>
<button id='safe'>eval() in a sandboxed frame.</button>
<iframe sandbox='allow-scripts'
        id='sandboxed'
        src='frame.html'></iframe>

अब हम इसे लागू करने के लिए तैयार करेंगे. सबसे पहले, हम iframe से जवाब मांगेंगे और फिर उन्हें अपने उपयोगकर्ताओं को देंगे.alert() ऐसा माना जा सकता है कि कोई असल ऐप्लिकेशन, लोगों को परेशान करने वाला कुछ ऐसा नहीं करेगा:

window.addEventListener('message',
    function (e) {
        // Sandboxed iframes which lack the 'allow-same-origin'
        // header have "null" rather than a valid origin. This means you still
        // have to be careful about accepting data via the messaging API you
        // create. Check that source, and validate those inputs!
        var frame = document.getElementById('sandboxed');
        if (e.origin === "null" &amp;&amp; e.source === frame.contentWindow)
        alert('Result: ' + e.data);
    });

इसके बाद, हम button पर क्लिक करने के लिए इवेंट हैंडलर को जोड़ेंगे. जब उपयोगकर्ता क्लिक करेगा, तो हम textarea के मौजूदा कॉन्टेंट को पकड़ लेंगे और उन्हें फ़्रेम में भेज देंगे, ताकि उन्हें लागू किया जा सके:

function evaluate() {
    var frame = document.getElementById('sandboxed');
    var code = document.getElementById('code').value;
    // Note that we're sending the message to "*", rather than some specific
    // origin. Sandboxed iframes which lack the 'allow-same-origin' header
    // don't have an origin which you can target: you'll have to send to any
    // origin, which might alow some esoteric attacks. Validate your output!
    frame.contentWindow.postMessage(code, '*');
}

document.getElementById('safe').addEventListener('click', evaluate);

आसान है, है ना? हमने आकलन करने वाला एक बहुत ही आसान एपीआई बनाया है. हम यह पक्का कर सकते हैं कि जिस कोड का आकलन किया जा रहा है उसके पास कुकी या डीओएम स्टोरेज जैसी संवेदनशील जानकारी का ऐक्सेस नहीं है. इसी तरह, जांचा गया कोड प्लग इन लोड नहीं कर सकता, नई विंडो पॉप-अप नहीं कर सकता या कई अन्य परेशान करने वाली या नुकसान पहुंचाने वाली गतिविधियां नहीं कर सकता.

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

हालांकि, ध्यान रखें कि फ़्रेम किए गए ऐसे कॉन्टेंट के साथ काम करते समय आपको बहुत सावधानी बरतनी होगी जो पैरंट कॉन्टेंट के उसी ऑरिजिन से आता है. अगर https://example.com/ पर मौजूद कोई पेज, एक ही ओरिजिन पर मौजूद किसी दूसरे पेज को सैंडबॉक्स के ज़रिए फ़्रेम करता है, जिसमें allow-same-origin और allow-scripts, दोनों फ़्लैग शामिल होते हैं, तो फ़्रेम किया गया पेज पैरंट पेज तक पहुंच सकता है और सैंडबॉक्स एट्रिब्यूट को पूरी तरह से हटा सकता है.

अपने सैंडबॉक्स में खेलना

सैंडबॉक्सिंग की सुविधा अब कई ब्राउज़र पर उपलब्ध है: Firefox 17 और उसके बाद के वर्शन, IE10 और उसके बाद के वर्शन, और Chrome (बेशक, caniuse में अप-टू-डेट सहायता टेबल है). शामिल किए गए iframes पर sandbox एट्रिब्यूट लागू करने से, आपको उस कॉन्टेंट के लिए कुछ खास सुविधाएं देने की अनुमति मिलती है जिसे वह दिखाता है. हालांकि, सिर्फ़ उन सुविधाओं को दिया जा सकता है जो कॉन्टेंट के सही तरीके से काम करने के लिए ज़रूरी हैं. इससे, कॉन्टेंट की सुरक्षा से जुड़ी नीति के तहत पहले से मौजूद सुविधाओं के अलावा, तीसरे पक्ष के कॉन्टेंट को शामिल करने से जुड़े जोखिम को कम करने में मदद मिलती है.

इसके अलावा, सैंडबॉक्सिंग एक ऐसी बेहतरीन तकनीक है जिससे यह जोखिम कम किया जा सकता है कि कोई चतुर हमलावर आपके कोड में मौजूद गड़बड़ियों का फ़ायदा उठा पाए. किसी एक जैसे काम करने वाले ऐप्लिकेशन को सैंडबॉक्स की गई सेवाओं के सेट में अलग-अलग करके, हर सेवा को अपने काम के छोटे हिस्से के लिए ज़िम्मेदार बनाया जा सकता है. इससे, हमलावर को न सिर्फ़ चुनिंदा फ़्रेम के कॉन्टेंट को हैक करना होगा, बल्कि उनके कंट्रोलर को भी हैक करना होगा. यह काफ़ी मुश्किल काम है, खास तौर पर इसलिए, क्योंकि कंट्रोलर के दायरे को काफ़ी कम किया जा सकता है. अगर ब्राउज़र से बाकी कामों में मदद मांगी जाती है, तो सुरक्षा से जुड़ी अपनी कोशिशों को उस कोड की ऑडिटिंग में लगाया जा सकता है.

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

इसके बारे में और पढ़ें

  • "HTML5 ऐप्लिकेशन में विशेषाधिकार को अलग करना" एक दिलचस्प पेपर है. इसमें एक छोटे फ़्रेमवर्क के डिज़ाइन और तीन मौजूदा HTML5 ऐप्लिकेशन पर इसके इस्तेमाल के बारे में बताया गया है.

  • सैंडबॉक्सिंग को दो अन्य नए iframe एट्रिब्यूट के साथ जोड़ने पर, इसे और भी आसानी से इस्तेमाल किया जा सकता है: srcdoc और seamless. पहले विकल्प की मदद से, एचटीटीपी अनुरोध के ओवरहेड के बिना फ़्रेम में कॉन्टेंट भरा जा सकता है. वहीं, दूसरे विकल्प की मदद से, फ़्रेम किए गए कॉन्टेंट में स्टाइल जोड़ा जा सकता है. फ़िलहाल, Chrome और WebKit के नाइटली वर्शन, दोनों के लिए ब्राउज़र की सहायता काफ़ी खराब है. हालांकि, आने वाले समय में यह एक दिलचस्प कॉम्बिनेशन होगा. उदाहरण के लिए, यहां दिए गए कोड की मदद से, किसी लेख पर की गई टिप्पणियों को सैंडबॉक्स में डाला जा सकता है:

        <iframe sandbox seamless
            srcdoc="<p>This is a user's comment!
                       It can't execute script!
                       Hooray for safety!</p>"></iframe>