Resumo: limites da conformidade CSP
- O CSP é uma defesa crítica nativa do navegador, mas não garante, por si só, conformidade com a PCI DSS 4.0.1. O ataque à cadeia de fornecimento do Polyfill.io em 2024 teve sucesso em centenas de milhares de sites onde o CSP estava corretamente configurado.
- A limitação fundamental é que o CSP permite domínios por lista de permissões, não a integridade do código. Se um domínio de confiança for comprometido (como aconteceu com o Polyfill.io), o CSP continua a permitir que o código malicioso carregue e execute.
- A PCI DSS 4.0.1 §6.4.3 e §11.6.1 exigem explicitamente capacidades que vão além do CSP: inventário de scripts com justificação de negócio, verificação de integridade em cada carregamento, e deteção de modificações não autorizadas nas páginas de pagamento.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
O que é uma Content Security Policy (CSP)?
A Content Security Policy (CSP) é um cabeçalho de resposta HTTP que indica aos navegadores quais origens de scripts, folhas de estilo e frames estão autorizados a carregar. Mitiga o XSS ao bloquear scripts inline não autorizados e carregamentos externos. O CSP é uma base necessária, mas não deteta anomalias comportamentais em scripts autorizados, não monitoriza o que os scripts fazem em tempo de execução, nem satisfaz o requisito da PCI DSS 6.4.3 de um inventário de autorização de scripts com justificação de negócio.
A Content Security Policy (CSP) é um recurso de segurança fornecido pelos navegadores web que o proprietário de um site pode usar para definir um conjunto de regras que controlam quais recursos (por exemplo, scripts, estilos, imagens) podem ser carregados e executados pelo navegador. Chamamos a isto o lado do cliente, que está no extremo final da cadeia de fornecimento web.
Quando configurada corretamente, ajuda a prevenir uma vasta gama de ataques. Mas essas três primeiras palavras fazem toda a diferença.
Pode ajudar a prevenir cross-site scripting (XSS): ao restringir as origens a partir das quais os scripts podem ser carregados, o CSP bloqueia scripts maliciosos injetados numa página web. Por exemplo, se uma política de CSP especificar script-src 'self', apenas scripts do próprio domínio do site podem executar. Também protege contra clickjacking — a diretiva frame-ancestors impede que um site seja incorporado em iframes em domínios não autorizados — e limita ataques de injeção de dados ao controlar quais imagens, fontes e media têm permissão para carregar.
Como veremos, na prática isso não é bem assim.
O objetivo do CSP (quando configurado corretamente)
Defesa contra conteúdo malicioso de terceiros
Os sites frequentemente dependem de conteúdo de terceiros, como ferramentas de analytics ou scripts publicitários, que se podem tornar vetores de ataque se forem comprometidos. O CSP minimiza este risco ao restringir o conteúdo a fontes pré-aprovadas e de confiança, protegendo o seu site de vulnerabilidades em bibliotecas de terceiros.
Prevenção da exfiltração de dados
Scripts maliciosos concebidos para extrair dados sensíveis e enviá-los para domínios não autorizados são uma ameaça constante. O CSP funciona como uma barreira, bloqueando esses scripts e garantindo que os dados dos utilizadores permanecem seguros.
Proteção contra ataques à cadeia de fornecimento
Quando combinado com Subresource Integrity (SRI), o CSP valida scripts e estilos de terceiros para garantir que não foram alterados durante a entrega. Isto acrescenta uma salvaguarda teórica contra comprometimentos na cadeia de fornecimento.
Controlo sobre comportamentos dinâmicos não intencionais
As diretivas do CSP como script-src, style-src, e restrições sobre unsafe-eval impedem a execução de código gerado ou modificado dinamicamente. Isto reduz a superfície de ataque ao limitar exploits que dependem de eval() ou de scripts inline.
Leve e altamente configurável
Entregue através de cabeçalhos do lado do servidor, o CSP tem um impacto mínimo no desempenho da aplicação. A sua flexibilidade permite configurações personalizadas, tornando-o adequado para uma vasta gama de casos de uso e necessidades arquiteturais.
Os desafios e limitações do CSP
Porque é que, então, o CSP tem má reputação? Em teoria, soa a uma solução ideal. Uma ferramenta poderosa para controlar totalmente o que os navegadores têm permissão para carregar num site.
Na prática, contudo, a realidade fica muito aquém dessa promessa.
O CSP é um mecanismo de defesa complementar, não uma solução autónoma, e vem com desafios e limitações significativos que podem prejudicar a sua eficácia ou até dar uma falsa sensação de segurança.
Complexidade de implementação
Criar um CSP eficaz para aplicações web modernas é uma tarefa difícil. Os sites frequentemente dependem de inúmeros domínios de terceiros para analytics, CDNs, publicidade e fontes, tornando quase impossível criar uma política rígida sem quebrar algum tipo de funcionalidade. Gerir diretivas como script-src, style-src e img-src em diversas origens torna-se, de facto, ingerível, particularmente em aplicações grandes e em constante evolução.
Incapacidade de bloquear scripts específicos
O CSP funciona segundo um modelo de lista de permissões, que autoriza recursos de domínios de confiança mas não consegue bloquear scripts ou recursos individuais provenientes desses domínios.
Um exemplo rápido: se permitir um domínio como cdn.example.com, o CSP não consegue impedir que scripts maliciosos aí alojados sejam executados.
Atualizações recentes ao CSP introduzem uma funcionalidade para resolver esta limitação usando Subresource Integrity (SRI) integrada na diretiva script-src. Isto permite que scripts específicos sejam adicionados à lista de permissões usando hashes do seu conteúdo, garantindo que apenas a versão exata e verificada de um script pode carregar.
Embora poderosa em teoria, esta abordagem tem uma desvantagem significativa: qualquer atualização ao script invalida o hash, fazendo com que a verificação SRI falhe e o script deixe de funcionar.
Para scripts que são atualizados com frequência, como os de ferramentas de marketing, isto torna a funcionalidade de hash inútil. A menos que esteja a trabalhar com scripts garantidamente estáticos, este mecanismo é essencialmente inutilizável.
Sobrecarga de manutenção elevada
As políticas de CSP exigem atualizações frequentes para acomodar:
- Novos scripts, estilos ou recursos para funcionalidades ou páginas adicionadas.
- Alterações em domínios ou serviços de terceiros.
- Fatores externos, como uma alteração numa API de terceiros, que podem quebrar uma política anteriormente funcional.
É necessária uma ferramenta de monitorização só para isso, para detetar as atualizações.
Riscos das dependências de terceiros
Permitir recursos de terceiros nas políticas de CSP implica confiar, inerentemente, que esses domínios externos permanecem seguros. Mas scripts comprometidos ou maliciosos de terceiros de confiança podem continuar a executar, contornando totalmente as proteções do CSP.
Esta dependência é, em si mesma, uma vulnerabilidade crítica no modelo do CSP.
Vimos isto no ataque ao Polyfill em 2024, onde exatamente isso aconteceu. Mais de meio milhão de sites confiavam num único domínio para injetar um script no seu site. Até mesmo os que tinham uma estratégia robusta de CSP foram vítimas.
Desafios com scripts e estilos inline
Por predefinição, o CSP bloqueia scripts e estilos inline, o que é uma medida de segurança sensata. Mas, mais uma vez, há problemas.
- Muitas frameworks (por exemplo, React, Angular) e sistemas legados dependem fortemente de scripts inline, dificultando a aplicação sem uma refatoração extensa.
- Muitas ferramentas de marketing fornecem exemplos que usam tags
<script>inline para carregar bundles JavaScript externos. Embora estes scripts pudessem ser executados a partir de ficheiros separados, os exemplos frequentemente incorporam-nos diretamente, complicando a aplicação do CSP e introduzindo riscos potenciais. - Para acomodar isto, os programadores recorrem frequentemente ao uso de unsafe-inline, o que compromete a segurança do CSP ao permitir todo o conteúdo inline.
Uso excessivo de diretivas permissivas
Para evitar quebrar funcionalidades, os programadores acabam por ter de enfraquecer as políticas de CSP. Uma forma invertida de priorizar a funcionalidade em detrimento da segurança.
unsafe-inline: permite scripts e estilos inline, anulando os principais objetivos de segurança do CSP.unsafe-eval: permite o uso de eval() e métodos semelhantes, que são altamente exploráveis.*(wildcard): concede acesso a qualquer domínio, anulando efetivamente o valor da política.
Depuração de violações de CSP
Diagnosticar problemas relacionados com o CSP é extremamente demorado e frustrante.
- Os navegadores registam violações de CSP na consola, mas os registos frequentemente não têm contexto suficiente para identificar a causa raiz.
- Depurar políticas excessivamente rígidas que quebram funcionalidades exige um esforço significativo, levando os programadores a relaxar a política e a comprometer a segurança.
Quebra de funcionalidades existentes
Como referido anteriormente, políticas de CSP rígidas podem perturbar componentes essenciais.
- Integrações de terceiros como analytics, anúncios ou widgets sociais.
- Aplicações legadas dependentes de scripts inline, estilos ou recursos carregados dinamicamente. Para restaurar a funcionalidade, os programadores frequentemente afrouxam as restrições, comprometendo a segurança pretendida.
Inconsistências entre navegadores
A aplicação do CSP varia de navegador para navegador, o que agrava ainda mais o problema.
- Navegadores mais antigos podem ignorar completamente certas diretivas.
- Algumas diretivas, como worker-src ou navigate-to, não têm suporte universal, o que limita a sua eficácia.
Falta de relatórios padronizados
Embora o CSP suporte relatórios de violações, não existe um formato ou ferramenta universalmente aceite para processar esses relatórios, o que dificulta que as equipas os analisem e ajam sobre eles de forma eficaz.
Formas fáceis de contornar políticas de CSP incompletas para exfiltração
Uma das maiores vulnerabilidades em configurações de CSP incompletas é a ausência da diretiva default-src. Sem ela, as políticas de CSP podem ser contornadas para exfiltrar dados através de mecanismos como o prefetching.
Embora o default-src se destine a definir regras de reserva (fallback), a especificação do CSP nota que o prefetching não é regido pela sua própria diretiva, pelo que, sem default-src, os links de prefetch contornam o CSP por completo. A nossa análise de sites rastreados encontrou um número surpreendente sem default-src, deixando-os vulneráveis a este exploit. E o connect-src também não ajuda: mesmo um connect-src bem configurado não consegue impedir a exfiltração baseada em prefetch, uma vez que não se aplica a este tipo de ligações.
Evite o CSP, faça isto em vez disso
O CSP tem benefícios reais no papel. Usá-lo num ambiente real torna-se rapidamente uma tarefa incómoda. Ainda assim, a segurança do lado do cliente está a tornar-se cada vez mais prevalente.
Ao procurar uma ferramenta de segurança do lado do cliente, certifique-se de verificar se ela não depende exclusivamente do CSP como base para a monitorização de recursos, configurando-o em modo "report-only". As suas soluções dependem principalmente do CSP para monitorizar e reportar comportamentos de recursos, oferecendo capacidades de bloqueio limitadas como funcionalidade adicional.
Embora provavelmente seja suficiente para conformidade, isto deixa-o exposto a um mundo de problemas caso seja atacado.
A cside tem soluções de segurança modernas que não dependem do CSP, para uma abordagem mais eficiente à proteção do lado do cliente. Construímos um serviço de proxy que acompanha todos os scripts no seu site, e que consegue identificar e bloquear proativamente código malicioso.
Sem necessidade de verificação ou relatórios manuais.
Pode começar gratuitamente ou contactar-nos.
