DISCOURSE_CDN_URL causa violações de política de segurança de conteúdo?

Suporte Instalação
1

Não sei como estou estragando isso. Não consigo entender como sou o único enfrentando o que parece ser um bug.

Se eu definir

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

na seção env: do meu arquivo yml para uma configuração multisite bastante padrão, todos os URLs do CDN são rejeitados pelo navegador devido a um erro de CSP.

content security policy script src afirma: “Fontes de script adicionais na lista branca. O host atual e o CDN estão incluídos por padrão. Veja Mitigar ataques XSS com Content Security Policy.”, mas quando eu defino isso (ou adiciono/removo do discourse.conf e executo sv restart unicorn), recebo o seguinte:

image
image811×296 62.4 KB

mesmo com content security policy report only definido como true, o site ainda não carrega.

Parece que é necessário desativar content_security_policy ou adicionar o URL do CDN ao content security policy script src para que o navegador carregue os recursos.

aqui está o meu arquivo yml.

2

As URLs do CDN devem ser computadas e incluídas na CSP por padrão. Você também poderia fornecer (ou tentar comparar) a CSP real enviada no cabeçalho e a origem dos recursos bloqueados?

3

Aqui está o cabeçalho:

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:

Aqui estão as variáveis de ambiente dentro do 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

Aqui está a URL do CDN de discourse.conf:

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

e do rails:

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

E aqui está a URL de um dos ativos que não carrega: https://lcsupport-92e2.kxcdn.com/brotli_asset/preload-store-d32dcf974dddcac742f8a7a6aa7fcd686185920b201029d0ecb2b85527ef9034.js

4

Então, temos isso no CSP:

https://abedmulti-92e2.kxcdn.com/uploads/assets/
https://abedmulti-92e2.kxcdn.com/uploads/brotli_asset/
# ou seja, DISCOURSE_S3_CDN_URL + /brotli_asset/

Mas o endereço real é:

https://lcsupport-92e2.kxcdn.com/brotli_asset/preload-store-d32dcf974dddcac742f8a7a6aa7fcd686185920b201029d0ecb2b85527ef9034.js
# ou seja, DISCOURSE_CDN_URL + /brotli_asset/...

O código CSP relevante:

Priorizamos o uso de DISCOURSE_S3_CDN_URL para ativos quando disponível. Isso está alinhado com a geração de URLs de ativos do CDN.

@pfaffman, GlobalSetting.use_s3? retorna true para o seu site?

Estou me perguntando se precisamos de uma verificação adicional de GlobalSetting.use_s3? aqui. Ter GlobalSetting.s3_cdn_url implica necessariamente GlobalSetting.use_s3?? Estou um pouco confuso com a geração de ativos / CDN S3 agora :sweat_smile: alguém mais familiarizado com isso poderia dar uma olhada também? Obrigado!

5

Bem, tentei definir use_s3 e depois executar rake assets:precompile, mas não houve nenhuma mudança.

Já tive esse problema em outro lugar, onde havia confusão sobre se os assets estavam no S3 ou locais (ou seus espelhos na CDN).