تحميلات آمنة

[martin (Martin Brennan)]

تمت إضافة ميزة التحميلات الآمنة في إصدار Discourse 2.4 الصادر في فبراير، وهي توفر درجة أعلى من الأمان لجميع الملفات المرفوعة (صور، فيديو، صوت، نصوص، ملفات PDF، ملفات مضغوطة، وغيرها) ضمن مثيل Discourse.

المتطلبات الأساسية

يجب أن يكون لديك تحميلات S3 مفعلة في موقعك، وهو ما يتطلب تعبئة الإعدادات التالية:

• معرف مفتاح الوصول S3
• المفتاح السري للوصول S3
• منطقة S3
• سلة رفع S3

كما يجب أن تستخدم سلة S3 لا تحتوي على سياسة سلة عامة، وتحتاج إلى التأكد من أن جميع الملفات المرفوعة مسبقًا تحتوي على قائمة تحكم في الوصول (ACL) عامة للقراءة (public-read) في S3. راجع قسم “تفعيل التحميلات الآمنة” أدناه.

بعد استيفاء هذه المتطلبات الأساسية، يمكنك تفعيل إعداد الموقع “التحميلات الآمنة”.

تفعيل التحميلات الآمنة

هنا تنبثق التنانين

هذه ميزة متقدمة، والدعم خارج مستوى المؤسسة لدينا سيكون محدودًا للغاية. قم بتفعيل التحميلات الآمنة فقط إذا كنت مستخدمًا خبيرًا.

---

لتفعيل التحميلات الآمنة، يجب عليك اتباع الخطوات التالية:

1. تأكد من إعداد تحميلات S3.
2. احفظ ما إذا كانت سلة S3 الخاصة بك تحتوي على سياسة سلة عامة. إذا كانت كذلك، فهناك خطوة إضافية مطلوبة (الخطوة 4).
3. قم بتشغيل مهمة uploads:sync_s3_acls باستخدام Rake. سيضمن ذلك أن جميع ملفاتك المرفوعة تحتوي على قائمة تحكم في الوصول (ACL) الصحيحة في S3. هذا مهم؛ فإذا قمت بالخطوة 4 قبل هذه الخطوة، قد تصبح بعض الملفات غير قابلة للوصول في منتداك.
4. احذف سياسة السلة العامة من سلتك إذا كانت موجودة في الخطوة 1.
5. قم بتفعيل إعداد الموقع “التحميلات الآمنة”. يمكنك أيضًا تفعيل إعداد الموقع “منع المستخدمين المجهولين من تنزيل الملفات” لمنع المستخدمين المجهولين من تنزيل المرفقات من المنشورات العامة. قد يتم تصنيف أي ملفات مرفوعة من هذه اللحظة فصاعدًا على أنها آمنة اعتمادًا على الشروط أدناه.
6. إذا كنت ترغب في تحليل جميع الملفات المرفوعة سابقًا وتصنيفها كآمنة محتملة، قم بتشغيل مهمة uploads:secure_upload_analyse_and_update باستخدام Rake.

ملاحظة حول سياسة سلة S3

يجب عليك التأكد من أن السلة التي تقوم برفع الملفات إليها لا تحتوي على سياسة سلة عامة. ستكون السياسة العامة للسلة مشابهة لهذا:

{
    "Version": "2012-10-17",
    "Id": "ComputedBucketPolicy",
    "Statement": [
        {
            "Sid": "AllowWorldRead",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

الجزء المهم هنا هو أننا نسمح لـ * (الجميع) بالحصول على الكائنات (GetObject)، مما يعني السماح لأي شخص بتنزيل أي شيء في السلة. ستظهر هذه التسمية أيضًا ما إذا كانت السياسة عامة:

لا يجب ألا يتم تعديل الإعدادات هنا. الصورة أدناه تمثل الحالة المثالية لعلامة “حظر الوصول العام”:

ما الذي تفعله

بمجرد تفعيل التحميلات الآمنة، سيتم تصنيف أي ملف يتم رفعه عبر المصنف (Composer) على أنه آمن أو غير آمن بناءً على المعايير التالية:

• إذا كان إعداد الموقع “مطلوب تسجيل الدخول” مفعلاً، فسيتم تصنيف جميع الملفات المرفوعة على أنها آمنة، ولن يتمكن المستخدمون المجهولون من الوصول إليها.
• إذا قمت برفع شيء ما داخل رسالة شخصية، فسيتم تصنيفه على أنه آمن.
• إذا قمت برفع شيء ما داخل موضوع موجود داخل فئة خاصة، فسيتم تصنيفه على أنه آمن.

سيكون الملف المرفوع في S3 لديه قائمة تحكم في الوصول (ACL) خاصة، لذا فإن الروابط المباشرة إلى الملف في S3 ستؤدي إلى خطأ 403 (مرفوض). سيتم الوصول إلى أي من التحميلات الآمنة جميعًا عبر عنوان URL موقع سلفي (presigned URL) في S3. ومع ذلك، سيظل هذا مخفيًا عن مستخدميك؛ فإذا كان الرفع آمنًا، سيتم أي مرجع إليه عبر عنوان URL /secure-uploads/ الخاص بـ Discourse.

الأذونات والتحكم في الوصول

سيحدد عنوان URL /secure-uploads/ ما إذا كان المستخدم الحالي مسموحًا له بالوصول إلى الوسائط وخدمتها إذا كان مسموحًا بذلك. عند إنشاء الرفع، سيتم تعيين المنشور الذي ظهر فيه لأول مرة على أنه “منشور التحكم في الوصول”، وستكون جميع الأذونات مبنية على ذلك المنشور.

• إذا كان إعداد الموقع “مطلوب تسجيل الدخول” مفعلاً، فسيحصل المستخدمون المجهولون دائمًا على خطأ 404 عند محاولة الوصول إلى العنوان.
• عند الوصول إلى وسائط يكون منشور التحكم في الوصول لها رسالة شخصية، يجب أن يكون المستخدم جزءًا من موضوع الرسالة الشخصية هذه للوصول إلى الوسائط، وإلا سيحصل المستخدم على خطأ 403.
• عند الوصول إلى وسائط يكون منشور التحكم في الوصول لها داخل موضوع موجود داخل فئة خاصة، يجب أن يكون لدى المستخدم حق الوصول إلى تلك الفئة للوصول إلى الوسائط، وإلا سيحصل المستخدم على خطأ 403.

نسخ عناوين URL /secure-uploads/ ونقلها بين المنشورات والمواضيع أمر غير حكيم، حيث سيكون للمستخدمين المختلفين مستويات وصول مختلفة داخل منتديات Discourse الخاصة بك. يجب دائمًا إنشاء التحميلات الجديدة عبر المصنف (Composer). ستحترم الصور المضمنة (Oneboxes) والصور المرتبطة مباشرة (hotlinked) أيضًا قواعد التحميلات الآمنة. لا تتأثر التحميلات الخاصة بالإعدادات، والرموز التعبيرية (emojis)، وتحميل السمات (theme uploads) بـ التحميلات الآمنة، حيث يجب أن تكون عامة.

إذا تم حذف منشور التحكم في الوصول، فلن يكون الرفع المرفق قادرًا على الوصول إليه بعد الآن.

نقل المنشورات التي تحتوي على تحميلات آمنة

إذا قمت بنقل “منشور تحكم في الوصول” بين سياقات أمنية مختلفة، فقد يتغير الرفع المرفق ليصبح آمنًا أو غير آمن. هذه هي الحالات التي قد تغير أمان الرفع:

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

التحميلات الآمنة في رسائل البريد الإلكتروني

تم تمكين تضمين الصور الآمنة في رسائل البريد الإلكتروني افتراضيًا. يمكنك تكوين إعدادات الموقع هذه لمزيد من التحكم:

• secure_uploads_allow_embed_images_in_emails : قم بتعطيل هذا لإخفاء الصور الآمنة في رسائل البريد الإلكتروني.
• secure_uploads_max_email_embed_image_size_kb : الحد الأقصى لحجم الصورة الآمنة التي سنقوم بتضمينها، الافتراضي 1 ميجابايت، حتى لا تصبح رسالة البريد الإلكتروني كبيرة جدًا. الحد الأقصى هو 10 ميجابايت. يعمل بالتزامن مع email_total_attachment_size_limit_kb.

سيتم إضافة الصور الآمنة كمرفقات للبريد الإلكتروني وتضمينها باستخدام تنسيق عنوان URL cid: لأن دعم عناوين URL base64 في عملاء البريد الإلكتروني لا يزال غير مستقر.

إذا لم يكن لديك secure_uploads_allow_embed_images_in_emails مفعلاً، أو إذا بدأت الصور في تجاوز حدود الحجم، فستظهر لك هذه الرسالة بدلاً من الصور الآمنة (كما هو الحال مع الصوت والفيديو الآمنين غير المضمنين):

العملاء المستضافون

في الوقت الحالي، تتوفر التحميلات الآمنة لعملاء خطة المؤسسة فقط. يرجى التواصل معنا لمزيد من التفاصيل.

[codinghorror (Jeff Atwood)]

There should probably be a lot of warnings around this feature @martin as it is an ADVANCED thing, not for the faint of , and there is a limit to how much we will support it outside our enterprise tier. Bring your own expertise…

[sam (Sam Saffron)]

The security was never intended to cover avatars, this is not a use case we planned for

[martin (Martin Brennan)]

Advisory: Setting the S3 bucket to “Block all public access” is not correct

@genachka @AntiMetaman @Hugh_Roberts @znedw @Thamer

I am going to amend the OP. After talking with our infrastructure team member @schleifer I confirmed that I was incorrect to advise that the “Block all public access” setting should be enabled. Turn this off for your S3 bucket and then run uploads:sync_s3_acls to ensure the ACLs are correct and then try again with the custom avatars.

An additional thing that everyone needs to make sure is that the bucket you are uploading to does not have a Public bucket policy. A public bucket policy will have something like this:

{
    "Version": "2012-10-17",
    "Id": "ComputedBucketPolicy",
    "Statement": [
        {
            "Sid": "AllowWorldRead",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

The important part here is that we are Allowing * to GetObject, which is saying let anyone download anything in the bucket. This label will also show if the policy is Public:

My apologies for this. @AntiMetaman neither @schleifer or I could reproduce this error:

@AntiMetaman

However, now if I try to upload anything it will give me this error:

It would be helpful if you could provide more information about your S3/AWS setup.

[AntiMetaman]

@martin Thanks. My issue wasn’t that error but anons unable to access the page. If I set the upload bucket to private, then I dont have that error anymore and I can upload. I don’t have login as required on my site.

I never had the “Block all public access” enabled for my bucket settings in the first place. If you are telling me that anons should still be able to access a topic, read it, and view secure images - then I can try this again. If adding security to media prevents anons from seeing those images, then I’d rather just secure attachments only.

If it helps, I am using BackBlaze B2 with BunnyCDN. My upload bucket settings are currently public:

[martin (Martin Brennan)]

@genachka

My concern is that having public access set on an S3 bucket is something drilled in to us as a very bad idea. So I want to double confirm that the secured uploads will be safe with this setting? So based on your current recommendation, the premise is that for the avatars to be accessible for upload by the user/admin – public access is required and the secured uploads are protected because they each get explicitly set an ACL to prevent being accessed publicly and that running uploads:sync_s3_acls will update the current ones there and any new uploads in topics will at that time have the necessary ACL set?

This is the gist of it yes. Anything that needs to be private will have a private ACL set and is inaccessible unless a presigned URL is used. Note that the bucket policy is not Public. And yes all those “Block public access” settings should be unchecked. If you are interested in how we determine whether an upload is secure all of the rules are here discourse/lib/upload_security.rb at main · discourse/discourse · GitHub and here discourse/app/models/post.rb at main · discourse/discourse · GitHub

@AntiMetaman

I never had the “Block all public access” enabled for my bucket settings in the first place. If you are telling me that anons should still be able to access a topic, read it, and view secure images - then I can try this again. If adding security to media prevents anons from seeing those images, then I’d rather just secure attachments only.

If it helps, I am using BackBlaze B2 with BunnyCDN. My upload bucket settings are currently public:

I am not familiar with BackBlaze sorry. I am not sure how the settings shown would translate to a bucket policy. Basically you do not want Public as the bucket policy, and you do not want to turn on “Block all public access”. That way we can set private and public ACLs appropriately. If you do not have login required then any upload made in a topic that is not in a PM or private category should be public and accessible by anons. The images should not be secure in a topic accessible by anons.

[riking (Kane York)]

The secure media implementation is not compatible with Backblaze. Do they support pre-signed URLs?

[AntiMetaman]

@riking

Yes, pre-signed URLs are supported: Does the B2 S3 Compatible API support Pre-Signed URLs? – Backblaze Help

@martin

Yes, changing the bucket from public to private does this. I did this and it allowed me to upload, but as an anon I couldn’t view topics.

[genachka]

@martin thanks for the clarification. And I can confirm that with leaving the setting on the S3 as in my screenshot as Public and everything unchecked (and suggested by you) that the custom avatars / profile images are finally working while the topic secured uploads remain working as well. Thank you!

[martin (Martin Brennan)]

I merged this PR this week and I am adding these details to the OP:

FEATURE: Allow email image embed with secure media

---

If you want to allow embedding secure images in emails you can configure these site settings:

• secure_media_allow_embed_images_in_emails : If enabled we will embed secure images in emails instead of redacting them.
• secure_media_max_email_embed_image_size_kb : The cap to the size of the secure image we will embed, defaulting to 1mb, so the email does not become too big. Max is 10mb. Works in tandem with email_total_attachment_size_limit_kb .

The secure images will be added as email attachments and embedded using the cid: url format because base64 URL support in email clients is still flaky.

If you don’t have secure_media_allow_embed_images_in_emails enabled, or if the images start to exceed the size limits, then this is what you will see in place of secure images (also secure audio and video which is not embedded):

[martin (Martin Brennan)]

Further addendum to my previous post; from this PR:

FEATURE: Default allow embed secure images in email to true

We now enable secure media image embedding by default.

[gerald]

After setting up secure media uploads (following the OP guide) everything works well (attachments, images…) except uploads that are not topic attachments (like site logo, profile avatar) those raise “Access Denied” pop up in Discourse.
Did i mess up some setting?

[michaeld (Michael - Communiteq)]

Please read the topic, your issue is addressed a few posts above this one.

[gerald]

I read everything carefully. Please let me know what exactly you mean by few posts above. I don’t see this issue.
Edit:
Trying to read between the lines here, i see that this thread used to be longer but some key replies were deleted from it, i see references to replies that don’t exist and mentions of screenshots that don’t appear in the thread.
If I understand correctly though, the recommendation is to set S3 bucket to NOT block any public access at all. I just want to confirm that, and ask if it is safe?

[michaeld (Michael - Communiteq)]

Correct.

The original post is indeed gone but the problem and solution are still there

@genachka

the premise is that for the avatars to be accessible for upload by the user/admin – public access is required

[gerald]

I noticed a bug with using secure media and Knowledge Base Plugin
Links to attachments in the knowledge base fail to open (redirect to 404 page) unless forced to be opened in a new window.
The extra weird thing is that the very same attachment can be opened without issue from the Discourse topic associated with the knowledge base item.

Edit:
The same bug happens when someone is copying a link to an attachment from one reply to another. the link is the exact same one naturally, but it only works from the original reply, unless forced to be opened in a new window.

[sbernhard (Bernhard Suttner)]

What about secure media if s3 is not used?
Currently it looks like that, if you have the direct link to the uploaded file, you can download that file without login. Which is like a security issue then…

[RGJ (Richard - Communiteq)]

@sbernhard

What about secure media if s3 is not used?

Secure media requires s3.
This entire feature was developed to make it impossible to share and access direct links.

[mcaruanagalizia (Matthew Caruana Galizia)]

هذه ميزة ممتازة. شكرًا لكم على تطويرها. لا يدعم Minio، وهو بديل مجاني جاهز للاستخدام بدلاً من S3، قوائم التحكم بالوصول (ACLs) ولن يدعمها أبدًا. حججتهم، وهي حجة جيدة، هي أن قوائم التحكم بالوصول ليست ميزة مفيدة وتؤثر سلبًا على الأداء لأنها تتطلب عملية كتابة ثانية. سيعمل تحميل الوسائط الآمن مع Discourse - ستفشل مهمة uploads:secure_upload_analyse_and_update في الخطوة الأخيرة، ولكن يبدو أنه يمكنك تجاهل ذلك. مع ذلك، هل هناك أي سبب يجعل Discourse يقوم بمكالمات لقوائم التحكم بالوصول على الإطلاق؟

[martin (Martin Brennan)]

@mcaruanagalizia

ومع ذلك، هل هناك أي سبب يجعل Discourse يقوم باتصالات ACL على الإطلاق؟

نعم، لأن خزانة S3 خاصة بناءً على الإعدادات في المنشور الأصلي، يجب تعيين ACL للتحميلات غير الآمنة إلى عام، وستكون التحميلات الآمنة ذات ACL خاص بحيث يمكن الوصول إلى عنوان URL الخاص بـ S3 مباشرة. لا أعتقد أن لدينا خططًا في الوقت الحالي لتعديل طريقة عمل هذا؛ أعتقد أن هناك قدرًا كبيرًا من العمل المطلوب لتجنب استخدام ACLs على الإطلاق لاستبدال S3.