Uploads Seguros

[martin (Martin Brennan)]

Adicionado na versão 2.4 do Discourse em fevereiro está o recurso de Uploads Seguros, que fornece um nível mais alto de segurança para TODOS os uploads (imagens, vídeos, áudios, textos, PDFs, ZIPs e outros) dentro de uma instância do Discourse.

Pré-requisitos

Você deve ter os uploads S3 ativados em seu site, o que exige que as seguintes configurações sejam preenchidas:

• S3 access key id
• S3 secret access key
• S3 region
• S3 upload bucket

Você também deve estar usando um bucket S3 que não possua uma política de bucket pública e precisa garantir que todos os uploads existentes tenham uma ACL de leitura pública no S3. Consulte a seção “Ativando Uploads Seguros” abaixo.

Após satisfazer esses pré-requisitos, você pode ativar a configuração de site “secure uploads”.

Ativando Uploads Seguros

AQUI HÁ DRAGÕES

Este é um recurso avançado e o suporte fora do nosso nível Enterprise será limitado. Ative os uploads seguros apenas se você for um usuário experiente.

---

Para ativar os uploads seguros, você precisa seguir estas etapas:

1. Certifique-se de que os uploads S3 estão configurados.
2. Anote se seu bucket S3 possui uma política de bucket pública. Se tiver, há uma etapa adicional necessária (etapa 4).
3. Execute a tarefa rake uploads:sync_s3_acls. Isso garantirá que todos os seus uploads tenham a ACL correta no S3. Isso é importante; se você executar a etapa 4 antes disso, alguns uploads podem ficar inacessíveis em seu fórum.
4. Remova a política de bucket pública do seu bucket se ela estava presente na etapa 1.
5. Ative a configuração de site “secure uploads”. Opcionalmente, ative a configuração de site “prevent anons from downloading files” para impedir que usuários anônimos baixem anexos de posts públicos. A partir de agora, qualquer upload poderá ser marcado como seguro dependendo das condições abaixo.
6. Se quiser que todos os uploads sejam analisados retroativamente e possivelmente marcados como seguros, execute a tarefa rake uploads:secure_upload_analyse_and_update.

Nota sobre a política do bucket S3

Você precisa garantir que o bucket para o qual está fazendo upload não tenha uma política de bucket pública. Uma política de bucket pública terá algo como isto:

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

A parte importante aqui é que estamos permitindo que * obtenha objetos, o que significa permitir que qualquer pessoa baixe qualquer coisa no bucket. Este rótulo também mostrará se a política é pública:

As configurações aqui não devem ser alteradas. Na imagem está o estado ideal para a aba “Block public access”:

O que ele faz

Depois de ativar os Uploads Seguros, qualquer arquivo enviado via Composer será marcado como seguro ou não seguro com base nos seguintes critérios:

• Se você tiver a configuração de site “login required” ativada, todos os uploads serão marcados como seguros e usuários anônimos não poderão acessá-los.
• Se você estiver enviando algo dentro de uma Mensagem Pessoal, ele será marcado como seguro.
• Se você estiver enviando algo dentro de um Tópico que está dentro de uma Categoria privada, ele será marcado como seguro.

O upload no S3 terá uma ACL privada, portanto, links diretos para o arquivo no S3 retornarão um erro 403 de acesso negado. Qualquer e todo acesso a uploads seguros será feito por meio de uma URL assinada do S3. Isso ficará oculto para seus usuários; se um upload for seguro, qualquer referência a ele será feita através da URL /secure-uploads/ do Discourse.

Permissões e controle de acesso

A URL /secure-uploads/ determinará se o usuário atual tem permissão para acessar a mídia e a servirá se tiver. Quando o upload é criado, o post em que ele aparece pela primeira vez será definido como seu “post de controle de acesso” e todas as permissões serão baseadas nesse post.

• Se você tiver a configuração de site “login required” ativada, usuários anônimos sempre receberão um erro 404 ao acessar a URL.
• Ao acessar mídia cujo post de controle de acesso é uma Mensagem Pessoal, o usuário deve fazer parte desse tópico de Mensagem Pessoal para acessar a mídia; caso contrário, o usuário receberá um erro 403.
• Ao acessar mídia cujo post de controle de acesso está dentro de um tópico que está dentro de uma Categoria privada, o usuário deve ter acesso a essa categoria para acessar a mídia; caso contrário, o usuário receberá um erro 403.

Copiar URLs /secure-uploads/ entre Posts e Tópicos é imprudente, pois diferentes usuários terão diferentes níveis de acesso em seus fóruns do Discourse. Novos uploads devem sempre ser criados via Composer. Oneboxes e imagens com hotlink também respeitarão as regras de uploads seguros. Configurações de site, emojis e uploads de temas não são afetados pelos uploads seguros, pois devem ser públicos.

Se um post de controle de acesso for excluído, o upload anexado não estará mais acessível.

Movendo posts com uploads seguros

Se você mover um “post de controle de acesso” entre diferentes contextos de segurança, o upload anexado pode ser alterado para seguro ou não seguro. Estas são as situações que podem alterar a segurança de um upload:

• Alterar a categoria de um tópico. Percorrerá todos os posts no tópico e atualizará o status de segurança do upload de acordo.
• Alterar um tópico entre ser um tópico público e uma mensagem pessoal. Fará o mesmo que acima.
• Mover posts de um tópico para outro tópico novo ou existente. Executará o mesmo que acima no tópico de destino.

Uploads seguros em e-mails

A incorporação de imagens seguras em e-mails está ativada por padrão. Você pode configurar essas configurações de site para controle adicional:

• secure_uploads_allow_embed_images_in_emails: Desative isso para censurar imagens seguras em e-mails.
• secure_uploads_max_email_embed_image_size_kb: O limite máximo para o tamanho da imagem segura que incorporaremos, padrão de 1 MB, para que o e-mail não fique muito grande. O máximo é 10 MB. Funciona em conjunto com email_total_attachment_size_limit_kb.

As imagens seguras serão adicionadas como anexos de e-mail e incorporadas usando o formato de URL cid:, pois o suporte a URL base64 em clientes de e-mail ainda é instável.

Se você não tiver secure_uploads_allow_embed_images_in_emails ativado, ou se as imagens começarem a exceder os limites de tamanho, isto é o que você verá no lugar das imagens seguras (também áudio e vídeo seguros que não são incorporados):

Clientes Hospedados

Neste momento, os uploads seguros estão disponíveis apenas para nossos clientes do plano Enterprise. Por favor, entre em contato conosco para mais detalhes.

[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

Minha preocupação é que ter o acesso público configurado em um bucket S3 é algo que nos é ensinado como uma ideia muito ruim. Então, quero confirmar novamente se os uploads seguros estarão seguros com essa configuração? Com base na sua recomendação atual, a premissa é que, para que os avatares estejam acessíveis para upload pelo usuário/admin, o acesso público é necessário, e os uploads seguros são protegidos porque cada um recebe explicitamente uma ACL definida para impedir o acesso público, e executar uploads:sync_s3_acls atualizará os existentes e qualquer novo upload em tópicos terá, naquele momento, a ACL necessária definida?

Essa é a essência, sim. Qualquer coisa que precise ser privada terá uma ACL privada definida e será inacessível, a menos que uma URL assinada seja usada. Note que a política do bucket não é Pública. E sim, todas as configurações de “Bloquear acesso público” devem estar desmarcadas. Se você estiver interessado em como determinamos se um upload é seguro, todas as regras estão aqui: discourse/lib/upload_security.rb at main · discourse/discourse · GitHub e aqui: discourse/app/models/post.rb at main · discourse/discourse · GitHub

@AntiMetaman

Eu nunca tive a opção “Bloquear todo o acesso público” habilitada nas configurações do meu bucket desde o início. Se você está me dizendo que anônimos ainda devem conseguir acessar um tópico, lê-lo e visualizar imagens seguras, então posso tentar novamente. Se adicionar segurança às mídias impedir que anônimos vejam essas imagens, eu preferiria apenas proteger os anexos.

Se ajudar, estou usando BackBlaze B2 com BunnyCDN. Minhas configurações do bucket de upload estão atualmente públicas:

Não estou familiarizado com o BackBlaze, desculpe. Não tenho certeza de como as configurações mostradas se traduziriam em uma política de bucket. Basicamente, você não quer que a política do bucket seja Pública e não quer ativar “Bloquear todo o acesso público”. Assim, podemos definir as ACLs privadas e públicas adequadamente. Se você não tiver “login obrigatório”, qualquer upload feito em um tópico que não esteja em uma mensagem privada ou categoria privada deve ser público e acessível por anônimos. As imagens não devem ser seguras em um tópico acessível por anônimos.

[riking (Kane York)]

A implementação de mídia segura não é compatível com o Backblaze. Eles suportam URLs pré-assinadas?

[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, obrigado pela esclarecimento. Posso confirmar que, mantendo a configuração no S3 conforme minha captura de tela (Pública) e com todas as opções desmarcadas (como você sugeriu), os avatares personalizados/imagens de perfil finalmente estão funcionando, enquanto os uploads protegidos de tópicos continuam funcionando perfeitamente. Obrigado!

[martin (Martin Brennan)]

Juntei este PR esta semana e estou adicionando esses detalhes ao OP:

FEATURE: Allow email image embed with secure media (#10563)

---

Se você deseja permitir a incorporação de imagens seguras em e-mails, pode configurar as seguintes opções do site:

• secure_media_allow_embed_images_in_emails: Se habilitado, incorporaremos imagens seguras nos e-mails em vez de ocultá-las.
• secure_media_max_email_embed_image_size_kb: O limite máximo para o tamanho da imagem segura que incorporaremos, com padrão de 1 MB, para que o e-mail não fique muito grande. O máximo é 10 MB. Funciona em conjunto com email_total_attachment_size_limit_kb.

As imagens seguras serão adicionadas como anexos de e-mail e incorporadas usando o formato de URL cid:, pois o suporte a URLs em base64 em clientes de e-mail ainda é instável.

Se você não tiver secure_media_allow_embed_images_in_emails habilitado, ou se as imagens começarem a exceder os limites de tamanho, isso é o que você verá no lugar das imagens seguras (também áudio e vídeo seguros, que não são incorporados):

[martin (Martin Brennan)]

Adendo adicional ao meu post anterior; a partir deste PR:

FEATURE: Default allow embed secure images in email to true (#10688)

Agora ativamos por padrão a incorporação segura de imagens de mídia.

[gerald]

Depois de configurar o upload seguro de mídias (seguindo o guia do OP), tudo funciona bem (anexos, imagens…), exceto os uploads que não são anexos de tópico (como logotipo do site, avatar do perfil), que exibem um pop-up “Acesso Negado” no Discourse.
Eu configurei algo errado?

[michaeld (Michael - Communiteq)]

Por favor, leia o tópico; sua questão foi abordada em algumas postagens acima desta.

[gerald]

Li tudo com atenção. Por favor, me informe exatamente o que você quis dizer com as poucas postagens acima. Não estou vendo esse problema.
Edição:
Tentando ler nas entrelinhas, vejo que este tópico costumava ser mais longo, mas algumas respostas-chave foram excluídas dele; vejo referências a respostas que não existem e menções a capturas de tela que não aparecem no tópico.
Se entendi corretamente, a recomendação é configurar o bucket S3 para NÃO bloquear nenhum acesso público. Gostaria apenas de confirmar isso e perguntar se é seguro?

[michaeld (Michael - Communiteq)]

Correto.

A postagem original realmente sumiu, mas o problema e a solução continuam lá.

@genachka

a premissa é que, para que os avatares estejam acessíveis para upload pelo usuário/admin, é necessário acesso público.

[gerald]

Percebi um bug ao usar mídia segura e https://meta.discourse.org/t/knowledge-base-plugin/115288

Links para anexos na base de conhecimento falham ao abrir (redirecionam para uma página 404), a menos que sejam forçados a abrir em uma nova janela.

O estranho é que o mesmo anexo pode ser aberto sem problemas a partir do tópico do Discourse associado ao item da base de conhecimento.

Edição:
O mesmo bug ocorre quando alguém copia um link para um anexo de uma resposta para outra. O link é exatamente o mesmo, naturalmente, mas só funciona na resposta original, a menos que seja forçado a abrir em uma nova janela.

[sbernhard (Bernhard Suttner)]

E quanto à mídia segura se o S3 não for utilizado?

Atualmente, parece que, se você tiver o link direto para o arquivo enviado, poderá baixar esse arquivo sem precisar fazer login. Isso representa um problema de segurança…

[RGJ (Richard - Communiteq)]

@sbernhard

E quanto à mídia segura se o S3 não for usado?

A mídia segura exige o S3.
Todo esse recurso foi desenvolvido para tornar impossível compartilhar e acessar links diretos.

[mcaruanagalizia (Matthew Caruana Galizia)]

Essa é uma funcionalidade excelente. Obrigado por desenvolvê-la. O Minio, uma substituição gratuita e direta para o S3, não oferece suporte a ACLs e nunca o fará. O argumento deles, que é válido, é que as ACLs não são uma funcionalidade útil e afetam negativamente o desempenho, pois exigem uma segunda operação de escrita. O upload seguro de mídia funcionará com o Discourse — a tarefa uploads:secure_upload_analyse_and_update falhará na etapa final, mas parece que você pode ignorá-la. Dito isso, há alguma razão para o Discourse fazer chamadas de ACL de qualquer forma?

[martin (Martin Brennan)]

@mcaruanagalizia

Dito isso, há alguma razão para o Discourse fazer chamadas de ACL?

Sim, porque o bucket S3 é privado com base na configuração do OP, qualquer upload não seguro precisa ter sua ACL definida como pública, e uploads seguros terão uma ACL privada para que a URL do S3 possa ser acessada diretamente. Não acredito que tenhamos planos, neste momento, de modificar como isso funciona; acredito que haveria bastante trabalho envolvido para evitar o uso de ACLs completamente para substituições do S3.