العب بأمان في إطارات 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. يمكننا إجراء ذلك من خلال إضافة سمة 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>

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

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

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

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

• لن يتم تنفيذ JavaScript في المستند المُدرَج في إطار. ولا يقتصر ذلك على تضمين رموز JavaScript التي تم تحميلها بشكل صريح من خلال علامات النصوص البرمجية، بل يشمل أيضًا معالِجات الأحداث المضمّنة وعناوين URL التي تتضمّن JavaScript. ويعني ذلك أيضًا أنّه سيتم عرض المحتوى المضمَّن في علامات منع النص البرمجي، تمامًا كما لو كان المستخدم قد أوقف النص البرمجي بنفسه.
• يتم تحميل المستند المُعدّ للعرض في مصدر فريد، ما يعني أنّه لن يتم اجتياز أي من عمليات التحقّق من المصدر نفسه، لأنّ المصادر الفريدة لا تتطابق مع أي مصادر أخرى، وحتى مع نفسها. يعني هذا، إلى جانب تأثيرات أخرى، أنّ المستند لا يمكنه الوصول إلى البيانات المخزَّنة في ملفات تعريف الارتباط لأي مصدر أو أي آليات تخزين أخرى (مساحة تخزين نموذج العناصر في المستند (DOM) وقاعدة البيانات المفهرَسة وغيرها).
• لا يمكن للمستند الذي تم وضع إطاره إنشاء نوافذ أو مربعات حوار جديدة (عبر 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 عشوائي يعني أنّه يمكن الحصول على أي وجميع البيانات التي يقدّمها المصدر. سنحدّ من خطر حدوث أخطاء TMBad 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>

داخل الإطار، لدينا مستند بسيط يستمع ببساطة إلى الرسائل من العنصر الرئيسي من خلال الربط بحدث 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 والإصدارات الأحدث، وIE10 والإصدارات الأحدث، و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>