تساعد سياسة أمان المحتوى (CSP) في ضمان أن أي محتوى يتم تحميله على الصفحة موثوق به من قِبل مالك الموقع الإلكتروني. يخفِّض مقدمو خدمة الضبط (CSP) هجمات البرمجة النصية على المواقع الإلكترونية (XSS) لأنها يمكنها حظر النصوص البرمجية غير الآمنة التي يدخلها المهاجمون. ومع ذلك، يمكن بسهولة تجاوز سياسة CSP إذا لم تكن صارمة بما يكفي. للمزيد من المعلومات، راجِع مقالة الحدّ من استخدام النصوص البرمجية على المواقع الإلكترونية (XSS) باستخدام سياسة أمان محتوى (CSP) صارمة. تجمع أداة Lighthouse "مقدّمي الخدمات لصنّاع المحتوى" (CSP) المطبَّقة على المستند الرئيسي، وتُبلغ عن المشاكل من مقيّم سياسة أمان المحتوى (CSP) في حال كان من الممكن تجاوزها.
الممارسات المطلوبة لمقدّم خدمة عملاء (CSP) لا يمكن تجاوزه
نفِّذ الممارسات التالية لضمان عدم تجاوز سياسة CSP. وفي حال كان من الممكن تجاوز سياسة CSP، ستُصدر Lighthouse تحذيرًا عالي الخطورة.
سياسة CSP تستهدف XSS
لاستهداف XSS، يجب أن يشتمل CSP على التوجيهات script-src وobject-src وbase-uri. يجب أن يكون CSP خاليًا من أخطاء البنية.
يعمل كل من script-src وobject-src على تأمين صفحة من النصوص البرمجية غير الآمنة والمكوّنات الإضافية غير الآمنة على التوالي. بدلاً من ذلك، يمكن استخدام default-src لضبط سياسة واسعة النطاق بدلاً من العديد من التوجيهات، بما في ذلك script-src وobject-src.
يمنع base-uri إدخال علامات <base> غير مصرَّح بها والتي يمكن استخدامها لإعادة توجيه جميع عناوين URL النسبية (مثل النصوص البرمجية) إلى نطاق يتحكّم فيه مهاجم.
يستخدم CSP أرقامًا أو علامات تجزئة لتجنُّب تجاوز القائمة المسموح بها.
إنّ سياسة CSP التي تضبط القائمة المسموح بها في script-src على افتراض أنّ جميع الردود الواردة من نطاق موثوق به آمنة ويمكن تنفيذها كنصوص برمجية. ومع ذلك، لا ينطبق هذا الافتراض على التطبيقات الحديثة؛ بعض الأنماط الشائعة والحميدة، مثل كشف واجهات JSONP واستضافة نُسخ من مكتبة AngularJS، تسمح للمهاجمين بالهروب من قيود سياسة أمان المحتوى (CSP).
من الناحية العملية، على الرغم من أنّ مؤلفي التطبيقات قد لا يكون واضحًا لهم، يمكن أن يتحايل مهاجم على معظم script-src القوائم المسموح بها من خلال مهاجم لديه خطأ XSS، ما يوفّر قدرًا ضئيلاً من الحماية من إدخال النصوص البرمجية. في المقابل، لا تعاني الأساليب غير المستندة إلى علامات التجزئة من هذه المشاكل، ما يسهّل اعتماد سياسة أكثر أمانًا والحفاظ عليها.
على سبيل المثال، يستخدم هذا الرمز نقطة نهاية JSONP مستضافة على نطاق موثوق به لإدخال نص برمجي يتحكّم فيه مهاجم:
سياسة أمان المحتوى (CSP):
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
لتجنب التجاوز، يجب أن يسمح CSP بالنصوص البرمجية بشكل فردي باستخدام nonces أو التجزئات واستخدام 'strict-dynamic'. بدلاً من القائمة المسموح بها.
اقتراحات إضافية حول سياسة أمان (CSP) آمنة
نفِّذ الممارسات التالية لزيادة الأمان والتوافق. وفي حال لم يتّبع سياسة CSP أحد الاقتراحات، ستصدر أداة Lighthouse تحذيرًا متوسط الخطورة.
ضبط إعداد تقارير سياسة أمان المحتوى (CSP)
سيساعد ضبط وجهة إعداد التقارير في رصد أي أعطال. يمكنك إعداد وجهة إعداد التقارير باستخدام التوجيه report-uri أو report-to. report-to غير متوافق حاليًا مع جميع المتصفحات الحديثة، لذا يُنصح باستخدام كلتيهما أو استخدام report-uri فقط.
في حال كان أي محتوى يخالف سياسة أمان المحتوى (CSP)، سيرسل المتصفِّح تقريرًا إلى الوجهة التي تم ضبطها. تأكَّد من إعداد تطبيق في هذه الوجهة للتعامل مع هذه التقارير.
تحديد سياسة CSP في عنوان HTTP
يمكن تحديد سياسة CSP في علامة وصفية على النحو التالي:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
ومع ذلك، يجب تحديد سياسة CSP في عنوان استجابة HTTP إذا أمكن. أي حقن قبل العلامة الوصفية سيتجاوز سياسة CSP. بالإضافة إلى ذلك، لا يمكن استخدام frame-ancestors وsandbox وإعداد التقارير في سياسة CSP الخاصة بالعلامات الوصفية.
التأكّد من توافق سياسة CSP مع الإصدارات القديمة
لا تتيح بعض المتصفّحات استخدام علامات CSP الخاصة أو علامات التجزئة، لذلك ننصح بإضافة unsafe-inline كإجراء احتياطي للمتصفّحات غير المتوافقة. وإذا كان المتصفّح يتيح استخدام nonces/hashes، سيتم تجاهل unsafe-inline.
وبالمثل، لا يتوافق strict-dynamic مع جميع المتصفحات. ننصح بضبط القائمة المسموح بها كإجراء احتياطي لأيّ متصفّحات غير متوافقة. وسيتم تجاهل القائمة المسموح بها في المتصفّحات المتوافقة مع strict-dynamic.
كيفية تطوير سياسة أمان محتوى (CSP) صارمة
في ما يلي مثال على استخدام سياسة CSP صارمة مع سياسة لا تستند إلى أي سياسة.
سياسة أمان المحتوى (CSP):
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
ستكون random123 أي سلسلة base64 من جهة الخادم يتم إنشاؤها في كل مرة يتم فيها تحميل الصفحة. يتم تجاهل unsafe-inline وhttps: في المتصفحات الحديثة بسبب عدم وجود اسم وstrict-dynamic. للحصول على مزيد من المعلومات حول اعتماد سياسة CSP صارمة، يمكنك الاطّلاع على دليل سياسة CSP الصارمة.
يمكنك التحقّق من سياسة CSP بحثًا عن أي تجاوزات محتملة باستخدام Lighthouse ومقيّم CSP. إذا أردت اختبار سياسة CSP جديدة بدون المخاطرة بتقسيم صفحات حالية، عليك تحديد سياسة CSP في وضع "إعداد التقارير فقط" باستخدام Content-Security-Policy-Report-Only كاسم للعنوان. سيؤدي هذا الإجراء إلى إرسال انتهاكات سياسة CSP إلى أي وجهات إعداد تقارير أعددتها من خلال report-to وreport-uri، ولكنه لن يفرض سياسة CSP في الواقع.