هل يسبب DISCOURSE_CDN_URL انتهاكات لسياسة أمان المحتوى؟

الدعم تثبيت
1

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

إذا عرفت:

  DISCOURSE_CDN_URL: https://lcsupport-92e2.kxcdn.com

في قسم env: ضمن ملف yml الخاص بي في إعداد متعدد المواقع قياسي إلى حد ما، فإن جميع عناوين CDN يتم رفضها بواسطة المتصفح بسبب خطأ في سياسة أمان المحتوى (CSP).

تُفيد رسالة content security policy script src بأن: “مصادر السكربت الإضافية المسموح بها. يتم تضمين المضيف الحالي وCDN افتراضيًا. راجع التخفيف من هجمات XSS باستخدام سياسة أمان المحتوى”. لكن عندما أعرف هذا (أو أضيفه/أزيله من discourse.conf وأعيد تشغيل sv restart unicorn)، أحصل على ما يلي:

image
image811×296 62.4 KB

حتى مع تعيين content security policy report only إلى true، لا يزال الموقع لا يعمل.

يبدو أن تعطيل content_security_policy أو إضافة عنوان URL الخاص بـ CDN إلى content security policy script src ضروريان لكي يقوم المتصفح بتحميل الأصول.

هنا ملف yml الخاص بي.

2

يجب حساب عناوين URL الخاصة بشبكة توصيل المحتوى (CDN) وتضمينها في سياسة أمان المحتوى (CSP) بشكل افتراضي. هل يمكنك أيضًا تقديم (أو محاولة مقارنة) سياسة أمان المحتوى (CSP) الفعلية المقدمة في الرأس ومصدر الأصول المحظورة؟

3

إليك الرأس:

content-security-policy-report-only: base-uri 'none'; object-src 'none'; script-src 'report-sample' 
https://support.literatecomputing.com/logs/ 
https://support.literatecomputing.com/sidekiq/ 
https://support.literatecomputing.com/mini-profiler-resources/ 
https://abedmulti-92e2.kxcdn.com/uploads/assets/ 
https://abedmulti-92e2.kxcdn.com/uploads/brotli_asset/ 
https://support.literatecomputing.com/extra-locales/ 
https://lcsupport-92e2.kxcdn.com/highlight-js/ 
https://lcsupport-92e2.kxcdn.com/javascripts/ 
https://lcsupport-92e2.kxcdn.com/plugins/ 
https://lcsupport-92e2.kxcdn.com/theme-javascripts/ 
https://lcsupport-92e2.kxcdn.com/svg-sprite/ 
https://www.google-analytics.com/analytics.js 
https://tagmanager.google.com/ 
https://www.googletagmanager.com/; worker-src 'self' blob:

إليك متغيرات البيئة داخل الحاوية:

root@support-multi:/var/www/discourse# echo $DISCOURSE_S3_UPLOAD_BUCKET 
abed-multi/uploads
root@support-multi:/var/www/discourse# echo $DISCOURSE_S3_CDN_URL 
https://abedmulti-92e2.kxcdn.com/uploads

إليك عنوان URL الخاص بشبكة CDN من ملف discourse.conf:

cdn_url = 'https://lcsupport-92e2.kxcdn.com'

وإليك rails:

[1] pry(main)> GlobalSetting.cdn_url
=> "https://lcsupport-92e2.kxcdn.com"

وإليك عنوان URL لأحد الأصول التي لن يتم تحميلها: https://lcsupport-92e2.kxcdn.com/brotli_asset/preload-store-d32dcf974dddcac742f8a7a6aa7fcd686185920b201029d0ecb2b85527ef9034.js

4

إذن لدينا هذا في سياسة أمن المحتوى (CSP)

https://abedmulti-92e2.kxcdn.com/uploads/assets/
https://abedmulti-92e2.kxcdn.com/uploads/brotli_asset/
# أي: DISCOURSE_S3_CDN_URL + /brotli_asset/

لكن العنوان الفعلي هو

https://lcsupport-92e2.kxcdn.com/brotli_asset/preload-store-d32dcf974dddcac742f8a7a6aa7fcd686185920b201029d0ecb2b85527ef9034.js
# أي: DISCOURSE_CDN_URL + /brotli_asset/...

الكود ذي الصلة في سياسة أمن المحتوى (CSP):

نحن نعط الأولوية لاستخدام DISCOURSE_S3_CDN_URL للأصول عند توفره. وهذا يتوافق مع توليد عناوين أصول CDN.

@pfaffman هل تُرجع GlobalSetting.use_s3؟ قيمة true لموقعك؟

أتساءل عما إذا كنا بحاجة إلى إضافة تحقق من GlobalSetting.use_s3؟ هنا. هل وجود GlobalSetting.s3_cdn_url يعني بالضرورة GlobalSetting.use_s3؟؟ أنا غير متأكد قليلاً بشأن توليد الأصول / CDN لـ S3 الآن :sweat_smile: هل يمكن لشخص أكثر دراية بذلك إلقاء نظرة أيضًا؟ شكرًا!

5

حسنًا، لقد حاولت تعيين use_s3 ثم تشغيل rake assets:precompile لكن لا يوجد أي تغيير.

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