العب بأمان في إطارات IFrames المتوافقة مع وضع الحماية

إنّ إنشاء تجربة غنية على الويب اليوم يتطلّب بشكلٍ لا مفرّ منه تقريبًا استخدام مكونات ومحتوى لا يمكنك التحكّم فيهما بشكلٍ حقيقي. يمكن أن تساهم التطبيقات المصغّرة التابعة لجهات خارجية في تعزيز التفاعل وتؤدي دورًا مهمًا في تجربت العام للمستخدم، ويكون المحتوى الذي ينشئه المستخدمون أحيانًا أكثر أهمية من المحتوى الأصلي للموقع الإلكتروني. لا يمكنك تجنُّب أيّ منهما، ولكن يزيد كلاهما من خطر حدوث Something Bad™ على موقعك الإلكتروني. إنّ كلّ أداة تضمينها، مثل كلّ إعلان وكلّ أداة تابعة لوسائل التواصل الاجتماعي، هي مسار هجوم محتمل لجهات تهدف إلى إلحاق الضرر بك:

يمكن أن تقلِّل سياسة أمان المحتوى (CSP) من المخاطر المرتبطة بكلا النوعَين من المحتوى من خلال منحك القدرة على إضافة مصادر موثوق بها بشكل خاص للنصوص البرمجية وغيرها من المحتوى إلى القائمة المسموح بها. هذه خطوة كبيرة في الاتجاه الصحيح، ولكن تجدر الإشارة إلى أنّ الحماية التي تقدّمها معظم توجيهات CSP ثنائية: إما أن يكون المرجع مسموحًا به أو لا. في بعض الأحيان، قد يكون من المفيد قول "لست متأكّدًا مما إذا كان مصدر المحتوى هذا موثوقًا به، ولكنّه جميل جدًا. أريد تضمين هذا المحتوى، أرجوك يا متصفّح، ولكن لا تتسبّب في تعطُّل موقعي الإلكتروني".

الحد الأدنى من الأذونات

في الأساس، نبحث عن آلية تتيح لنا منح المحتوى الذي نضمّنه الحد الأدنى من الإمكانات اللازمة لأداء وظيفته فقط. إذا كانت الأداة المصغّرة لا تحتاج إلى فتح نافذة جديدة، لن يؤدي منع الوصول إلى window.open إلى أي تأثير. إذا لم يكن التطبيق يتطلب استخدام Flash، لن يؤدي إيقاف ميزة استخدام المكوّنات الإضافية إلى إثارة أي مشكلة. نحرص على توفير أعلى مستوى من الأمان من خلال اتّباع مبدأ الحدّ الأدنى من الأذونات المميّزة وحظر كل ميزة لا تتعلّق مباشرةً بالوظائف التي نريد استخدامها. والنتيجة هي أنّه لم يعُد علينا الوثوق بشكل أعمى بأنّ بعض المحتوى المضمّن لن يستفيد من امتيازات لا يحقّ له استخدامها. لن يتمكّن التطبيق من الوصول إلى الوظيفة في الأساس.

وتعدّ عناصر iframe الخطوة الأولى نحو إطار عمل جيد لهذا الحلّ. يوفر تحميل بعض المكوّنات غير الموثوق بها في iframe مقياسًا للفصل بين تطبيقك والمحتوى الذي تريد تحميله. لن يتمكّن المحتوى المُدرَج في إطار من الوصول إلى نموذج DOM لصفحتك أو البيانات التي تخزّنها على الجهاز، ولن يتمكّن أيضًا من الرسم في مواضع عشوائية على الصفحة، بل سيكون نطاق عمله محدودًا بحدود الإطار. ومع ذلك، فإنّ عملية الفصل ليست فعّالة حقًا. لا تزال الصفحة المضمّنة تتضمّن عددًا من الخيارات التي تؤدي إلى سلوك مزعج أو ضار، وتعدّ الفيديوهات المشغّلة تلقائيًا والمكونات الإضافية والنوافذ المنبثقة قمة جبل الجليد.

تمنحنا سمة sandbox لعنصر iframe ما نحتاجه لتشديد القيود المفروضة على المحتوى المُدرَج في إطار. يمكننا توجيه المتصفّح إلى تحميل محتوى إطار معيّن في بيئة توفّر امتيازات منخفضة، مع السماح فقط بالمجموعة الفرعية من الإمكانات اللازمة لتنفيذ أي مهمة مطلوبة.

الثقة، ولكن التحقّق

يُعدّ زر "نشر تغريدة" في Twitter مثالاً رائعًا على الوظيفة التي يمكن تضمينها بأمان أكبر في موقعك الإلكتروني من خلال بيئة اختبار. تتيح لك منصة Twitter تضمين الزر من خلال إطار iframe باستخدام الرمز التالي:

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

لمعرفة الإجراءات التي يمكننا حظرها، لنطّلِع بعناية على الإمكانات التي يتطلّبها الزر. إنّ رمز HTML الذي يتم تحميله في الإطار ينفذ جزءًا من لغة JavaScript من خوادم Twitter، وينشئ نافذة منبثقة مملوءة بواجهة للنشر على Twitter عند النقر عليها. وتحتاج هذه الواجهة إلى إذن بالوصول إلى ملفّات تعريف الارتباط في Twitter لربط التغريدة بالحساب الصحيح، كما تحتاج إلى إمكانية إرسال نموذج التغريدة. هذا كلّ ما عليك فعله. لا يحتاج الإطار إلىتحميل أيّ مكوّنات إضافية، ولا يحتاج إلى التنقّل في نافذة المستوى الأعلى أو أيّ من الوظائف الأخرى. بما أنّه لا يحتاج إلى هذه الامتيازات، لنزيلها من خلال وضع محتوى الإطار في مساحة مغلقة.

تعمل ميزة "وضع الحماية" على أساس قائمة بيضاء. نبدأ بإزالة كل التصاريح المُمكنة، ثم نعيد تفعيل الإمكانات الفردية من خلال إضافة علامات محدّدة إلى إعدادات وضع الحماية. بالنسبة إلى تطبيق Twitter المصغّر، قررنا تفعيل JavaScript والنوافذ المنبثقة وإرسال النماذج وملفّات تعريف الارتباط الخاصة بكل من twitter.com وtwitter.co.uk. يمكننا إجراء ذلك من خلال إضافة سمة sandbox إلى iframe باستخدام القيمة التالية:

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

ما مِن إجراءات أخرى مطلوبة. لقد منحنا الإطار جميع الإمكانات التي يتطلبها، وسيمنعه ال browser بجدوى من الوصول إلى أي من الامتيازات التي لم نمنحه إياها صراحةً من خلال قيمة سمة sandbox.

التحكّم الدقيق في الإمكانات

لقد اطّلعنا على بعض علامات وضع الحماية في المثال أعلاه، لنطّلِع الآن على الآلية الداخلية للسمة بمزيد من التفاصيل.

إذا كان لديك إطار iframe يتضمّن سمة sandbox فارغة، سيتم وضع المستند المُدرَج في الإطار في وضع الحماية بالكامل، ما يخضعه للقيود التالية:

• لن يتم تنفيذ JavaScript في المستند المُدرَج في إطار. ولا يشمل ذلك فقط JavaScript المحمَّل صراحةً من خلال علامات النصوص البرمجية، بل يشمل أيضًا معالجات الأحداث المضمّنة وعناوين URL الخاصة بـ javascript:. ويعني ذلك أيضًا أنّه سيتم عرض المحتوى المضمّن في علامات noscript تمامًا كما لو كان المستخدم قد أوقف البرنامج النصي بنفسه.
• يتم تحميل المستند المُعدّ للعرض في مصدر فريد، ما يعني أنّه لن يتم اجتياز أي من عمليات التحقّق من المصدر نفسه، لأنّ المصادر الفريدة لا تتطابق مع أي مصادر أخرى، وحتى مع نفسها. من بين التأثيرات الأخرى، يعني ذلك أنّ المستند ليس لديه إذن بالوصول إلى البيانات المخزّنة في ملفات تعريف الارتباط لأي مصدر أو أي آليات تخزين أخرى (تخزين DOM وIndexed DB وما إلى ذلك).
• لا يمكن للمستند المُدرَج في إطار إنشاء نوافذ أو مربّعات حوار جديدة (من خلال window.open أو target="_blank"، على سبيل المثال).
• لا يمكن إرسال النماذج.
• لن يتم تحميل المكوّنات الإضافية.
• لا يمكن للمستند المُدرَج في إطار التنقّل إلا في نفسه، وليس في العنصر الرئيسي من المستوى الأعلى. سيؤدي ضبط القيمة window.top.location إلى طرح استثناء، ولن يؤدي النقر على الرابط الذي يحتوي على target="_top" إلى أي تأثير.
• يتم حظر الميزات التي يتم تفعيلها تلقائيًا (عناصر النماذج التي يتم التركيز عليها تلقائيًا والفيديوهات التي يتم تشغيلها تلقائيًا وما إلى ذلك).
• لا يمكن الحصول على قفل المؤشر.
• يتم تجاهل سمة seamless في iframes الذي يحتوي عليه المستند المُعدّ للعرض.

هذه إجراءات صارمة جدًا، ويشكّل المستند الذي يتم تحميله إلى 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 عشوائي يعني أنّه يمكن الحصول على أي وجميع البيانات التي يقدّمها المصدر. سنحدّ من خطر حدوث الأمور السيئة™ من خلال التأكّد من تنفيذ الرمز البرمجي داخل بيئة محاكاة، ما يجعله أكثر أمانًا. سنطّلع على الرمز من القاعدة إلى القمة، بدءًا من محتويات الإطار:

<!-- 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>

داخل الإطار، لدينا مستند بسيط يستمع ببساطة إلى الرسائل من العنصر الرئيسي من خلال الربط بحدث message للكائن window. عندما ينفذ الوالد postMessage على محتوى iframe، سيتم تنشيط هذا الحدث، ما يتيح لنا الوصول إلى السلسلة التي يريد الوالد تنفيذها.

في المعالج، نحصل على سمة 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" && 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 والإصدارات الأحدث، وInternet Explorer 10 والإصدارات الأحدث، وChrome في وقت كتابة هذه المقالة (تتوفّر في caniuse بالطبع جدول دعم محدّث). من خلال تطبيق السمة sandbox على iframes التي تضمّنها، يمكنك منح امتيازات معيّنة لل المحتوى الذي يعرضه، فقط تلك الامتيازات اللازمة لكي يعمل المحتوى بشكل صحيح. يمنحك ذلك فرصة تقليل المخاطر المرتبطة بتضمين محتوى تابع لجهات خارجية، بالإضافة إلى ما هو متاح حاليًا من خلال سياسة أمان المحتوى.

بالإضافة إلى ذلك، فإنّ وضع التطبيقات في بيئة معزولة هو أسلوب فعّال لتقليل خطر أن يتمكّن مهاجم ما من استغلال ثغرات في التعليمات البرمجية الخاصة بك. من خلال فصل التطبيق المتكامل إلى مجموعة من الخدمات في وضع الحماية، تكون كل خدمة مسؤولة عن جزء صغير من الوظائف المستقلة، ما يجبر المهاجمين على عدم اختراق محتوى إطارات معيّنة فحسب، بل أيضًا وحدة التحكّم فيها. هذه مهمة أكثر صعوبة، خاصةً أنّ نطاق وحدة التحكّم يمكن تقليله بشكل كبير. يمكنك قضاء وقتك في مراجعة هذا الرمز البرمجي إذا طلبت من المتصفّح المساعدة في تنفيذ الإجراءات الأخرى.

لا يعني ذلك أنّ وضع التطبيقات في بيئة معزولة هو حلّ كامل لمشكلة الأمان على الإنترنت. ويقدّم هذا الإجراء دفاعًا شاملاً، ولا يمكنك الاعتماد على إتاحة المتصفّح لجميع مستخدميك ما لم يكن لديك التحكّم في عملاء المستخدمين (إذا كنت تتحكّم في عملاء المستخدمين، مثلاً في بيئة مؤسسة). في يوم من الأيام، ولكن في الوقت الحالي، يشكّل وضع التطبيقات في بيئة محفوظة طبقة أخرى من الحماية لتعزيز دفاعاتك، وليس دفاعًا كاملاً يمكنك الاعتماد عليه فقط. ومع ذلك، فإنّ الطبقات ممتازة. أقترح عليك استخدام هذا الرابط.

مراجع إضافية

• "فصل الأذونات في تطبيقات HTML5" هي ورقة بحث مثيرة للاهتمام تعمل من خلال تصميم إطار عمل صغير، وتطبيقه على ثلاثة تطبيقات HTML5 حالية.

• يمكن أن يكون وضع الحماية أكثر مرونة عند دمجه مع سمتَين iframe جديدتَين أخريتَين: srcdoc وseamless. يسمح لك الخيار الأول بملء إطار بالمحتوى بدون الحاجة إلى طلب HTTP، ويسمح الخيار الثاني بتطبيق النمط على المحتوى المُدرَج في الإطار. لا يتوفّر دعم جيد للمتصفّحات في الوقت الحالي لكلاهما (Chrome وWebKit الإصدارات التجريبية). ولكن سيكون هذان المتصفّحان مزيجًا مثيرًا للاهتمام في المستقبل. على سبيل المثال، يمكنك استخدام الرمز البرمجي التالي لعرض التعليقات في وضع الحماية على مقالة:

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