سياسة أمان المحتوى

Joe Medley
Joe Medley
GitHub

فإن نموذج أمان الويب متأصل في سياسة المصدر نفسه: رمز برمجي من https://mybank.com يجب أن يكون لديه الإذن بالوصول إلى https://mybank.com فقط البيانات، وبالتأكيد لا ينبغي السماح لـ https://evil.example.com بالوصول. يتم الحفاظ على عزل كل مصدر عن باقي المواقع الإلكترونية، ما يمنح المطوّرين بيئة آمنة وضع الحماية الذي يمكن استخدامه للإنشاء واللعب. من الناحية النظرية، هذا رائع تمامًا. ضِمن التدريب، فقد وجد المهاجمون طرقًا ذكية لإسقاط النظام.

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

تسلط هذه النظرة العامة الضوء على دفاع يمكنه تقليل مخاطر تأثير هجمات XSS في المتصفحات الحديثة: سياسة أمان المحتوى (CSP).

TL;DR

  • استخدِم القوائم المسموح بها لإعلام العميل بالمنتجات المسموح بها وغير المسموح بها.
  • تعرَّف على الأوامر المتاحة.
  • التعرف على الكلمات الرئيسية التي تستخدمها.
  • يُعدّ الرمز المضمَّن والرمز eval() ضارًا.
  • إبلاغ خادمك عن انتهاكات السياسة قبل فرضها.

القوائم المسموح بها للمصادر

المشكلة التي تستغلها هجمات XSS هي عدم قدرة المتصفح على تمييز بين النص البرمجي الذي يُعد جزءًا من تطبيقك والنص البرمجي الذي تم التي تم حقنها بشكل ضار من قبل جهة خارجية. على سبيل المثال، زر Google +1 في أسفل هذه الصفحة بتحميل وتنفيذ التعليمات البرمجية من https://apis.google.com/js/plusone.js في سياق مصدر هذه الصفحة. أر نثق في هذه التعليمة البرمجية، ولكننا لا نتوقع أن يكتشف المتصفح من تلقاء نفسه هذه الشفرة من apis.google.com رائع، بينما الرمز من apis.evil.example.com ربما ليس كذلك. ينزّل المتصفح أي رمز في صفحة وينفّذه بسهولة. بغض النظر عن مصدرها.

بدلاً من الوثوق بشكل عشوائي بكل ما يقدمه الخادم، تحدِّد سياسة أمان المحتوى (CSP) عنوان 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، وأيضًا من مصدر الصفحة الحالية.

خطأ في وحدة التحكّم: تم رفض تحميل النص البرمجي "http://evil.example.com/evil.js" لأنّها تخالف التوجيه التالي لسياسة أمان المحتوى: script-src 'self' https://apis.google.com

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

تنطبق السياسة على مجموعة متنوعة من الموارد

على الرغم من أن موارد النصوص البرمجية هي أكثر المخاطر الأمنية وضوحًا، إلا أن سياسة 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 هي نظير script-src لأوراق الأنماط.
  • توجِّه upgrade-insecure-requests برامج وكيل المستخدم إلى إعادة كتابة مخططات عناوين URL. تغيير HTTP إلى HTTPS. هذا التوجيه مخصص لمواقع الويب التي تحتوي على عدد كبير من عناوين URL القديمة التي يجب إعادة كتابتها.
  • worker-src هو توجيه من المستوى 3 في سياسة أمان المحتوى (CSP) يحدّ من عناوين URL التي قد عامل أو عامل أو عامل مشترك أو عامل خدمات. اعتبارًا من تموز (يوليو) 2017، ستكون هذه أمر واحد عمليات تنفيذ محدودة.

بشكل افتراضي، تكون التوجيهات مفتوحة على نطاق واسع. إذا لم يتم تعيين سياسة محددة لنفترض أن هذا التوجيه font-src، فلن يعمل هذا التوجيه تلقائيًا على الرغم من أنك حددت * كمصدر صالح (على سبيل المثال، يمكنك تحميل خطوط من من أي مكان، وبدون قيود).

يمكنك إلغاء هذا السلوك التلقائي من خلال تحديد default-src التوجيه. يحدد هذا التوجيه الإعدادات الافتراضية لمعظم أوامر تتركها غير محددة. بشكل عام، ينطبق هذا على أي توجيه ينتهي بـ -src. في حال ضبط default-src على https://example.com، تعذّر عليك ذلك لتحديد التوجيه font-src، يمكنك عندئذٍ تحميل الخطوط من https://example.com، وليس في أي مكان آخر. لقد حددنا script-src فقط في الأمثلة السابقة، مما يعني أنه يمكن تحميل الصور والخطوط وما إلى ذلك من أي أصل.

لا تستخدِم التوجيهات التالية default-src كبديل. تذكر أن فإن الفشل في تعيينها يشبه السماح بأي شيء.

  • base-uri
  • form-action
  • frame-ancestors
  • plugin-types
  • report-uri
  • sandbox

يمكنك استخدام أكبر أو عدد قليل من هذه الأوامر حسبما يبدو تطبيقًا محددًا، حيث يتم ببساطة إدراج كل منها في عنوان HTTP، ويفصل التوجيهات باستخدام الفواصل المنقوطة. تأكد من إدراج كل الموارد المطلوبة من نوع معيّن في التوجيه single. إذا كتبت شيء مثل script-src https://host1.com; script-src https://host2.com فسيتم ببساطة تجاهل التوجيه الثاني. شيء مثل ما يلي تحديد كلا المصدرين على أنهما صالحان:

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'

تفاصيل التنفيذ

سترى X-WebKit-CSP وX-Content-Security-Policy عنوانًا بمختلف التنسيقات. برامج تعليمية على الويب. من الآن فصاعدًا، يجب تجاهل هذه البادئة العناوين. تدعم المتصفحات الحديثة (باستثناء IE) علامات عنوان Content-Security-Policy هذا هو العنوان الذي يجب أن تستخدمه.

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

تتميز قائمة المصادر في كل توجيه بالمرونة. يمكنك تحديد المصادر عن طريق (data:، https:)، أو يختلف نطاق الخصوصية بدءًا من اسم المضيف فقط (example.com، الذي يتطابق مع أي مصدر على هذا المضيف: أي مخطط أو أي منفذ) إلى معرف موارد منتظم (URI) مؤهل بالكامل (https://example.com:443، والذي يتطابق فقط مع HTTPS، فقط example.com، بالإضافة إلى المنفذ 443 فقط). يتم قبول أحرف البدل، ولكن فقط كمخطط، المنفذ أو في أقصى موضع من اسم المضيف: *://*.example.com:* تتطابق مع جميع النطاقات الفرعية للنطاق example.com (ولكن ليس example.com نفسها)، باستخدام وأي مخطط، وعلى أي منفذ.

تقبل قائمة المصدر أيضًا أربع كلمات رئيسية:

  • قد لا تتطابق قيمة 'none' مع أي نتائج.
  • يتطابق العنصر 'self' مع المصدر الحالي، ولكن لا يتطابق مع نطاقاته الفرعية.
  • يسمح 'unsafe-inline' بتضمين JavaScript وCSS. (سنتطرق إلى هذا في بمزيد من التفصيل بعد قليل).
  • يسمح 'unsafe-eval' بآليات تحويل النص إلى JavaScript مثل 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 فحسب، بل يشمل أيضًا معالِجات الأحداث المضمّنة وjavascript: عنوان URL ستحتاج إلى نقل محتوى علامات script في ملف خارجي، واستبدال javascript: من عناوين URL و<a ... onclick="[JAVASCRIPT]"> بطلبات addEventListener() المناسبة. على سبيل المثال: يمكنك إعادة كتابة ما يلي من:

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

إلى شيء أكثر مثل:

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

تتمتع التعليمة البرمجية المُعاد كتابتها بعدد من المزايا التي تفوق العمل بشكل جيد باستخدام CSP; من أفضل الممارسات بالفعل، بغض النظر عن استخدامك لـ CSP. المضمنة تمزج لغة JavaScript بين البنية والسلوك بالطريقة التي يجب ألّا تراعيها. من الأسهل تخزين الموارد الخارجية في المتصفحات، ويكون من السهل فهمها والمطورون، وتشجّع على تجميع البيانات وتصغيرها. ستكتب بشكل أفضل إذا قمت بعمل نقل الرمز إلى موارد خارجية.

يتم التعامل مع النمط المضمّن بالطريقة نفسها: يتم التعامل مع كل من السمة style وstyle. دمج العلامات في أوراق أنماط خارجية للحماية من مجموعة متنوعة ذكية بشكل مذهل وأساليب استخراج البيانات التي توفرها CSS.

إذا كان يجب أن يكون لديك نص برمجي مضمَّن ونمط، يمكنك تفعيله من خلال إضافة 'unsafe-inline' كمصدر مسموح به في script-src أو style-src التوجيه. يمكنك أيضًا استخدام nonce أو تجزئة (انظر أدناه)، ولكن لا يجب عليك ذلك. إنّ حظر النص البرمجي المضمّن هو أكبر مكاسب أمنية تقدّمها سياسة CSP. كما يؤدي حظر النمط المضمّن إلى تقوية تطبيقك. إنها عبارة عن والجهد مقدمًا لضمان سير الأمور بشكل صحيح بعد نقل جميع التعليمات البرمجية ولكن سيكون ذلك أمرًا مقايضًا يستحق التنفيذ.

إذا كنت مضطرًا لاستخدام هذه الميزة

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

لاستخدام nonce، امنح علامة النص البرمجي سمة nonce. يجب أن تتطابق قيمتها مع واحد. في قائمة المصادر الموثوق بها على سبيل المثال:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

والآن، أضِف الجزء الخاص من التوجيه script-src إلى الكلمة الرئيسية nonce-.

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

تذكر أنه يجب إعادة إنشاء الأرقام الخاصة بكل طلب صفحة ويجب أن تكون لا يمكن تخمينه.

تعمل علامات التجزئة بالطريقة ذاتها. وبدلاً من إضافة الرمز إلى علامة البرنامج النصي إنشاء تجزئة SHA للنص البرمجي نفسه وإضافتها إلى التوجيه script-src. على سبيل المثال، لنفترض أنّ صفحتك تحتوي على ما يلي:

<script>
  alert('Hello, world.');
</script>

ستحتوي سياستك على ما يلي:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

في ما يلي بعض النقاط. تحدّد البادئة sha*- الخوارزمية. التي تنشئ التجزئة. في المثال أعلاه، يتم استخدام sha256-. سياسة CSP أيضًا يتوافق مع sha384- وsha512-. عند إنشاء التجزئة، لا تضمِّن علامات <script> كما أن الأحرف الكبيرة والمسافات البيضاء، بما في ذلك البادئة أو المسافة البيضاء اللاحقة.

يقودك البحث على Google حول إنشاء تجزئات SHA إلى حلول في أي عدد اللغات. باستخدام Chrome 40 أو إصدار أحدث، يمكنك فتح "أدوات مطوري البرامج" ثم أعِد تحميل صفحتك. ستحتوي علامة التبويب "وحدة التحكم" على رسائل خطأ تتضمن معلومات تجزئة sha256 لكل من النصوص البرمجية المضمنة.

Eval أيضًا

حتى عندما لا يتمكن المهاجم من إدخال النص البرمجي مباشرةً، قد يتمكن من خداع تحويل تطبيقك إلى نص غير مكتمل إلى ملفات JavaScript قابلة للتنفيذ وتنفيذه نيابةً عنه. eval()، جديدة 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. إلا أننا نثبط ذلك بشدة. حظر القدرة على التنفيذ تجعل السلاسل أكثر صعوبة على المهاجم لتنفيذ غير مُصرح به على موقعك الإلكتروني.

إعداد التقارير

تُعدّ قدرة CSP على حظر الموارد غير الموثوق بها من جهة العميل مكسبًا كبيرًا لك ولكن سيكون من المفيد جدًا إرسال إشعار إلى الخادم حتى تتمكن من تحديد وإصلاح أي أخطاء تسمح الحقن الضار في المقام الأول. تحقيقًا لهذه الغاية، يمكنك إرشاد متصفّح يتضمّن 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"
  }
}

يحتوي هذا على جزء كبير من المعلومات التي ستساعدك في تعقب السبب المحدد للانتهاك، بما في ذلك الصفحة التي يظهر فيها الانتهاك (document-uri)، مُحيل هذه الصفحة (لاحظ أنه على عكس HTTP العنوان، فإن المفتاح لم يتضمن خطأً إملائيًا)، فإن المورد الذي انتهك سياسة الصفحة (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) الخاصة بتطبيقك: يُرجى تفعيل والإبلاغ عن سياسة جديدة، ومراقبة تقارير الانتهاكات وإصلاح أي أخطاء رَفْعْ عندما تصبح راضيًا عن تأثيرها، ابدأ في فرض السياسة الجديدة.

الاستخدام في العالم الحقيقي

يمكن استخدام CSP 1 بشكلٍ كبير في Chrome وSafari وFirefox، ولكنه محدود للغاية في الإصدار 10 من IE. يمكنك الاطّلاع على التفاصيل على caniuse.com يتوفّر المستوى 2 من سياسة أمان المحتوى (CSP) في Chrome منذ الإصدار 40. وقد نشرت مواقع ضخمة مثل Twitter وFacebook العنوان (تستحق دراسة الحالة من Twitter القراءة)، وهذا المعيار جاهز جدًا لبدء النشر على مواقعك الإلكترونية

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

حالة الاستخدام رقم 1: أدوات وسائل التواصل الاجتماعي

  • زر 1+ في Google يتضمن نصًا من https://apis.google.com، ويتضمن <iframe> من https://plusone.google.com أنت بحاجة إلى سياسة تتضمن كلا المقياسين من أجل تضمين الزر. الحد الأدنى من السياسة هو script-src https://apis.google.com; child-src https://plusone.google.com. تحتاج أيضًا إلى لضمان إدراج مقتطف JavaScript الذي توفّره Google ملف JavaScript خارجي. إذا كانت لديك سياسة مستندة إلى المستوى 1 بشأن استخدام frame-src في المستوى 2، عليك تغييره إلى child-src. لم يعُد ذلك ضروريًا في المستوى 3 من سياسة أمان المحتوى (CSP).

  • الزر "أعجبني" على Facebook يتضمن عددًا من خيارات التنفيذ. ننصحك بالالتزام إصدار واحد (<iframe>) لأنّه موضوع في وضع الحماية بأمان من باقي موقعك الإلكتروني. أُنشأها جون هنتر، الذي كان متخصصًا تتطلب توجيه child-src https://facebook.com ليعمل بشكل سليم. ملاحظة الذي يعمل تلقائيًا على تحميل رمز <iframe> الذي يوفّره Facebook عنوان URL، //facebook.com. غيِّر ذلك لتحديد بروتوكول HTTPS بشكل صريح: https://facebook.com ليس هناك سبب لاستخدام HTTP إذا لم تكن مضطرًا لذلك.

  • زر التغريدات في Twitter يعتمد الوصول إلى نص برمجي وإطار، وكلاهما مستضاف على https://platform.twitter.com (بالمثل، يوفر Twitter عنوان URL نسبيًا default; تعديل الرمز لتحديد HTTPS عند نسخه/لصقه على الجهاز). يمكنك استخدام script-src https://platform.twitter.com; child-src https://platform.twitter.com، ما دمت تنقل مقتطف JavaScript. يقدّمه Twitter في ملف JavaScript خارجي.

  • وهناك منصات أخرى لها متطلبات مشابهة ويمكن التعامل معها بالطريقة نفسها. نقترح عليك ضبط 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

حالة الاستخدام رقم 2: التأمين

افترض لوهلة أنك تدير موقعًا مصرفيًا وتريد التأكد من لن يتم تحميل سوى تلك الموارد التي كتبتها بنفسك. في هذا السيناريو، تبدأ بسياسة تلقائية تحظر كل شيء (default-src 'none') وتتراكم من هناك.

لنفترض أن المصرف يحمّل جميع الصور والأنماط والنصوص البرمجية من شبكة توصيل المحتوى على https://cdn.mybank.net، ويتصل عبر XHR بـ https://api.mybank.com/ سحب أجزاء مختلفة من البيانات. يتم استخدام الإطارات، ولكن فقط للصفحات المحلية لـ الموقع (ما مِن مصادر تابعة لجهات خارجية). ما مِن فلاش على الموقع الإلكتروني أو خطوط أو الإضافية. عنوان 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'

حالة الاستخدام رقم 3: طبقة المقابس الآمنة فقط

يريد مشرف منتدى مناقشة خاتم الزفاف التأكد من أن جميع الموارد يتم تحميلها عبر قنوات آمنة فقط، ولكنها لا تكتب الكثير من التعليمات البرمجية؛ جارٍ إعادة الكتابة وأجزاء كبيرة من برنامج المنتديات الخارجي المليء والنص والأسلوب المضمّنان يتجاوزان قدراته. ستكون السياسة التالية فعالة:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

على الرغم من تحديد https: في default-src، لا يزال النص البرمجي والنمط محدّدين. لا تكتسب الأوامر هذا المصدر تلقائيًا. يتضمن كل توجيه يستبدل الإعداد الافتراضي لهذا النوع المحدد من الموارد.

المستقبل

المستوى الثاني من سياسة أمان المحتوى اقتراح المرشحين: مجموعة عمل أمان تطبيقات الويب التابعة لـ W3C العمل بالفعل على التكرار التالي للمواصفات، المستوى 3 من سياسة أمان المحتوى:

إذا كنت مهتمًا بالمناقشة حول هذه الميزات القادمة، تصفُّح أرشيفات القائمة البريدية public-webappsec@، أو انضم إلى نفسك.

ملاحظات