Téléversements Sécurisés

[martin (Martin Brennan)]

Ajouté dans la version 2.4 de Discourse en février, la fonctionnalité Téléchargements Sécurisés offre un niveau de sécurité accru pour TOUS les fichiers téléchargés (images, vidéos, audio, texte, PDF, ZIP, etc.) au sein d’une instance Discourse.

Prérequis

Vous devez avoir activé les téléchargements S3 sur votre site, ce qui nécessite de remplir les paramètres suivants :

• Clé d’accès S3 (S3 access key id)
• Clé secrète d’accès S3 (S3 secret access key)
• Région S3
• Bac de téléchargement S3 (S3 upload bucket)

Vous devez également utiliser un bac S3 qui ne possède pas de politique de bac publique, et vous devez vous assurer que tous les téléchargements existants ont une ACL S3 de type public-read. Consultez la section « Activation des téléchargements sécurisés » ci-dessous.

Une fois ces prérequis satisfaits, vous pouvez activer le paramètre de site « téléchargements sécurisés ».

Activation des téléchargements sécurisés

ICÔNE DE DRAGON : ATTENTION AUX DANGERS

Il s’agit d’une fonctionnalité avancée et le support en dehors de notre offre Entreprise sera très limité. N’activez les téléchargements sécurisés que si vous êtes un utilisateur expert.

---

Pour activer les téléchargements sécurisés, vous devez suivre ces étapes :

1. Assurez-vous que les téléchargements S3 sont configurés.
2. Notez si votre bac S3 possède une politique de bac publique. Si c’est le cas, une étape supplémentaire est requise (étape 4).
3. Exécutez la tâche rake uploads:sync_s3_acls. Cela garantira que tous vos téléchargements ont la bonne ACL dans S3. C’est important ; si vous effectuez l’étape 4 avant celle-ci, certains téléchargements pourraient devenir inaccessibles sur votre forum.
4. Supprimez la politique de bac publique de votre bac si elle était présente à l’étape 1.
5. Activez le paramètre de site « téléchargements sécurisés ». Activez optionnellement le paramètre de site « empêcher les anonymes de télécharger des fichiers » pour empêcher les utilisateurs anonymes de télécharger des pièces jointes à partir de publications publiques. Tous les téléchargements effectués à partir de maintenant pourraient être marqués comme sécurisés selon les conditions ci-dessous.
6. Si vous souhaitez que tous les téléchargements soient rétrospectivement analysés et éventuellement marqués comme sécurisés, exécutez la tâche rake uploads:secure_upload_analyse_and_update.

Note sur la politique de bac S3

Vous devez vous assurer que le bac vers lequel vous téléchargez ne possède pas de politique de bac publique. Une politique de bac publique ressemblera à ceci :

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

La partie importante ici est que nous autorisons * à obtenir l’objet (GetObject), ce qui signifie que n’importe qui peut télécharger n’importe quoi dans le bac. Cette étiquette indiquera également si la politique est publique :

Les paramètres ici ne doivent pas être modifiés. L’image ci-dessous montre l’état idéal pour l’onglet « Bloquer l’accès public » :

Ce que cela fait

Une fois que vous avez activé les téléchargements sécurisés, tout fichier téléchargé via le compositeur sera marqué comme sécurisé ou non sécurisé selon les critères suivants :

• Si vous avez activé le paramètre de site « connexion requise », tous les téléchargements seront marqués comme sécurisés, et les utilisateurs anonymes ne pourront pas y accéder.
• Si vous téléchargez quelque chose dans un message privé, il sera marqué comme sécurisé.
• Si vous téléchargez quelque chose dans un sujet situé dans une catégorie privée, il sera marqué comme sécurisé.

Le téléchargement sur S3 aura une ACL privée, de sorte que les liens directs vers le fichier sur S3 renverront une erreur 403 accès refusé. Tout accès aux téléchargements sécurisés se fera via une URL signée S3. Cela sera cependant caché à vos utilisateurs ; si un téléchargement est sécurisé, toute référence à celui-ci sera faite via l’URL Discourse /secure-uploads/.

Permissions et contrôle d’accès

L’URL /secure-uploads/ déterminera si l’utilisateur actuel est autorisé à accéder au média et le servira s’il l’est. Lors de la création du téléchargement, la publication dans laquelle il apparaît en premier sera définie comme sa « publication de contrôle d’accès » et toutes les permissions seront basées sur cette publication.

• Si vous avez activé le paramètre de site « connexion requise », les utilisateurs anonymes recevront toujours une erreur 404 en accédant à l’URL.
• Si vous accédez à un média dont la publication de contrôle d’accès est un message privé, l’utilisateur doit faire partie de ce sujet de message privé pour accéder au média, sinon l’utilisateur recevra une erreur 403.
• Si vous accédez à un média dont la publication de contrôle d’accès est dans un sujet situé dans une catégorie privée, l’utilisateur doit avoir accès à cette catégorie pour accéder au média, sinon l’utilisateur recevra une erreur 403.

Copier les URL /secure-uploads/ entre des publications et des sujets est imprudent, car différents utilisateurs auront différents niveaux d’accès au sein de vos forums Discourse. Les nouveaux téléchargements doivent toujours être créés via le compositeur. Les Oneboxes et les images liées directement respecteront également les règles des téléchargements sécurisés. Les paramètres de site, les émojis et les téléchargements de thèmes sont non affectés par les téléchargements sécurisés, car ils doivent être publics.

Si une publication de contrôle d’accès est supprimée, le téléchargement attaché ne sera plus accessible.

Déplacement de publications avec des téléchargements sécurisés

Si vous déplacez une « publication de contrôle d’accès » entre différents contextes de sécurité, le téléchargement attaché peut éventuellement être changé en sécurisé ou non sécurisé. Voici les situations qui peuvent modifier la sécurité d’un téléchargement :

• Changer la catégorie d’un sujet. Cela parcourra tous les sujets du sujet et mettra à jour l’état de sécurité des téléchargements en conséquence.
• Changer un sujet entre un sujet public et un message privé. Cela fera la même chose que ci-dessus.
• Déplacer des publications d’un sujet vers un autre sujet nouveau ou existant. Cela exécutera la même opération que ci-dessus sur le sujet cible.

Téléchargements sécurisés dans les e-mails

L’intégration d’images sécurisées dans les e-mails est activée par défaut. Vous pouvez configurer ces paramètres de site pour un contrôle plus poussé :

• secure_uploads_allow_embed_images_in_emails : Désactivez ceci pour censurer les images sécurisées dans les e-mails.
• secure_uploads_max_email_embed_image_size_kb : La limite de taille de l’image sécurisée que nous intégrerons, par défaut 1 Mo, afin que l’e-mail ne devienne pas trop volumineux. Le maximum est de 10 Mo. Fonctionne de concert avec email_total_attachment_size_limit_kb.

Les images sécurisées seront ajoutées en tant que pièces jointes aux e-mails et intégrées en utilisant le format d’URL cid: car le support des URL base64 dans les clients de messagerie est encore instable.

Si vous n’avez pas activé secure_uploads_allow_embed_images_in_emails, ou si les images commencent à dépasser les limites de taille, voici ce que vous verrez à la place des images sécurisées (également pour l’audio et la vidéo sécurisés qui ne sont pas intégrés) :

Clients hébergés

Pour le moment, les téléchargements sécurisés sont disponibles uniquement pour nos clients de l’offre Entreprise. Veuillez nous contacter pour plus de détails.

[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)]

This is an excellent feature. Thank you for developing it. Minio, a free drop-in replacement for S3, has no support for ACLs and never will. Their argument, which is a good one, is that ACL are not a useful feature and negatively affect performance because they require a second write operation. Secure media uploads will work with Discourse - the uploads:secure_upload_analyse_and_update task will error out on the final step but it seems you can ignore it. That said, is there any reason for Discourse to make ACL calls at all?

[martin (Martin Brennan)]

@mcaruanagalizia

Ce dit, y a-t-il une raison pour que Discourse effectue des appels ACL ?

Oui, car le bucket S3 est privé selon la configuration du sujet original, tout téléchargement non sécurisé doit avoir son ACL défini sur public, et les téléchargements sécurisés auront un ACL privé afin que l’URL S3 puisse être accédée directement. Je ne pense pas que nous ayons actuellement des plans pour modifier le fonctionnement de ceci ; je pense qu’il y aurait beaucoup de travail à faire pour éviter d’utiliser les ACLs pour les remplacements S3.