سياسة أمان المحتوى تستخدم الآن 'strict-dynamic'

منذ v3.3.0.beta1، يطبق Discourse سياسة أمان المحتوى (CSP) “strict-dynamic”. سيلغي هذا الحاجة إلى تكوين CSP يدويًا، وسيحسن بشكل كبير التوافق مع الأدوات الخارجية مثل مديري العلامات والإعلانات.

بصفتك مسؤول موقع، لا تحتاج إلى القيام بأي شيء. سيتم تطبيق التغيير تلقائيًا، وستستمر البرامج النصية الخارجية التي تستخدمها في العمل.

لا يلزم إجراء تغييرات على السمات. قد تحتاج مجموعة صغيرة من الإضافات [1] إلى تعديل بسيط للتوافق مع هذا التغيير (مثل 1، 2).

يمكن للمنتديات التي قامت سابقًا بتعطيل CSP للتوافق مع البرامج النصية الخارجية الآن إعادة تمكينها دون أي مشاكل أو جهد في التكوين.

للتفاصيل التقنية، تحقق من هذا الموضوع:

في الوقت الحالي، لا يزال من الممكن العودة إلى النظام القديم عن طريق تعطيل إعداد الموقع “content security policy strict dynamic”. إذا كان لديك أي سبب للقيام بذلك، فيرجى إخبارنا!


منذ v3.3.0.beta3، جعلنا الكلمة المفتاحية “strict-dynamic” جزءًا إلزاميًا من CSP الخاص بنا. تمت إزالة إعداد الموقع “content security policy strict dynamic” وتم تحديث إعداد الموقع “content security policy script src” لتخزين القيم الصالحة فقط.

للمسؤولين، يجب أن تكون قادرًا على العثور على القيمة السابقة لإعداد الموقع “content security policy script src” من سجلات إجراءات الموظفين في موقعك (https://<site_url>/admin/logs/staff_action_logs?filters=%7B%22action_name%22%3A%22change_site_setting%22%2C%22action_id%22%3A3%2C%22subject%22%3A%22content_security_policy_script_src%22%7D - استبدل <site_url> بعنوان URL الأساسي لموقعك).


  1. تقنيًا: تلك التي تقدم عناصر <script> عبر register_html_builder أو قالب erb ↩︎

26 إعجابًا

كيف يمكنني تكوين 'unsafe-eval' بعد هذا التغيير كما كان من قبل؟

إعجاب واحد (1)

لا يوجد تغيير هناك - لا يزال بإمكانك إضافة ‘unsafe eval’ (مع علامات الاقتباس) إلى إعداد الموقع content security script src.

3 إعجابات

لقد رأيت أن وصف إعداد content security script src ينص على أن تمكين content_security_policy_strict_dynamic سيتجاهل هذا الإعداد، لذلك جئت إلى هنا للاستشارة.

3 إعجابات

يقول الوصف

\u003e سيتم تجاهل مصادر المضيف عند تمكين content_security_policy_strict_dynamic.

الجزء المهم هناك هو “مصادر المضيف”. ‘unsafe-inline’ ليس مصدر مضيف، لذا لا يزال مدعومًا.

ومع ذلك، أتفق تمامًا على أن هذا مربك. بالنظر إلى نجاح طرح strict-dynamic، نخطط لإزالة النظام القديم. بمجرد القيام بذلك، يمكننا إزالة جميع مصادر المضيف من القائمة تلقائيًا، وستكون الأمور أبسط بكثير للمسؤولين. :rocket:

5 إعجابات

حسناً، شكراً للتوضيح.

4 إعجابات

ديفيد،

بعض التوضيحات فقط.

يفترض أن هذا النظام الجديد يعمل بشكل جيد مع:

  • البرامج النصية المضمنة
  • مصادر البرامج النصية الكاملة المستضافة محليًا

ولكن ماذا عن الحالة التي تم فيها استدعاء البرامج النصية عن بُعد باستخدام “loadScript” وعنوان URL الكامل عن بُعد؟

صححني إذا كنت مخطئًا، لكنني لا أعتقد أن هناك طريقة جيدة للتعامل مع هذه الحالة؟

إذًا، هل هذا يعني أنه في تلك الحالات نحتاج بدلاً من ذلك إلى الاعتماد على:

  • نقل هذا الاستدعاء إلى برنامج نصي مضمن أو
  • تنزيل المصدر الكامل كأصل سمة؟

بالنسبة لحالة البرنامج النصي المضمن الأولى، لا أعتقد أن هناك طريقة لضمان تحميل البرنامج النصي قبل استخدام عناصره؟ (كما يمكنك القيام به ضمن .then بعد loadScript)

إعجابَين (2)

يجب أن يعمل strict-dynamic مع البرامج النصية البعيدة التي تم تحميلها عبر loadScript. في الواقع، كان هذا هو السبب الرئيسي للتبديل: لم نعد بحاجة إلى سرد كل عنوان URL لبرنامج نصي خارجي مسبقًا. هذا جيد بشكل خاص للأشخاص الذين يعرضون إعلانات، والتي غالبًا ما تجلب الكثير من البرامج النصية البعيدة.

هل ترى أخطاء مع loadScript؟

3 إعجابات

كنت أرى بعض الأخطاء، ولكن قد لا يكون ذلك بسبب هذا السبب. دعني أرى ما إذا كان بإمكاني العثور على مثال.

كنت أجهز نفسي بشكل أساسي لترقية مستقرة أعرف أنها تتضمن loadScript والبرامج النصية البعيدة.

هل يمكنك أن تتحملني وتشرح كيف يتم “مصادقة” البرامج النصية البعيدة التي يتم استدعاؤها عشوائيًا داخل الكود باستخدام loadScript بواسطة وضع CSP الديناميكي؟ هل هناك أي سحر يحدث؟

3 إعجابات

نعم!

لدى MDN شرح جيد وأمثلة.

يعبر تعبير المصدر 'strict-dynamic' عن أن الثقة الممنوحة صراحةً لبرنامج نصي موجود في العلامة، عن طريق إقرانه برقم عشوائي (nonce) أو تجزئة (hash)، سيتم نشرها لجميع البرامج النصية التي تم تحميلها بواسطة هذا البرنامج النصي الجذر.

لذلك، طالما أن البرنامج النصي الأصلي موثوق به (عبر رقم عشوائي)، فإن المتصفح يسمح له بتحميل أي برامج نصية أخرى دون قيود. وبعد ذلك، نظرًا لأن هذه البرامج النصية موثوق بها، يمكنها تحميل المزيد!


هناك تحذير واحد، وهو أن البرامج النصية لا يمكن أن تكون “مُدرجة في المحلل”. هذا يمنع استخدام strict-dynamic للاستغلال في هجمات XSS.

لذلك، على سبيل المثال، سيكون هذا “مُدرجًا في المحلل” وسيتم حظره:

document.head.appendChild("<script src='https://example.com/xss-attempt.js' />");

ولكن، إنشاء عنصر البرنامج النصي برمجيًا لا يتضمن تحليل HTML، ومن غير المرجح أن يكون ناقلًا لهجمات XSS، ولذلك يُسمح به:

const script = document.createElement("script");
script.src = "https://example.com/script.js"
document.head.appendChild(script);

^^ هذا هو أساسًا كيف يعمل loadScript()

3 إعجابات

رابط رائع.

حسنًا، لقد فهمت تقريبًا، شكرًا لك!

إذًا، هل يتم تضمين الـ nonce أيضًا في علامات الـ script التي تم إنشاؤها بواسطة loadScript؟

إعجابَين (2)

لا، يتم تضمين الـ nonce فقط في علامة النص البرمجي الأصلية التي تم إنشاؤها بواسطة Rails (على سبيل المثال، نصوص برمجية أساسية أو إضافات أو سمات).\n\nهذا يعني أن التعليمات البرمجية الأساسية/الإضافات/السمات موثوق بها، ويُسمح لها بإدراج أي نصوص برمجية أخرى. لا يلزم وجود nonce هنا - يعرف المتصفح النص البرمجي الذي قام بالإدراج، ويعرف بشكل سحري أنه يمكن الوثوق به.

4 إعجابات

ديفيد، مرة أخرى، شكراً لوقتك!

4 إعجابات

تم تقسيم 6 مشاركات إلى موضوع جديد: خطأ CSP عند إضافة نص برمجي عبر مكون سمة