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

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

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

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

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

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

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

मोड़ें, लेकिन सत्यापित करें

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

<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: यूआरएल. इसका मतलब यह भी है कि नोस्क्रिप्ट टैग में शामिल सामग्री दिखाई देंगे, ठीक वैसे ही जैसे उपयोगकर्ता ने खुद स्क्रिप्ट को बंद कर दिया हो.
  • फ़्रेम किया गया दस्तावेज़ एक यूनीक ऑरिजिन में लोड किया जाता है, जिसका मतलब है कि सभी सेम-ऑरिजन वाले चेक फ़ेल हो जाएंगे; यूनीक ऑरिजिन, किसी और ऑरिजिन से मेल नहीं खाते. खुद भी. इसका मतलब है कि दस्तावेज़ में ऐसी कोई किसी भी ऑरिजिन की कुकी या स्टोरेज के किसी अन्य तरीके में सेव किए गए डेटा का ऐक्सेस (DOM स्टोरेज, इंडेक्स किया गया DB वगैरह).
  • फ़्रेम किया गया दस्तावेज़ नई विंडो या डायलॉग नहीं बना सकता (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 खुद को एक ऐसे ब्राउज़र प्रोसेस में जिसे खास अधिकार दिए गए हैं. इसमें लोकल हार्ड-ड्राइव का ऐक्सेस होता है और वह नेटवर्क कनेक्शन बना सकता है. साथ ही, कई कम खास अधिकार वाली रेंडरर की प्रोसेस को पूरा कर सकता है गैर-भरोसेमंद कॉन्टेंट को पार्स करने में लगने वाला समय उठाए. रेंडरर को छूने की ज़रूरत नहीं है डिस्क, ब्राउज़र उन्हें वह सभी जानकारी देने का ध्यान रखता है जिसकी उन्हें ज़रूरत होती है पेज को रेंडर करते हैं. एक चालाक हैकर को इमेज बनाने वाले को गच्चा देने का तरीका भी पता चलता है लोग बहुत आगे नहीं जाते, क्योंकि रेंडरर अपने हिसाब से ज़्यादा दिलचस्पी नहीं दिखा सकता: सभी खास अधिकार, ब्राउज़र की प्रोसेस से रूट किए जाने चाहिए. हमलावरों को सिस्टम के अलग-अलग हिस्सों में कई छेद करने होंगे कोई नुकसान नहीं पहुंचाता है, जो इसके सफल होने का खतरा बहुत कम कर देता है.

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

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

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

<!-- 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(). इस कॉल को प्रतिबंधित ऑपरेशन के तौर पर, ट्रायल ब्लॉक में पूरा कर दिया गया है सैंडबॉक्स किए गए iframe में, अक्सर DOM अपवाद जनरेट करेंगे; हम पकड़ लेंगे और इसके बजाय एक फ़्रेंडली गड़बड़ी के मैसेज की शिकायत करें. आखिर में, हम नतीजे को पोस्ट करते हैं पैरंट विंडो पर वापस जाएं. यह काफ़ी आसान बात है.

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

<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 (बेशक, उनके पास अप-टू-डेट सहायता टेबल) देखें. sandbox लागू किया जा रहा है शामिल किए गए iframes एट्रिब्यूट का इस्तेमाल करके, आप की अनुमति नहीं है. सिर्फ़ वे खास अधिकार होते हैं जो ताकि कॉन्टेंट सही तरीके से काम करे. इससे आपको जोखिम को कम करने का मौका मिलता है जो तीसरे-पक्ष के कॉन्टेंट को शामिल करने से जुड़ी है. कॉन्टेंट की सुरक्षा के साथ-साथ, नीति.

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

यह कहना सही नहीं है कि सैंडबॉक्सिंग की मदद से, सुरक्षित रखने में मदद मिलती है. इससे कई तरह की सुरक्षा मिलती है. हालांकि, अगर आपके पास उपयोगकर्ताओं का कंट्रोल क्लाइंट, आप अभी तक सभी के लिए ब्राउज़र समर्थन पर अपने उपयोगकर्ताओं (अगर आप अपने उपयोगकर्ता क्लाइंट -- एक एंटरप्राइज़ एनवायरमेंट, उदाहरण के लिए -- हुर्रे!). कभी-कभी... लेकिन अभी के लिए, सैंडबॉक्सिंग आपकी सुरक्षा को मज़बूत करता है. हालांकि, यह पूरा बचाव नहीं है, जिस पर आप पर पूरी तरह से भरोसा किया जा सकता है. फिर भी, लेयर बेहतरीन हैं. मेरा सुझाव है कि आप एक.

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

  • "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>