M

MLOG

Português

Aprenda como a Content Security Policy (CSP) mitiga eficazmente os ataques de Cross-Site Scripting (XSS), melhorando a segurança da web para um público global.

Content Security Policy (CSP): Um Guia Abrangente para a Prevenção de XSS

No cenário digital de hoje, a segurança da web é fundamental. Os ataques de Cross-Site Scripting (XSS) continuam a ser uma ameaça prevalecente e perigosa para as aplicações web em todo o mundo. A Content Security Policy (CSP) é um poderoso cabeçalho de resposta HTTP que fornece uma camada extra de segurança, ajudando a mitigar o risco de vulnerabilidades de XSS. Este guia oferece uma visão abrangente da CSP, sua implementação e as melhores práticas para proteger suas aplicações web contra ataques de XSS.

O que é Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) é um tipo de ataque de injeção em que scripts maliciosos são injetados em sites que, de outra forma, seriam benignos e confiáveis. Os ataques de XSS ocorrem quando um invasor usa uma aplicação web para enviar código malicioso, geralmente na forma de um script do lado do navegador, para um usuário final diferente. As falhas que permitem que esses ataques tenham sucesso são bastante difundidas e ocorrem em qualquer lugar onde uma aplicação web usa a entrada de um usuário na saída que gera sem validá-la ou codificá-la.

Existem três tipos principais de ataques XSS:

Os ataques XSS podem ter consequências graves, incluindo:

O que é a Content Security Policy (CSP)?

A Content Security Policy (CSP) é uma camada adicional de segurança que ajuda a detetar e mitigar certos tipos de ataques, incluindo Cross-Site Scripting (XSS) e ataques de injeção de dados. A CSP é implementada usando um cabeçalho de resposta HTTP que permite controlar os recursos (por exemplo, scripts, folhas de estilo, imagens, fontes, frames) que o navegador tem permissão para carregar para uma página específica. Ao definir uma CSP rigorosa, você pode reduzir significativamente a superfície de ataque da sua aplicação web e dificultar a injeção de código malicioso por parte dos invasores.

A CSP funciona definindo uma lista de permissões (whitelist) de fontes das quais o navegador pode carregar recursos. Qualquer recurso carregado de uma fonte não permitida explicitamente na CSP será bloqueado pelo navegador. Isso impede a execução de scripts não autorizados e reduz o risco de ataques XSS.

Como a CSP Funciona: Diretivas e Fontes

A CSP é configurada usando uma série de diretivas, cada uma especificando uma política para um tipo particular de recurso. Cada diretiva consiste num nome seguido por uma lista de fontes permitidas. Aqui estão algumas das diretivas de CSP mais comumente usadas:

Os valores de fonte comumente usados incluem:

Implementando a CSP

A CSP pode ser implementada de duas maneiras principais:

  1. Cabeçalho HTTP: O método preferido é configurar seu servidor web para enviar o cabeçalho de resposta HTTP `Content-Security-Policy`. Isso permite que você defina a CSP para cada página ou recurso em seu site.
  2. Tag <meta>: A CSP também pode ser definida usando uma tag <meta> na seção <head> do seu documento HTML. No entanto, este método é menos flexível e tem limitações em comparação com o uso do cabeçalho HTTP. Por exemplo, as diretivas `frame-ancestors`, `sandbox` e `report-uri` não podem ser usadas em meta tags HTML.

Usando o Cabeçalho HTTP

Para implementar a CSP usando o cabeçalho HTTP, você precisa configurar seu servidor web para incluir o cabeçalho `Content-Security-Policy` em suas respostas. As etapas de configuração específicas variarão dependendo do servidor web que você está usando.

Aqui estão exemplos para servidores web comuns:

Usando a Tag <meta>

Para implementar a CSP usando a tag <meta>, adicione a seguinte tag à seção <head> do seu documento HTML:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;">

Considerações Importantes:

Exemplos de CSP

Aqui estão vários exemplos de CSP com explicações:

  1. CSP Básica:
    2. Content-Security-Policy: default-src 'self';

    Esta política permite recursos apenas da mesma origem.

  2. Permitindo Scripts de um Domínio Específico:
    3. Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com;

    Esta política permite recursos da mesma origem e scripts de `https://example.com`.

  3. Permitindo Estilos de um CDN:
    4. Content-Security-Policy: default-src 'self'; style-src 'self' https://cdn.example.com;

    Esta política permite recursos da mesma origem e estilos de `https://cdn.example.com`.

  4. Permitindo Imagens de Qualquer Fonte:
    5. Content-Security-Policy: default-src 'self'; img-src *;

    Esta política permite recursos da mesma origem e imagens de qualquer fonte (não recomendado para produção).

  5. Relatando Violações da CSP:
    6. Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint;

    Esta política permite recursos da mesma origem e envia relatórios de violação para `/csp-report-endpoint`. Recomenda-se usar `report-to` em vez de `report-uri`.

  6. Usando `report-to` e `report-uri` juntos para compatibilidade:
    7. Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report-endpoint"}]}

    Este exemplo demonstra a configuração de um `report-uri` (para navegadores mais antigos) e um endpoint `report-to`, além da configuração do próprio cabeçalho `Report-To`. Certifique-se de que seu servidor lida corretamente com o cabeçalho `Report-To`, definindo `group`, `max_age` e `endpoints` corretamente.

  7. Usando Nonces para Scripts Embutidos:
    8. Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3Str1nG';

    Esta política permite recursos da mesma origem e scripts embutidos com o atributo nonce correspondente.

    <script nonce="rAnd0mN0nc3Str1nG">
  // Seu código de script embutido aqui
</script>

CSP em Modo de Apenas Relatório (Report-Only)

A CSP pode ser implementada em dois modos:

O modo de Apenas Relatório é útil para testar e refinar sua CSP antes de aplicá-la. Para habilitar o modo de Apenas Relatório, use o cabeçalho HTTP `Content-Security-Policy-Report-Only` em vez do cabeçalho `Content-Security-Policy`.

Exemplo:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;

Esta configuração enviará relatórios para `/csp-report-endpoint` sem bloquear nenhum recurso.

Melhores Práticas para Implementar a CSP

Aqui estão algumas melhores práticas para implementar a CSP eficazmente:

  1. Comece com uma Política Rigorosa: Comece com uma política restritiva que permite apenas recursos da mesma origem e relaxe-a gradualmente conforme necessário.
  2. Use Nonces ou Hashes para Scripts e Estilos Embutidos: Evite usar `'unsafe-inline'` e use nonces ou hashes para permitir scripts e estilos embutidos específicos.
  3. Evite `'unsafe-eval'`: Se possível, evite usar `'unsafe-eval'`, pois pode introduzir riscos de segurança. Considere abordagens alternativas para a execução de código dinâmico.
  4. Use HTTPS: Certifique-se de que todos os recursos sejam carregados sobre HTTPS para prevenir ataques man-in-the-middle. Use a diretiva `upgrade-insecure-requests` para atualizar automaticamente as requisições inseguras.
  5. Monitore as Violações da CSP: Configure um endpoint de relatório para monitorar as violações da CSP e identificar potenciais problemas de segurança.
  6. Teste sua CSP Completamente: Teste sua CSP em diferentes navegadores e ambientes para garantir que ela esteja funcionando como esperado.
  7. Itere e Refine: A implementação da CSP é um processo iterativo. Monitore e refine continuamente sua CSP à medida que sua aplicação evolui.
  8. Considere a Diretiva `strict-dynamic`: Use `strict-dynamic` para reduzir a complexidade da sua CSP, propagando a confiança para scripts carregados por scripts confiáveis.

Ferramentas para CSP

Várias ferramentas podem ajudá-lo a gerar, testar e monitorar a CSP:

CSP e Frameworks/Bibliotecas

Ao usar frameworks e bibliotecas, é importante configurar a CSP corretamente para garantir a compatibilidade e prevenir problemas de segurança. Aqui estão algumas considerações:

CSP e CDNs (Redes de Entrega de Conteúdo)

CDNs são comumente usadas para hospedar ativos estáticos, como arquivos JavaScript, folhas de estilo CSS e imagens. Para permitir recursos de CDNs na sua CSP, você precisa adicionar explicitamente os domínios da CDN à lista de permissões.

Exemplo:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' https://cdnjs.cloudflare.com;

Esta política permite scripts do jsDelivr e estilos do cdnjs da Cloudflare.

Erros Comuns de CSP a Evitar

Aqui estão alguns erros comuns de CSP a evitar:

Conceitos Avançados de CSP

Além do básico, vários conceitos avançados de CSP podem aprimorar ainda mais a segurança da sua web:

O Futuro da CSP

A CSP está em constante evolução para enfrentar novos desafios de segurança. Desenvolvimentos futuros podem incluir:

Conclusão

A Content Security Policy (CSP) é uma ferramenta poderosa para mitigar ataques XSS e aprimorar a segurança da web. Ao definir uma CSP rigorosa, você pode reduzir significativamente a superfície de ataque da sua aplicação web e proteger seus usuários de código malicioso. Implementar a CSP eficazmente requer planejamento cuidadoso, testes completos e monitoramento contínuo. Seguindo as melhores práticas descritas neste guia, você pode aproveitar a CSP para melhorar a postura de segurança de suas aplicações web e proteger sua presença online no ecossistema digital global.

Lembre-se de revisar e atualizar regularmente sua CSP para se adaptar às ameaças de segurança em evolução e garantir que suas aplicações web permaneçam protegidas.