A partir da v3.3.0.beta1, o Discourse implementa uma Política de Segurança de Conteúdo (CSP) ‘strict-dynamic’. Isso eliminará a necessidade de configuração manual de CSP e melhorará significativamente a compatibilidade com ferramentas externas como gerenciadores de tags e publicidade.
Como administrador do site, você não precisa fazer nada. A alteração entrará em vigor automaticamente e quaisquer scripts externos que você esteja usando continuarão funcionando.
Nenhuma alteração é necessária para temas. Um pequeno número de plugins [1] pode precisar de um pequeno ajuste para compatibilidade com esta alteração (por exemplo, 1, 2).
Fóruns que anteriormente desativaram o CSP para compatibilidade com scripts externos agora devem ser capazes de reativá-lo sem quaisquer problemas ou esforço de configuração.
Para detalhes técnicos, confira este tópico:
Por enquanto, ainda é possível voltar ao sistema antigo desativando a configuração do site ‘content security policy strict dynamic’. Se você tiver algum motivo para fazer isso, por favor nos avise!
A partir da v3.3.0.beta3, tornamos a palavra-chave ‘strict-dynamic’ uma parte obrigatória do nosso CSP. A configuração do site ‘content security policy strict dynamic’ foi removida e a configuração do site ‘content security policy script src’ foi atualizada para armazenar apenas valores válidos.
Para administradores, você deve ser capaz de encontrar o valor anterior da configuração do site ‘content security policy script src’ nos Registros de Ações da Equipe do seu site (https://<url_do_site>/admin/logs/staff_action_logs?filters=%7B%22action_name%22%3A%22change_site_setting%22%2C%22action_id%22%3A3%2C%22subject%22%3A%22content_security_policy_script_src%22%7D - Substitua <url_do_site> pelo URL base do seu site).
tecnicamente: aqueles que introduzem elementos <script> através de register_html_builder ou um template erb↩︎
Notei que a descrição da configuração content security script src afirma que habilitar content_security_policy_strict_dynamic ignorará essa configuração, então vim aqui para consultar.
As fontes de host serão ignoradas quando content_security_policy_strict_dynamic estiver habilitado.
O ponto importante aí é “Fontes de host”. ‘unsafe-inline’ não é uma fonte de host, então ainda é suportado.
Dito isso, concordo totalmente que isso é confuso. Dado o sucesso da implementação do strict-dynamic, planejamos remover o sistema antigo. Assim que o fizermos, poderemos remover automaticamente todas as fontes de host da lista, e as coisas serão muito mais simples para os administradores.
Este novo sistema presumivelmente funciona bem com:
scripts inline
fontes de script completas hospedadas localmente
Mas e o caso em que scripts remotos foram invocados com “loadScript” e a URL remota completa?
Corrija-me se estiver errado, mas acho que não há uma maneira elegante de lidar com esse caso?
Então, isso significa que, para esses casos, precisamos confiar em:
mover essa invocação para um script inline OU
baixar a fonte completa como um ativo do Tema?
Para o primeiro caso de script inline, acho que não há como garantir que o script seja carregado antes de usar elementos dele? (Como você poderia fazer dentro de um .then após um loadScript)
strict-dynamic deve funcionar com scripts remotos carregados via loadScript. Na verdade, esse foi o principal motivo da mudança: não precisamos mais listar todas as URLs de scripts externos antecipadamente. Isso é especialmente bom para quem veicula anúncios, que geralmente carregam muitos scripts remotos.
Eu estava vendo alguns erros, mas pode não ser por esse motivo. Deixe-me ver se consigo encontrar um exemplo.
Eu estava me preparando principalmente para uma atualização estável que sei que envolve loadScript e scripts remotos.
Você pode me atender e explicar como scripts remotos que são invocados aleatoriamente no código com loadScript acabam sendo “autorizados” pela CSP do modo dinâmico? Está acontecendo alguma mágica?
A expressão de origem 'strict-dynamic' especifica que a confiança explicitamente dada a um script presente na marcação, acompanhando-o com um nonce ou hash, será propagada a todos os scripts carregados por esse script raiz.
Portanto, desde que o script original seja confiável (via nonce), o navegador permite que ele carregue quaisquer outros scripts sem restrição. E então, como esses scripts são confiáveis, eles podem carregar mais!
Há uma ressalva, que é que os scripts não podem ser ‘inseridos pelo parser’. Isso impede que o strict-dynamic seja explorado para ataques XSS.
Portanto, por exemplo, isso seria ‘inserido pelo parser’ e seria bloqueado:
Não, o nonce só é incluído na tag de script original renderizada pelo Rails (por exemplo, scripts principais, de plugins ou de temas).
Isso significa que o código principal/de plugin/de tema é confiável e tem permissão para inserir quaisquer outros scripts. Nenhum nonce é necessário aqui - o navegador sabe qual script realizou a inserção e, magicamente, sabe que ele pode ser confiável.
