تساعد سياسة أمان المحتوى (CSP) في ضمان أنّ مالك الموقع الإلكتروني يثق بأي محتوى يتم تحميله في الصفحة. تعمل سياسات أمان المحتوى على تخفيف هجمات النصوص البرمجية على المواقع الإلكترونية (XSS) لأنّها يمكنها حظر النصوص البرمجية غير الآمنة التي يحقنها المهاجمون. ومع ذلك، يمكن بسهولة تجاوز سياسة CSP إذا لم تكن صارمة بما يكفي. اطّلِع على مقالة الحدّ من الهجمات التي تستخدم النصوص البرمجية على المواقع الإلكترونية (XSS) من خلال سياسة أمان المحتوى (CSP) الصارمة للحصول على مزيد من المعلومات. يجمع Lighthouse خدمات إدارة المحتوى في خدمة مقارنة الأسعار (CSP) التي يتم فرضها على المستند الرئيسي، ويُبلغ عن المشاكل من أداة تقييم خدمات إدارة المحتوى في خدمة مقارنة الأسعار (CSP Evaluator) إذا كان من الممكن تجاوزها.
الممارسات المطلوبة لخدمات إدارة الخدمات السحابية (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)، يجب أن تسمح هذه السياسة بالنصوص البرمجية كل على حدة باستخدام الأرقام الخاصة أو أجزائها، واستخدام 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 إذا كان ذلك ممكنًا. سيؤدي حقن المحتوى قبل العلامة الوصفية إلى تجاوز "إطار عمل حماية المحتوى". بالإضافة إلى ذلك، لا تتوفّر العلامات frame-ancestors وsandbox وإعداد التقارير في مقدّمي خدمات المحتوى في العلامات الوصفية.
التأكّد من توافق سياسة CSP مع الإصدارات القديمة
لا تتوافق بعض المتصفّحات مع وظائف nonces/hashes في 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: في المتصفّحات الحديثة بسبب nonce وstrict-dynamic. لمزيد من المعلومات عن استخدام سياسة خدمة محتوى صارمة، يمكنك الاطّلاع على دليل سياسة خدمة المحتوى الصارمة.
يمكنك التحقّق من خدمة إدارة خدمات المحتوى (CSP) بحثًا عن عمليات التحايل المحتمَلة باستخدام Lighthouse وأداة تقييم خدمة إدارة خدمات المحتوى (CSP). إذا كنت تريد اختبار سياسة أمان محتوى جديدة بدون المخاطرة بتعطُّل الصفحات الحالية، حدِّد سياسة أمان المحتوى في وضع "التقارير فقط" باستخدام Content-Security-Policy-Report-Only كاسم العنوان. سيؤدي ذلك إلى إرسال انتهاكات سياسة CSP إلى أي وجهات إعداد تقارير أعددتها باستخدام report-to وreport-uri، ولكنّه لن يفرض سياسة CSP في الواقع.