इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

Mike West

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

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

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

असल में, हम ऐसे तरीके की तलाश कर रहे हैं जिससे हम एम्बेड किए गए कॉन्टेंट को सिर्फ़ उतना ऐक्सेस दें जितना ज़रूरी है. अगर किसी विजेट को नई विंडो में पॉप-अप करने की ज़रूरत नहीं है, तो 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 की मदद से, दस्तावेज़ को फ़्रेम से बाहर निकाला जा सकता है. इसके लिए, टॉप-लेवल विंडो पर नेविगेट करें.

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

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);

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

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

हालांकि, ध्यान रखें कि फ़्रेम किए गए ऐसे कॉन्टेंट के साथ काम करते समय आपको बहुत सावधानी बरतनी होगी जो पैरंट कॉन्टेंट के उसी ऑरिजिन से आता है. अगर 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>
```