مختبر يفرز مخالفات سياسة المتصفح قبل فرضها: مشاريع تخرج أمن الويب

إضافة سياسة Content Security Policy واسعة قد تمنع ملفاً تحتاجه الواجهة، بينما فرض سياسة ضعيفة لا يحقق هدفاً واضحاً. لذلك يبدأ مشروع تخرج أمن الويب بوضع مراقبة على صفحات اختبار قبل محاولة الحظر. تشرح مسودة W3C الحالية لـCSP Level 3 آلية السياسات وContent-Security-Policy-Report-Only التي ترصد الأثر بدلاً من فرض المنع. الوثيقة Working Draft كما هو موضح في حالة نشرها؛ راجع النسخة وحالة كل ميزة قبل الاعتماد. المختبر المقترح يجمع بيانات اصطناعية محلياً ولا يرسل بلاغاً إلى خدمة حقيقية.

ابدأ بصفحات تملكها

أنشئ ثلاث صفحات محلية: صفحة بلا موارد خارجية، وصفحة تستدعي script محلياً مسموحاً، وصفحة تحتوي مورداً ممنوعاً عمداً مثل صورة من origin تجريبي غير موجود في allowlist. أضف حالة inline script لاختبار الفرق الذي يحدث عند تغيير السياسة. خزّن ملفات HTML وheaders في مجلد fixtures. لا تختبر على صفحة خارجية ولا تجعل المعمل يعدل رؤوس موقع قائم. ابدأ بتوجيه واحد أو اثنين حتى يستطيع الطالب تفسير سبب كل بلاغ بدلاً من قراءة تفاصيل كثيرة مختلطة.

حلل التقرير دون افتراض ثابت

احتفظ بالحقول المتاحة مثل effectiveDirective وblockedURL وdocumentURL وdisposition حين تظهر، لكن لا تفترض أن كل المتصفحات ترسل نفس البيانات أو أن كل تقرير يحتوي sample مفيداً. توضح مسودة CSP أن سياسة Report-Only ترصد الأثر بدلاً من فرض المنع. وتوفر Reporting API إطاراً لإرسال التقارير إلى endpoints معلنة في المتصفح. قد تختلف التفاصيل بحسب دعم المتصفح وإصداره، لذلك سجل user agent ووقت الاختبار مع عينة البلاغ من بيئة المختبر.

صنف النتائج إلى قرار قابل للمراجعة

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

مثال يجمع صورة مسموحة وبلاغاً متوقعاً

جهز fixture بها صورة محلية وسكربت من مجلد الموقع، ثم سياسة Report-Only تسمح بهذه المصادر. يجب ألا يولد التحميل المشروع مخالفة لتوجيه img-src أو script-src. أضف صورة من نطاق محلي ثانٍ لا تسمح به القائمة؛ ينبغي ظهور مخالفة مقيدة بهذا السيناريو. سجل disposition على أنه تقرير فقط ولا تكتب أن المتصفح حظر الصورة. بعد ذلك انقل الصورة إلى المصدر المسموح وأعد الاختبار؛ ينبغي اختفاء البلاغ المرتبط بها. هذا المثال يختبر أن العارض لا يساوي بين Report-Only والتنفيذ الفعلي.

قياس أثر السياسة قبل تغييرها

لكل سياسة، احفظ قائمة الوظائف التي يجب أن تعمل: تحميل الخط، فتح صفحة، إرسال نموذج محلي، وتشغيل تفاعل JavaScript. قارن مجموعة البلاغات في وضع report-only بعدد الوظائف الناجحة في نسخة enforcement منفصلة على localhost. لا ترفع السياسة من المختبر إلى خادم عام. استخدم اختبارات WPT الخاصة بـCSP لمقارنة الحالات القياسية، مع كتابة أن نجاح fixture لا يعني دعماً موحداً لكل المتصفحات أو إغلاقاً شاملاً لثغرات حقن النصوص.

خفف المعلومات الحساسة في السجلات

قد تتضمن التقارير عنوان صفحة أو مورداً أو تفاصيل سياق لا تريد الاحتفاظ بها طويلاً. في النسخة الجامعية، استخدم نطاقاً محلياً وبيانات وهمية، واحذف query strings قبل العرض، وضع سياسة احتفاظ قصيرة. لا ترسل البلاغات من جهاز طالب إلى endpoint خارجي دون إعداد واضح، ولا تضع قيمة كوكي أو محتوى مستخدم في fixture. يركز المشروع على triage للسياسة، وليس منصة جمع telemetry واسعة.

المخرجات والحدود

سلّم مجموعة صفحات اختبار وسياسة مرشحة وparser للتقارير وتصنيفاً مع الأسباب ومصفوفة تقيس وظيفة كل صفحة قبل/بعد. تشير مسودة CSP3 إلى أن report-uri قديم وتقترح report-to مع مراعاة توافق المتصفحات؛ لا تعتمد ميزة مسودة أو endpoint واحداً كحقيقة ثابتة. المختبر لا يثبت خلو الموقع من XSS ولا يراجع كوداً لم يُختبر. يمكن طرحه ضمن مشاريع تخرج في أمن الويب وربطه بخدمة تطوير المواقع والتطبيقات. الانتقال إلى سياسة enforced قرار منفصل مبني على مراجعة فعلية، لا زر أخضر في مشروع تجريبي.