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

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

إذا عرفت:

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

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

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

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

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

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

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

CDN URLs should be computed and included in the CSP by default. Could you also provide (or try comparing) the actual CSP served in the header and the source of the blocked assets?

6 إعجابات

Here is the header:

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:

Here are the ENV variables inside the container:

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

Here is the CDN URL from discourse.conf:

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

and rails:

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

And here is the URL for one of the assets that won’t load: https://lcsupport-92e2.kxcdn.com/brotli_asset/preload-store-d32dcf974dddcac742f8a7a6aa7fcd686185920b201029d0ecb2b85527ef9034.js

إعجابَين (2)

So we have this in the CSP

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

But the actual address is

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

The relevant CSP code:

We prioritize using DISCOURSE_S3_CDN_URL for assets when available. This aligns with the CDN asset URL generation.

@pfaffman Does GlobalSetting.use_s3? return true for your site?

I wonder if we need an additional GlobalSetting.use_s3? check here. Does having GlobalSetting.s3_cdn_url necessarily imply GlobalSetting.use_s3?? I’m a bit hazy with asset genereation / S3 CDN now :sweat_smile: could someone more familiar with it also take a look? Thanks!

7 إعجابات

Well, I tried setting use_s3 and then rake assets:precompile and there’s no change.

I’ve somewhere else had this issue where there was confusion about whether assets were in s3 or local (or their CDN mirrors).

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