आज के वेब पर बेहतर अनुभव देने से करीब-करीब उस कॉन्टेंट और कॉम्पोनेंट को एम्बेड किया जाता है जिन पर आपका कोई कंट्रोल नहीं है. तीसरे पक्ष के विजेट, जुड़ाव बढ़ा सकते हैं और उपयोगकर्ता अनुभव में अहम भूमिका निभा सकते हैं. साथ ही, यूज़र जनरेटेड कॉन्टेंट कभी-कभी किसी साइट के मूल कॉन्टेंट से कहीं ज़्यादा अहम होता है. इनमें से किसी से भी परहेज़ करना एक विकल्प नहीं है, लेकिन दोनों इस बात का जोखिम बढ़ाते हैं कि आपकी साइट पर कुछ बैडTM हो सकता है. हर विजेट को एम्बेड किया जाता है. इस विजेट में, हर विज्ञापन और हर सोशल मीडिया विजेट को शामिल किया जाता है. यह नुकसान पहुंचाने वाले लोगों के लिए हमला करने का एक संभावित वेक्टर होता है:
कॉन्टेंट की सुरक्षा के बारे में नीति (सीएसपी), इन दोनों तरह के कॉन्टेंट से जुड़े जोखिमों को कम कर सकती है. इसके लिए, आपको स्क्रिप्ट और अन्य कॉन्टेंट के भरोसेमंद सोर्स को व्हाइटलिस्ट में जोड़ने की सुविधा दी जाती है. इस दिशा में यह एक अहम कदम है. हालांकि, इस बात पर ध्यान देना ज़रूरी है कि ज़्यादातर सीएसपी डायरेक्टिव बाइनरी की मदद से मिलते हैं: रिसॉर्स को अनुमति दी जाती है या नहीं दी जाती है. कई बार ऐसा करना सही होगा कि "मुझे पक्के तौर पर नहीं पता कि मुझे कॉन्टेंट के इस सोर्स पर भरोसा है, लेकिन यह बहुत बढ़िया है! इसे एम्बेड करें, ब्राउज़र, लेकिन इसे मेरी साइट को भंग न होने दें."
कम से कम अधिकार
संक्षेप में, हम एक ऐसा तरीका खोज रहे हैं जिसके ज़रिए हम एम्बेड किए गए कॉन्टेंट को सिर्फ़ उतनी ही क्षमता दें जितने की अपने काम करने के लिए ज़रूरी है. अगर किसी विजेट को नई विंडो में पॉप-अप करने की ज़रूरत न हो, तो window.open डालने पर, उसे ले जाने से कोई दिक्कत नहीं होगी. अगर उसमें Flash की ज़रूरत नहीं है, तो प्लगिन की सुविधा बंद करने से कोई समस्या नहीं होनी चाहिए. हम कम से कम अधिकारों के सिद्धांत का पालन करने पर, जितने हो सकते हैं उतने सुरक्षित हैं. साथ ही, ऐसी हर सुविधा को ब्लॉक कर देते हैं जो सीधे तौर पर काम की नहीं है और जिसका इस्तेमाल करना है. इसका नतीजा यह है कि अब हमें इस बात पर भरोसा नहीं करना पड़ेगा कि एम्बेड किए गए कॉन्टेंट के कुछ हिस्से का फ़ायदा उस कॉन्टेंट को नहीं मिलेगा जिसका इस्तेमाल नहीं किया जाना चाहिए. ऐसे में, उस ऐप्लिकेशन के पास मुख्य तौर पर, इस सुविधा का ऐक्सेस नहीं होगा.
इस तरह के समाधान के लिए, iframe एलिमेंट एक अच्छे फ़्रेमवर्क की ओर पहला कदम हैं.
iframe में कुछ गैर-भरोसेमंद कॉम्पोनेंट लोड होने से, आपके ऐप्लिकेशन और लोड किए जाने वाले कॉन्टेंट के बीच फ़र्क़ पता चलता है. फ़्रेम किए गए कॉन्टेंट के पास आपके पेज के डीओएम या उस डेटा का ऐक्सेस नहीं होगा जिसे आपने स्थानीय तौर पर सेव किया है. साथ ही, वह पेज पर मनमुताबिक जगह नहीं बना पाएगा; यह फ़्रेम की आउटलाइन तक सीमित होता है. हालांकि, अलगाव वास्तविक रूप से मज़बूत नहीं होता. शामिल पेज में
अब भी परेशान करने वाले या नुकसान पहुंचाने वाले व्यवहार के कई विकल्प हैं: वीडियो, प्लगिन
और पॉप-अप अपने-आप चलने के सुझाव सबसे अहम हैं.
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: यूआरएल भी शामिल हैं. इसका मतलब यह भी है कि नोस्क्रिप्ट टैग में शामिल कॉन्टेंट भी दिखेगा, जैसे कि उपयोगकर्ता ने खुद स्क्रिप्ट को बंद किया हो.
- फ़्रेम किया गया दस्तावेज़ किसी यूनीक ऑरिजिन में लोड किया जाता है. इसका मतलब है कि एक ही ऑरिजिन से जुड़ी सभी जांच पूरी नहीं हो पाएंगी. यूनीक ऑरिजिन, किसी दूसरे ऑरिजिन से मैच नहीं करते, यहां तक कि खुद भी नहीं. इसके साथ-साथ, इसका मतलब है कि दस्तावेज़ के पास किसी भी ऑरिजिन की कुकी या स्टोरेज के किसी अन्य तरीके (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 खुद को खास सुविधा वाली ब्राउज़र प्रोसेस में बदल देता है, जिसमें लोकल हार्ड-ड्राइव का ऐक्सेस होता है और उससे नेटवर्क कनेक्शन हो सकता है. साथ ही, कम अधिकार वाली रेंडरर प्रक्रियाएं वे कई ऐसी प्रोसेस में शामिल होती हैं जो गैर-भरोसेमंद कॉन्टेंट को पार्स करने का बड़ा काम करती हैं. रेंडरर को डिस्क को छूने की ज़रूरत नहीं होती, ब्राउज़र उन्हें वह सारी जानकारी दे देता है जिसकी ज़रूरत उन्हें किसी पेज को रेंडर करने के लिए होती है. भले ही चालाक हैकर को किसी रेंडरर को खराब करने का तरीका मिल गया हो, लेकिन वह रेंडर करने वाले व्यक्ति से बहुत दूर है. ऐसा इसलिए, क्योंकि रेंडरर खुद अपने काम में ज़्यादा दिलचस्पी नहीं ले सकता: खास अधिकारों वाला सारा ऐक्सेस, ब्राउज़र की प्रोसेस के ज़रिए ही होना चाहिए. हमलावरों को किसी भी तरह का नुकसान पहुंचाने के लिए, सिस्टम के अलग-अलग हिस्सों में कई छेद ढूंढने होंगे. इससे, पॉर्नेज की सफलता का जोखिम बहुत कम हो जाता है.
eval() को सुरक्षित सैंडबॉक्स किया जा रहा है
सैंडबॉक्स और postMessage एपीआई की मदद से, इस मॉडल को वेब पर लागू करना काफ़ी आसान है. आपके ऐप्लिकेशन के कुछ हिस्से, सैंडबॉक्स किए गए iframe में रह सकते हैं. साथ ही, पैरंट दस्तावेज़, मैसेज पोस्ट करके और उनके जवाबों को सुनकर, उनके बीच
कम्यूनिकेशन में रुकावट डाल सकता है. इस तरह के स्ट्रक्चर से यह पक्का होता है कि ऐप्लिकेशन के किसी भी एक हिस्से में शोषण से सबसे कम नुकसान हो सकता है. इसका एक फ़ायदा यह भी है कि आप साफ़ तौर पर
इंटिग्रेशन पॉइंट बना सकें. इससे आपको पता चलता है कि इनपुट और आउटपुट की पुष्टि
करने के बारे में आपको कहां सावधानी बरतनी चाहिए. चलिए, खिलौने का एक उदाहरण देखते हैं
यह देखते हैं कि वह काम कैसे करता है.
Evalbox एक दिलचस्प ऐप्लिकेशन है, जो स्ट्रिंग को इकट्ठा करता है और JavaScript के तौर पर उसका आकलन करता है. वाह, है न? बस जिसका इंतज़ार आप इतने सालों से कर रहे थे. यह एक काफ़ी खतरनाक ऐप्लिकेशन है, क्योंकि आर्बिट्रेरी JavaScript को लागू करने की अनुमति देने का मतलब है कि ऑरिजिन से मिलने वाला कोई भी और पूरा डेटा, आसानी से हासिल किया जा सकता है. हम बैड थिंग्सTM के जोखिम को कम करने के लिए, यह पक्का करेंगे कि कोड को सैंडबॉक्स में चलाया जाए. इससे यह काफ़ी सुरक्षित हो जाता है. हम फ़्रेम के कॉन्टेंट से शुरुआत करते हुए, कोड के अंदर से ही काम करेंगे:
<!-- 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 के साथ एक छोटा यूज़र इंटरफ़ेस (यूआई) बनाएंगे. साथ ही, हम सैंडबॉक्स किए गए 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" && 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 लिखते समय (बेशक, इसमें अप-टू-डेट सहायता टेबल है). 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>