يمكن أن تقلِّل سياسة أمان المحتوى بشكل كبير من خطر هجمات النصوص البرمجية على المواقع الإلكترونية وتأثيرها في المتصفّحات الحديثة.
يستند نموذج أمان الويب إلى
سياسة المصدر نفسه. على سبيل المثال، يجب أن يتمكن رمز https://mybank.com
من الوصول إلى بيانات https://mybank.com
فقط، ويجب عدم السماح https://evil.example.com
بالوصول إليها مطلقًا.
من الناحية النظرية، يتم عزل كل مصدر عن بقية الويب، ما يمنح المطوّرين مساحة اختبار آمنة للتطوير. في الواقع، عثر المهاجمون
على عدة طرق لتعطيل النظام.
على سبيل المثال، تتجاوز هجمات النصوص البرمجية على المواقع الإلكترونية (XSS) سياسة المصدر نفسه من خلال خداع الموقع الإلكتروني ليقوم بإرسال رمز برمجي ضار مع المحتوى المقصود. وتعد هذه مشكلة كبيرة، حيث تثق المتصفحات في جميع الرموز التي تظهر على الصفحة باعتبارها جزءًا من أصل أمان تلك الصفحة. ملخّص XSS: هو مرجع قديم ولكنه تمثيلي يعرض الطرق التي قد يستخدمها المهاجم لانتهاك هذه الثقة عن طريق إدخال رمز ضار. وإذا أدخل مهاجم أي رمز على الإطلاق، يكون قد اخترق جلسة المستخدم وتمكّن من الوصول إلى المعلومات الخاصة.
توضّح هذه الصفحة "سياسة أمان المحتوى" (CSP) كاستراتيجية للحدّ من مخاطر هجمات XSS وتأثيرها في المتصفحات الحديثة.
مكونات سياسة أمان المحتوى (CSP)
لتنفيذ سياسة CSP فعالة، يُرجى اتّباع الخطوات التالية:
- استخدِم القوائم المسموح بها لإعلام العميل بما هو مسموح به وما هو غير مسموح به.
- تعرَّف على الأوامر المتاحة.
- تعرَّف على الكلمات الرئيسية التي تأخذها.
- حصر استخدام الرمز المضمّن و
eval()
- أبلِغ الخادم بانتهاكات السياسة قبل فرضها.
القوائم المسموح بها للمصادر
تستغل هجمات XSS عجز المتصفّح عن التمييز بين النص البرمجي الذي يشكّل
جزءًا من تطبيقك والنص البرمجي الذي تم إدخاله بشكل ضار من قِبل جهة
خارجية. على سبيل المثال، يعمل زر Google +1 الموجود أسفل هذه الصفحة على تحميل وتنفيذ الرموز من https://apis.google.com/js/plusone.js
في سياق مصدر هذه الصفحة.
نحن نثق في هذا الرمز، ولكن لا يمكننا أن نتوقّع من المتصفّح أن يحدّد بنفسه
أنّ الرمز من apis.google.com
آمن للتنفيذ، في حين أنّ الرمز من
apis.evil.example.com
قد لا يكون آمنًا. ينزِّل المتصفّح ويشغّل بكل سرور أي رمز تطلبه الصفحة، بغض النظر عن مصدره.
يتيح لك عنوان HTTP Content-Security-Policy
في "إطار عمل إدارة المحتوى في خدمة مقارنة الأسعار" إنشاء قائمة مسموح بها
لموارد المحتوى الموثوق به، ويطلب من المتصفّح تنفيذ موارد
من هذه المصادر فقط أو عرضها. حتى إذا تمكّن المهاجم من العثور على ثغرة لإدخال ملف برمجي، لن يتطابق الملف البرمجي مع القائمة المسموح بها، وبالتالي لن يتم تنفيذه.
نثق في apis.google.com
لتوفير رمز صالح، ونثق في أنفسنا
لفعل الشيء نفسه. في ما يلي مثال على سياسة تسمح بتنفيذ النصوص البرمجية فقط
عندما تأتي من أحد هذين المصدرَين:
Content-Security-Policy: script-src 'self' https://apis.google.com
script-src
هو توجيه يتحكّم في مجموعة من الامتيازات المرتبطة بالنصوص البرمجية ل
صفحة معيّنة. يُعدّ العنوان 'self'
مصدرًا صالحًا للنص البرمجي، وhttps://apis.google.com
مصدرًا آخر. يمكن للمتصفّح الآن تنزيل وتنفيذ
JavaScript من apis.google.com
عبر HTTPS، وكذلك من أصل
الصفحة الحالية، ولكن ليس من أي مصدر آخر. إذا أدخل مهاجم رمزًا في
موقعك الإلكتروني، يعرض المتصفّح خطأ ولا يُشغّل النص البرمجي الذي تم إدخاله.
تسري السياسة على مجموعة كبيرة من الموارد.
توفّر سياسة CSP مجموعة من توجيهات السياسات التي تتيح إمكانية التحكّم الدقيق في الموارد التي يُسمح للصفحة بتحميلها، ويشمل ذلك script-src
من المثال السابق.
توضِّح القائمة التالية بقية توجيهات الموارد اعتبارًا من المستوى 2. تمت صياغة مواصفات المستوى 3، إلا أنها لم يتم تنفيذها إلى حد كبير في المتصفحات الرئيسية.
base-uri
- يحظر عناوين URL التي يمكن أن تظهر في عنصر
<base>
في الصفحة. child-src
- تُدرِج عناوين URL للعناصر المشغّلة ومحتوى الإطارات المضمّنة. على سبيل المثال،
يتيح لك
child-src https://youtube.com
تضمين فيديوهات من YouTube ولكن ليس من مصادر أخرى. connect-src
- تحدّ من المصادر التي يمكنك الاتصال بها باستخدام XHR وWebSockets وEventSource.
font-src
- يحدِّد المصادر التي يمكنها عرض خطوط الويب. على سبيل المثال، يمكنك السماح
باستخدام خطوط الويب من Google باستخدام
font-src https://themes.googleusercontent.com
. form-action
- تُدرِج نقاط النهاية الصالحة لإرسالها من علامات
<form>
. frame-ancestors
- يتم تحديد المصادر التي يمكنها تضمين الصفحة الحالية. ينطبق هذا التوجيه
على علامات
<frame>
و<iframe>
و<embed>
و<applet>
. ولا يمكن استخدامه في علامات<meta>
أو لموارد HTML. frame-src
- تم إيقاف هذه التوجيهات نهائيًا في المستوى 2، ولكن تم استعادتها في المستوى 3. وإذا
لم يكن متوفّرًا، سيستخدم المتصفّح
child-src
. img-src
- تُحدِّد مصادر الصور التي يمكن تحميلها منها.
media-src
- تقييد المصادر المسموح بها لإرسال الفيديو والصوت.
object-src
- السماح بالتحكم في Flash والمكونات الإضافية الأخرى:
plugin-types
- يحدّ من أنواع الإضافات التي يمكن للصفحة استخدامها.
report-uri
- يحدِّد عنوان URL يرسل إليه المتصفّح التقارير عند
انتهاك سياسة أمان المحتوى. لا يمكن استخدام هذا التوجيه في علامات
<meta>
. style-src
- يحدّد مصادر أوراق الأنماط التي يمكن للصفحة استخدامها.
upgrade-insecure-requests
- توجيه برامج وكيل المستخدم إلى إعادة كتابة مخططات عناوين URL عن طريق تغيير HTTP إلى HTTPS هذه التوجيهات مخصّصة للمواقع الإلكترونية التي تحتوي على أعداد كبيرة من عناوين URL القديمة التي يجب إعادة كتابتها.
worker-src
- هو توجيه من المستوى 3 ضمن سياسة أمان المحتوى (CSP) يحدّ من عناوين URL التي يمكن تحميلها كعامل أو عامل أو عامل مشترك أو مشغّل خدمات. اعتبارًا من تموز (يوليو) 2 2017، تم تنفيذ عمليات محدودة من هذه التوجيهات.
يُحمِّل المتصفّح تلقائيًا المورد المرتبط من أي مصدر، بدون
قيود، ما لم تضبط سياسة تتضمّن توجيهًا محدّدًا. لإلغاء
الإعداد التلقائي، حدِّد توجيه default-src
. يحدّد هذا التوجيه الإعدادات التلقائية لأي توجيه غير محدَّد ينتهي بـ -src
. على سبيل المثال، إذا ضبطت
default-src
على https://example.com
، ولم تحدِّد توجيه font-src
، يمكنك تحميل الخطوط من https://example.com
فقط.
لا تستخدِم التوجيهات التالية default-src
كبديل. تذكر أن عدم تعيينها يشبه
السماح بأي شيء:
base-uri
form-action
frame-ancestors
plugin-types
report-uri
sandbox
بنية CSP الأساسية
لاستخدام توجيهات CSP، يجب إدراجها في عنوان HTTP مع توجيهات مفصولة بعلامات نقطتين. تأكد من سرد جميع الموارد المطلوبة من نوع معين في توجيه واحد على النحو التالي:
script-src https://host1.com https://host2.com
في ما يلي مثال على الأوامر المتعددة، وفي هذه الحالة تطبيق ويب
يحمّل كل موارده من شبكة توصيل المحتوى على
https://cdn.example.net
، ولا يستخدم مكونات إضافية أو محتوى بإطارات:
Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'
تفاصيل التنفيذ
تتوافق المتصفّحات الحديثة مع عنوان Content-Security-Policy
غير المسبَق.
هذا هو العنوان المقترَح. تم إيقاف عنوانَي X-WebKit-CSP
و
X-Content-Security-Policy
نهائيًا، وهما عنوانان قد تظهران في الدروس التعليمية على الإنترنت.
يتم تحديد سياسة CSP على أساس كل صفحة على حدة. عليك إرسال عنوان HTTP مع كل استجابة تريد حمايتها. يتيح لك ذلك ضبط السياسة على صفحات معينة بناءً على احتياجاتها الخاصة. على سبيل المثال، إذا كانت مجموعة من الصفحات في موقعك الإلكتروني تحتوي على زر +1، بينما لا تحتوي الصفحات الأخرى على هذا الزر، يمكنك السماح بتحميل رمز الزر عند الضرورة فقط.
تتميز قائمة المصادر لكل توجيه بالمرونة. يمكنك تحديد المصادر حسب
المخطّط (data:
أو https:
)، أو حسب مدى التحديد من اسم المضيف فقط
(example.com
الذي يتطابق مع أي مصدر على ذلك المضيف: أي مخطّط وأي منفذ) إلى
معرّف الموارد المنتظم المؤهَّل بالكامل (https://example.com:443
الذي يتطابق مع HTTPS فقط،
example.com
فقط، والمنفذ 443 فقط). يتم قبول أحرف البدل، ولكن فقط كمخطّط أو
منفذ أو في أقصى يمين اسم المضيف: *://*.example.com:*
سيتطابق مع جميع النطاقات الفرعية من example.com
(ولكن ليس example.com
نفسه)، باستخدام
أي مخطّط، على أي منفذ.
تقبل قائمة المصدر أيضًا أربع كلمات رئيسية:
- لا تتطابق
'none'
مع أي عنصر. - يتطابق
'self'
مع المصدر الحالي، ولكن ليس مع نطاقاته الفرعية. - يسمح
'unsafe-inline'
بتضمين JavaScript وCSS. ولمزيد من المعلومات، يُرجى الاطّلاع على تجنُّب الرمز المضمَّن. - يسمح
'unsafe-eval'
بآليات تحويل النصوص إلى JavaScript، مثلeval
. لمزيد من المعلومات، راجِع تجنُّبeval()
.
تتطلب هذه الكلمات الرئيسية علامات اقتباس مفردة. على سبيل المثال، يمنح الرمز script-src 'self'
(مع علامات الاقتباس)
الإذن بتنفيذ JavaScript من المضيف الحالي، بينما يسمح الرمز script-src self
(بدون علامات الاقتباس) بتنفيذ JavaScript من خادم باسم "self
" (وليس من المضيف الحالي)، وهو ما قد لا يكون ما قصدته.
وضع صفحاتك في وضع الحماية
هناك توجيه آخر يستحقّ الحديث عنه: sandbox
. وهي مختلفة بعض الشيء عن التطبيقات الأخرى التي تناولناها، لأنّها تفرض قيودًا على الإجراءات التي يمكن أن تتخذها الصفحة بدلاً من الموارد التي يمكن أن تحمّلها الصفحة. إذا كان توجيه
sandbox
متوفّرًا، يتم التعامل مع الصفحة كما لو تم تحميلها
داخل <iframe>
مع سمة sandbox
. ويمكن أن يكون لهذا الإجراء مجموعة كبيرة من
التأثيرات على الصفحة، مثل فرض مصدر فريد للصفحة ومنع إرسال النموذج وغيرها. لا يدخل هذا الموضوع ضمن نطاق هذه الصفحة، ولكن
يمكنك العثور على تفاصيل كاملة عن سمات وضع الحماية الصالحة في
قسم "وضع الحماية" من مواصفات HTML5.
العلامة الوصفية
آلية التسليم المفضلة لمقدّمي خدمة الضبط (CSP) هي عنوان HTTP. ومع ذلك، قد يكون من المفيد ضبط سياسة على إحدى الصفحات من خلال الترميز مباشرةً. يمكنك إجراء ذلك باستخدام علامة <meta>
مع السمة http-equiv
:
<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">
لا يمكن استخدام هذا المبلغ لتسديد frame-ancestors
أو report-uri
أو sandbox
.
تجنُّب الرموز البرمجية المضمّنة
على الرغم من مدى فعالية قوائم المسموح بها المستندة إلى المصدر المستخدَمة في توجيهات CSP، فإنّها
لا يمكنها حلّ أكبر تهديد يمثّله هجمات XSS، وهو حقن النصوص البرمجية المضمّنة.
إذا تمكّن المهاجم من إدخال علامة نص برمجي تحتوي مباشرةً على بعض الحمولات العميقة الضرر (مثل <script>sendMyDataToEvilDotCom()</script>
)، لن يكون لدى المتصفّح سبيل لتمييزها عن علامة نص برمجي مضمّنة مشروعة. ويحلّ إطار عمل CSP هذه
المشكلة من خلال حظر النصوص البرمجية المضمّنة بالكامل.
لا يشمل هذا الحظر النصوص البرمجية المضمّنة مباشرةً في علامات script
فحسب، بل يشمل أيضًا معالِجات الأحداث المضمّنة وعناوين URL التي تتضمّن javascript:
. عليك نقل محتوى علامات script
إلى ملف خارجي واستبدال عناوين URL التي تتضمّن javascript:
و<a ...
onclick="[JAVASCRIPT]">
باستدعاءات addEventListener()
المناسبة. على سبيل المثال،
يمكنك إعادة كتابة ما يلي من:
<script>
function doAmazingThings() {
alert('YOU ARE AMAZING!');
}
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>
إلى ما يلي:
<!-- amazing.html -->
<script src='amazing.js'></script>
<button id='amazing'>Am I amazing?</button>
// amazing.js
function doAmazingThings() {
alert('YOU ARE AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
document.getElementById('amazing')
.addEventListener('click', doAmazingThings);
});
إنّ الرمز المُعاد كتابته متوافق مع CSP، ولكنه متوافق أيضًا مع أفضل ممارسات تصميم الويب. تمزج لغة JavaScript المضمّنة بين البنية والسلوك بطرق تجعل الرمز البرمجي مربكًا. من الأكثر تعقيدًا أيضًا التخزين المؤقت والتجميع. يؤدي نقل الرمز إلى موارد خارجية إلى تحسين أداء صفحاتك.
ننصح بشدة أيضًا بنقل علامات style
والسمات المضمّنة إلى جداول التنسيق الخارجية بهدف حماية موقعك الإلكتروني من هجمات استخراج البيانات المستندة إلى CSS.
كيفية السماح مؤقتًا بالنصوص البرمجية والأنماط المضمّنة
يمكنك تفعيل النصوص البرمجية والأنماط المضمّنة من خلال إضافة 'unsafe-inline'
كمصدر مسموح به في التوجيه script-src
أو style-src
. يتيح لك المستوى 2 من سياسة CSP أيضًا إضافة نصوص برمجية مضمّنة محدّدة إلى
القائمة المسموح بها باستخدام مفتاح تشفير عشوائي (رقم يُستخدَم مرة واحدة) أو تجزئة على النحو التالي:
لاستخدام مفتاح nonce، امنح علامة النص البرمجي سمة nonce. ويجب أن تتطابق قيمته مع قيمة في قائمة المصادر الموثوق بها. على سبيل المثال:
<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
// Some inline code I can't remove yet, but need to as soon as possible.
</script>
أضِف nonce إلى التوجيه script-src
بعد الكلمة الرئيسية nonce-
:
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'
يجب إعادة إنشاء ملفات تعريف الارتباط المؤقتة لكل طلب صفحة، ويجب أن تكون غير قابلة للتوقّع.
تعمل الوظائف التوليدية بالطريقة نفسها. بدلاً من إضافة رمز إلى علامة النص البرمجي، أنشئ ملف SHA hash للنص البرمجي نفسه وأضِفه إلى التوجيه script-src
.
على سبيل المثال، إذا كانت صفحتك تتضمّن ما يلي:
<script>alert('Hello, world.');</script>
يجب أن تتضمّن سياستك ما يلي:
Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='
تحدِّد البادئة sha*-
الخوارزمية التي تُنشئ التجزئة. يستخدم المثال السابق
الرمز sha256-
، ولكن يمكن استخدام الرمزَين sha384-
وsha512-
أيضًا مع CSP. عند
إنشاء العلامة، احذف علامات <script>
. الكتابة بالأحرف الكبيرة والمسافات البيضاء،
بما في ذلك المسافات البيضاء البادئة واللاحقة.
وتتوفّر حلول لإنشاء تجزئات خوارزمية SHA بأي عدد من اللغات. باستخدام Chrome 40 أو إصدار أحدث، يمكنك فتح "أدوات مطوري البرامج" ثم إعادة تحميل صفحتك. تعرِض علامة التبويب "وحدة التحكّم" رسائل الخطأ مع تجزئة SHA-256 الصحيحة لكلّ من النصوص البرمجية المضمّنة.
تجنَّب eval()
حتى إذا لم يتمكّن المهاجم من حقن نص برمجي مباشرةً، قد يتمكّن من خداع
تطبيقك لتحويل نص الإدخال إلى JavaScript قابل للتنفيذ
وتنفيذه نيابةً عنه. تُعد eval()
وnew Function()
وsetTimeout([string], …)
وsetInterval([string], ...)
جميعها
موجّهات يمكن
استخدامها لتنفيذ رمز ضار من خلال النص المُدخَل. إنّ الردّ التلقائي
لبروتوكول CSP على هذا الخطر هو حظر جميع هذه المتجهات بالكامل.
يؤدّي ذلك إلى التأثيرات التالية في طريقة إنشاء التطبيقات:
- يجب تحليل JSON باستخدام
JSON.parse
المضمّن بدلاً من الاعتماد علىeval
. تتوفر عمليات JSON الآمنة في كل متصفِّح منذ IE8. يجب إعادة كتابة أيّ طلبات
setTimeout
أوsetInterval
تجريها باستخدام الدوالّ المضمّنة بدلاً من السلاسل. على سبيل المثال، إذا كانت صفحتك تحتوي على العناصر التالية:setTimeout("document.querySelector('a').style.display = 'none';", 10);
أعِد كتابته على النحو التالي:
setTimeout(function () { document.querySelector('a').style.display = 'none'; }, 10); ```
تجنَّب استخدام النماذج المضمّنة أثناء التشغيل. غالبًا ما تستخدم العديد من مكتبات النماذج
new Function()
لتسريع إنشاء النماذج أثناء التشغيل، ما يسمح بتقييم النص الضار. تتوافق بعض أطر العمل مع سياسة CSP بطريقة غير تقليدية، وذلك بدلاً من استخدام محلّل لغوي فعّال في حال عدم استخدامeval
. يُعدّ توجيه ng-csp في AngularJS مثالاً جيدًا على ذلك. وبدلاً من ذلك، نقترح بدلاً من ذلك استخدام لغة النماذج التي تتيح التجميع المسبق، مثل Handlebars. يمكن أن يؤدي التجميع المسبق للنماذج إلى تحسين تجربة المستخدم بسرعة أكبر من أسرع التنفيذ في بيئة التشغيل، فضلاً عن تعزيز أمان موقعك الإلكتروني.
إذا كانت دالة eval()
أو وظائف تحويل النصوص إلى JavaScript الأخرى ضرورية لتطبيقك، يمكنك تفعيلها عن طريق إضافة 'unsafe-eval'
كمصدر مسموح به في script-src
. وننصحك بشدة بعدم اتّباع هذا الإجراء بسبب مخاطر برمجة
الاقتحام التي يشكّلها.
الإبلاغ عن انتهاكات السياسة
لإعلام الخادم بالأخطاء التي قد تسمح بالحقن الضار، يمكنك
طلب من المتصفّح POST
إرسال تقارير المخالفات بتنسيق JSON إلى موقع
محدّد في توجيه report-uri
:
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
تبدو هذه التقارير كما يلي:
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.js",
"violated-directive": "script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
}
}
يحتوي التقرير على معلومات مفيدة للعثور على سبب انتهاكه لسياسة AdSense، بما في ذلك الصفحة التي حدث فيها الانتهاك (document-uri
) وreferrer
الصفحة ومصادر الانتهاك لسياسة الصفحة (blocked-uri
) والتوجيه المعنيّ الذي تم انتهاكه (violated-directive
) وسياسة الصفحة الكاملة (original-policy
).
إعداد التقارير فقط
إذا كنت لا تزال في خطواتك الأولى في استخدام سياسة CSP، ننصحك باستخدام وضع "إعداد التقارير فقط"
لتقييم حالة تطبيقك قبل تغيير سياستك. لإجراء ذلك، بدلاً من إرسال عنوان Content-Security-Policy
، أرسِل عنوان
Content-Security-Policy-Report-Only
:
Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
لا تحظر السياسة المحدّدة في وضع "إعداد التقارير فقط" الموارد المحظورة، ولكنها تُرسِل تقارير الانتهاكات إلى الموقع الجغرافي الذي تحدّده. يمكنك أيضًا إرسال كلا العنوانَين لفرض سياسة واحدة مع تتبُّع سياسة أخرى. هذه طريقة رائعة لاختبار التغييرات في خدمة إدارة المحتوى أثناء فرض سياستك الحالية: يمكنك تفعيل إعداد تقارير لسياسة جديدة، ومراقبة تقارير الانتهاكات وإصلاح أي أخطاء، وعندما تصبح راضيًا عن السياسة الجديدة، ابدأ بفرضها.
الاستخدام في الحياة اليومية
الخطوة الأولى في وضع سياسة لتطبيقك هي تقييم الموارد التي يحمّلها. عند فهم بنية تطبيقك، أنشئ سياسة تستند إلى متطلباته. تتناول الأقسام التالية بعض حالات الاستخدام الشائعة وعملية اتخاذ القرار بشأن دعمها وفقًا لإرشادات CSP.
تطبيقات مصغّرة لوسائل التواصل الاجتماعي
- يتوفّر زر إبداء الإعجاب
في Facebook بعدة خيارات للتنفيذ. ننصحك باستخدام الإصدار
<iframe>
لإبقاءه في مساحة مغلقة بعيدًا عن باقي موقعك الإلكتروني. وتتطلّب توجيهchild-src https://facebook.com
لكي تعمل بشكل صحيح. - يعتمد زر التغريدة في X على الوصول إلى نص برمجي.
انقل النص البرمجي الذي يوفّره إلى ملف JavaScript خارجي، واستخدِم التوجيه
script-src https://platform.twitter.com; child-src https://platform.twitter.com
. - تفرض المنصات الأخرى متطلبات مشابهة، ويمكن التعامل معها بالطريقة نفسها.
لاختبار هذه الموارد، ننصحك بضبط
default-src
على'none'
ومراقبة وحدة التحكّم لتحديد الموارد التي ستحتاج إلى تفعيلها.
لاستخدام تطبيقات مصغّرة متعددة، اجمع التوجيهات على النحو التالي:
script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com
إلغاء الفتح الذكي
بالنسبة إلى بعض المواقع الإلكترونية، عليك التأكّد من أنّه يمكن تحميل المراجع المحلية فقط. يوضّح المثال التالي تطوير خدمة إدارة خدمات المحتوى (CSP) لموقع مصرفي، بدءًا من
سياسة تلقائية تحظر كل شيء (default-src 'none'
).
يحمِّل الموقع الإلكتروني كل الصور والأنماط والنصوص البرمجية من شبكة توصيل المحتوى (CDN) على الرابط
https://cdn.mybank.net
، ويتصل بـ https://api.mybank.com/
باستخدام XHR ل retrieving data. ويستخدم هذا الإطار الصفحات المحلية فقط على الموقع الإلكتروني (بدون استخدام
مصادر تابعة لجهات خارجية). ما مِن فلاش على الموقع الإلكتروني أو خطوط أو أي إضافات. يليه عنوان CSP الأكثر تقييدًا الذي يمكن إرساله:
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'
طبقة المقابس الآمنة فقط
في ما يلي مثال على سياسة خدمة المحتوى (CSP) لمشرف منتدى يريد التأكّد من أنّه لا يتم تحميل جميع الموارد على المنتدى إلا باستخدام قنوات آمنة، ولكنه ليس لديه معرفة بالترميز ولا يملك الموارد اللازمة لإعادة كتابة برمجية منتدى تابعة لجهة خارجية مليئة بالنصوص البرمجية والأنماط المضمّنة:
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'
على الرغم من تحديد https:
في default-src
، لا تكتسِب توجيهات النص البرمجي وملف الأسلوب
هذا المصدر تلقائيًا. ويؤدّي كل توجيه إلى إلغاء
الإعداد التلقائي لهذا النوع المحدّد من الموارد.
تطوير معيار CSP
يُعدّ المستوى 2 من "سياسة أمان المحتوى" معيارًا مقترَحًا من W3C. تعمل مجموعة عمل أمان تطبيقات الويب في W3C على تطوير الإصدار التالي من المواصفة، وهو المستوى 3 من سياسة أمان المحتوى.
لمتابعة المناقشة حول هذه الميزات القادمة، يُرجى الرجوع إلى أرشيف القائمة البريدية public-webappsec@.