Política de Segurança de Conteúdo

A Política de Segurança de Conteúdo pode reduzir bastante o risco e o impacto de ataques de XSS em navegadores modernos.

Joe Medley

Mike West

O modelo de segurança da Web é baseado em uma política de mesma origem. Por exemplo, o código de https://mybank.com precisa ter acesso apenas aos dados de https://mybank.com, e https://evil.example.com nunca pode ter acesso. Em teoria, cada origem é isolada do restante da Web, oferecendo aos desenvolvedores um sandbox seguro para criar. Na prática, no entanto, os invasores encontraram várias maneiras de subverter o sistema.

Os ataques de scripting em vários locais (XSS), por exemplo, fogem da mesma política de origem fazendo um site enviar código malicioso junto com o conteúdo pretendido. Esse é um grande problema, porque os navegadores confiam que todo o código mostrado em uma página é uma parte legítima da origem de segurança da página. O guia de consulta rápida de XSS é um detalhamento antigo, mas representativo, dos métodos que podem ser usados por um invasor para violar essa confiança por meio da injeção de código malicioso. Se um invasor injetar qualquer código, ele comprometerá a sessão do usuário e terá acesso a informações particulares.

Nesta página, descrevemos a Política de Segurança de Conteúdo (CSP) como uma estratégia para reduzir o risco e o impacto de ataques XSS em navegadores modernos.

Componentes do CSP

Para implementar um CSP eficaz, siga estas etapas:

• Use listas de permissões para informar o cliente do que é permitido e do que não é.
• Conheça as diretivas disponíveis.
• Conheça as palavras-chave que usam.
• Restringe o uso de código inline e eval().
• Relate violações da política ao servidor antes de tomar alguma providência sobre elas.

Listas de permissões de origem

Os ataques XSS exploram a incapacidade do navegador de distinguir entre o script que faz parte do aplicativo e o que foi injetado de forma maliciosa por um terceiro. Por exemplo, o botão +1 do Google na parte de baixo desta página carrega e executa o código de https://apis.google.com/js/plusone.js no contexto da origem da página. Confiamos nesse código, mas não podemos esperar que o navegador descubra por conta própria que o código de apis.google.com é seguro para execução, enquanto o código de apis.evil.example.com provavelmente não é. O navegador baixa e executa todo código que uma página solicita, independentemente da origem.

O cabeçalho HTTP Content-Security-Policy da CSP permite criar uma lista de permissões de fontes de conteúdo confiável e instrui o navegador a executar ou renderizar apenas recursos dessas origens. Mesmo que um invasor consiga encontrar uma brecha para injetar um script, ele não vai corresponder à lista de permissões e, portanto, não será executado.

Confiamos em apis.google.com para fornecer código válido e confiamos em nós mesmos para fazer o mesmo. Confira um exemplo de política que permite a execução de scripts apenas quando eles vêm de uma dessas duas fontes:

Content-Security-Policy: script-src 'self' https://apis.google.com

script-src é uma diretiva que controla um conjunto de privilégios relacionados a scripts de uma página. Esse cabeçalho 'self' como uma fonte válida de script e https://apis.google.com como outra. O navegador agora pode fazer o download e executar JavaScript de apis.google.com por HTTPS, bem como da origem da página atual, mas não de nenhuma outra origem. Se um invasor injetar código no seu site, o navegador vai gerar um erro e não vai executar o script injetado.

A política se aplica a uma ampla variedade de recursos

O CSP fornece um conjunto de diretivas de política que permitem o controle granular dos recursos que uma página pode carregar, incluindo script-src do exemplo anterior.

A lista a seguir descreve o restante das diretivas de recursos a partir do nível 2. Uma especificação de nível 3 foi redigida, mas ela não foi implementada em grande parte nos principais navegadores.

base-uri

Restrição dos URLs que podem aparecer no elemento <base> de uma página.

child-src

Lista os URLs dos workers e do conteúdo do frame incorporado. Por exemplo, child-src https://youtube.com permite a incorporação de vídeos do YouTube, mas não de outras origens.

connect-src

Limita as origens às quais você pode se conectar usando XHR, WebSockets e EventSource.

font-src

Especifica as origens que podem disponibilizar fontes da Web. Por exemplo, é possível permitir as fontes da Web do Google usando font-src https://themes.googleusercontent.com.

form-action

Lista endpoints válidos para envio de tags <form>.

frame-ancestors

Especifica as origens que podem incorporar a página atual. Essa diretiva se aplica às tags <frame>, <iframe>, <embed> e <applet>. Ele não pode ser usado em tags <meta> ou para recursos HTML.

frame-src

Esta diretiva foi descontinuada no nível 2, mas restaurada no nível 3. Se ele não estiver presente, o navegador voltará para child-src.

img-src

Define a origem das imagens que podem ser carregadas.

media-src

Restrição das origens que podem fornecer vídeo e áudio.

object-src

Permite o controle sobre o Flash e outros plug-ins.

plugin-types

Limita os tipos de plug-ins que uma página pode invocar.

report-uri

Especifica um URL para o qual o navegador envia relatórios quando uma política de segurança de conteúdo é violada. Essa diretiva não pode ser usada em tags <meta>.

style-src

Limita as origens de onde uma página pode usar folhas de estilo.

upgrade-insecure-requests

Instrui os user agents a reescrever esquemas de URL mudando HTTP para HTTPS. Essa diretiva é para sites com um grande número de URLs antigos que precisam ser reescritos.

worker-src

Uma diretiva do nível 3 do CSP que restringe os URLs que podem ser carregados como worker, worker compartilhado ou service worker. Desde julho de 2017, essa diretiva tem implementações limitadas.

Por padrão, o navegador carrega o recurso associado de qualquer origem, sem restrições, a menos que você defina uma política com uma diretiva específica. Para substituir o padrão, especifique uma diretiva default-src. Essa diretiva define os padrões para qualquer diretiva não especificada que termine com -src. Por exemplo, se você definir default-src como https://example.com e não especificar uma diretiva font-src, só será possível carregar fontes de https://example.com.

As diretivas a seguir não usam default-src como substituto. Lembre-se de que não defini-las é o mesmo que permitir tudo:

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

Sintaxe básica de CSP

Para usar as diretivas da CSP, liste-as no cabeçalho HTTP com diretivas separadas por dois-pontos. Liste todos os recursos necessários de um tipo específico em uma única diretiva, conforme abaixo:

script-src https://host1.com https://host2.com

Confira a seguir um exemplo de várias diretivas, neste caso para um app da Web que carrega todos os recursos de uma rede de fornecimento de conteúdo em https://cdn.example.net e não usa conteúdo em frames ou plug-ins:

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

Detalhes da implementação

Os navegadores modernos oferecem suporte ao cabeçalho Content-Security-Policy sem prefixo. Este é o cabeçalho recomendado. Os cabeçalhos X-WebKit-CSP e X-Content-Security-Policy que você pode encontrar em tutoriais on-line foram descontinuados.

O CSP é definido página por página. Você precisa enviar o cabeçalho HTTP com todas as respostas que quer proteger. Isso permite ajustar a política para páginas específicas com base nas necessidades específicas. Por exemplo, se um conjunto de páginas no seu site tiver um botão +1, enquanto outras não, você poderá permitir que o código do botão seja carregado somente quando necessário.

A lista de fontes para cada diretiva é flexível. É possível especificar origens por esquema (data:, https:) ou variando de apenas nome do host (example.com, que corresponde a qualquer origem nesse host: qualquer esquema, qualquer porta) a um URI totalmente qualificado (https://example.com:443, que corresponde apenas HTTPS, somente example.com e somente à porta 443). Caracteres curinga são aceitos, mas somente como um esquema, uma porta ou à extrema esquerda do nome do host: *://*.example.com:* corresponderia a todos os subdomínios de example.com (mas não ao próprio example.com), usando qualquer esquema em qualquer porta.

A lista de fontes também aceita quatro palavras-chave:

• 'none' não corresponde a nada.
• 'self' corresponde à origem atual, mas não aos subdomínios.
• 'unsafe-inline' permite JavaScript e CSS inline. Para mais informações, consulte Evitar código inline.
• 'unsafe-eval' permite mecanismos de texto para JavaScript, como eval. Para mais informações, consulte Evitar eval().

Essas palavras-chave exigem aspas simples. Por exemplo, script-src 'self' (com aspas) autoriza a execução de JavaScript no host atual. script-src self (sem aspas) permite executar JavaScript de um servidor chamado "self" (e não do host atual), o que provavelmente não é o que você quer.

Testar suas páginas no sandbox

Há mais uma diretiva de que vale a pena falar: sandbox. Ela é um pouco diferente das outras que analisamos, já que coloca restrições em ações que a página pode executar, em vez de em recursos que a página pode carregar. Se a diretiva sandbox estiver presente, a página será tratada como se tivesse sido carregada dentro de um <iframe> com um atributo sandbox. Isso pode gerar um monte de efeitos na página: forçar a página em uma origem única, impedir o envio de formulários e outros. Está um pouco além do escopo desta página, mas você pode encontrar todos os detalhes sobre os atributos de sandbox válidos na seção "Sandboxing" da especificação HTML5.

A metatag

O mecanismo de fornecimento de CSPs preferido é um cabeçalho HTTP. No entanto, pode ser útil definir uma política em uma página diretamente na marcação. Para isso, use uma tag <meta> com um atributo http-equiv:

<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">

Não é possível usar esse recurso para frame-ancestors, report-uri ou sandbox.

Evite o código inline

Por mais poderosas que sejam as listas de permissões baseadas na origem usadas nas diretivas do CSP, elas não podem resolver a maior ameaça apresentada pelos ataques XSS: a injeção de script inline. Se um invasor conseguir injetar uma tag de script que contenha diretamente um payload malicioso (como <script>sendMyDataToEvilDotCom()</script>), o navegador não terá como diferenciá-la de uma tag de script inline legítima. A CSP resolve esse problema banindo totalmente o script inline.

Esse banimento inclui não apenas scripts incorporados diretamente nas tags script, mas também gerenciadores de eventos inline e URLs javascript:. Você vai precisar mover o conteúdo das tags script para um arquivo externo e substituir os URLs javascript: e <a ... onclick="[JAVASCRIPT]"> por chamadas addEventListener() apropriadas. Por exemplo, é possível reescrever o seguinte:

<script>
    function doAmazingThings() {
    alert('YOU ARE AMAZING!');
    }
</script>
<button onclick='doAmazingThings();'>Am I amazing?</button>

para algo mais como:

<!-- amazing.html -->
<script src='amazing.js'></script>
<button id='amazing'>Am I amazing?</button>

// amazing.js
function doAmazingThings() {
    alert('YOU ARE AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
    document.getElementById('amazing')
    .addEventListener('click', doAmazingThings);
});

O código regravado não é apenas compatível com o CSP, mas também está alinhado com as práticas recomendadas de design da Web. O JavaScript inline mistura estrutura e comportamento de maneiras que tornam o código confuso. Também é mais complicado fazer o cache e a compilação. Mover o código para recursos externos melhora o desempenho das suas páginas.

Mover tags e atributos style inline para folhas de estilo externas também é altamente recomendável para proteger seu site contra ataques de exfiltração de dados (em inglês) com base em CSS.

Como permitir temporariamente scripts e estilos inline

É possível ativar scripts e estilos inline adicionando 'unsafe-inline' como uma fonte permitida em uma diretiva script-src ou style-src. A CSP de nível 2 também permite adicionar scripts inline específicos à lista de permissões usando um nonce criptográfico (número usado uma vez) ou um hash da seguinte maneira.

Para usar um valor de uso único, atribua um atributo de uso único à tag de script. O valor precisa ser igual a um da lista de fontes confiáveis. Exemplo:

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
    // Some inline code I can't remove yet, but need to as soon as possible.
</script>

Adicione o valor de uso único à diretiva script-src seguindo a palavra-chave nonce-:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Os nonces precisam ser regenerados para cada solicitação de página e não podem ser adivinháveis.

Os hashes funcionam de maneira semelhante. Em vez de adicionar código à tag do script, crie um hash SHA do próprio script e adicione-o à diretiva script-src. Por exemplo, se a página contiver o seguinte:

<script>alert('Hello, world.');</script>

Sua política precisa conter o seguinte:

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

O prefixo sha*- especifica o algoritmo que gera o hash. O exemplo anterior usa sha256-, mas o CSP também oferece suporte a sha384- e sha512-. Ao gerar o hash, omita as tags <script>. Letras maiúsculas e minúsculas e espaços fazem diferença, incluindo espaços no início e no fim.

As soluções para gerar hashes SHA estão disponíveis em vários idiomas. Usando o Chrome 40 ou posterior, você pode abrir o DevTools e recarregar a página. A guia "Console" mostra mensagens de erro com o hash SHA-256 correto para cada um dos scripts inline.

Evite eval()

Mesmo quando um invasor não consegue injetar um script diretamente, ele pode enganar seu aplicativo para converter texto de entrada em JavaScript executável e executá-lo em nome dele. eval(), new Function(), setTimeout([string], …) e setInterval([string], ...) são vetores que os invasores podem usar para executar códigos maliciosos por meio de texto injetado. A resposta padrão da CSP a esse risco é bloquear completamente todos esses vetores.

Isso afeta a maneira como você cria aplicativos:

• Você precisa analisar JSON usando o JSON.parse integrado em vez de depender de eval. As operações JSON seguras estão disponíveis em todos os navegadores desde o IE8.

• Reescreva todas as chamadas de setTimeout ou setInterval que você faz usando funções inline em vez de strings. Por exemplo, se a página contiver o seguinte:

  setTimeout("document.querySelector('a').style.display = 'none';", 10);
  

  Reescreva-o como:

  setTimeout(function () {
      document.querySelector('a').style.display = 'none';
  }, 10);
    ```
  

• Evite a geração de modelos inline em tempo de execução. Muitas bibliotecas de modelos usam new Function() com frequência para acelerar a geração de modelos no momento da execução, o que permite a avaliação de texto malicioso. Alguns frameworks oferecem suporte a CSP de forma inovadora, usando fallback para um analisador robusto na ausência de eval. A diretiva ng-csp do AngularJS é um bom exemplo disso. No entanto, recomendamos usar uma linguagem de modelos que ofereça pré-compilação, como Handlebars. A pré-compilação dos modelos pode tornar a experiência do usuário ainda mais rápida do que a implementação de tempo de execução mais rápida, além de tornar seu site mais seguro.

Se eval() ou outras funções de texto para JavaScript forem essenciais para o aplicativo, ative-as adicionando 'unsafe-eval' como uma origem permitida em uma diretiva script-src. Isso não é recomendado devido ao risco de injeção de código que ele apresenta.

Denunciar violações da política

Para notificar o servidor sobre bugs que podem permitir injeção maliciosa, instrua o navegador a POST relatórios de violação no formato JSON para um local especificado em uma diretiva report-uri:

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

Esses relatórios são assim:

{
    "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
    }
}

O relatório contém informações úteis para encontrar a causa de uma violação de política, incluindo a página em que ela aconteceu (document-uri), o referrer dessa página, o recurso que violou a política da página (blocked-uri), a diretiva específica que foi violada (violated-directive) e a política completa da página (original-policy).

Somente relatórios

Se você está começando a usar o CSP, recomendamos usar o modo somente relatório para avaliar o estado do app antes de mudar a política. Para fazer isso, em vez de enviar um cabeçalho Content-Security-Policy, envie um cabeçalho Content-Security-Policy-Report-Only:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

A política especificada no modo somente relatório não bloqueia recursos restritos, mas envia relatórios de violação ao local que você especificar. Você pode até enviar ambos os cabeçalhos para aplicar uma política enquanto monitora outra. Essa é uma ótima maneira de testar alterações na sua CSP e aplicar sua política atual: ative os relatórios de uma nova política, monitore os relatórios de violação e corrija bugs e, quando estiver satisfeito com a nova política, comece a aplicá-la.

Uso no mundo real

A primeira etapa para criar uma política para seu app é avaliar os recursos que ele carrega. Depois de entender a estrutura do app, crie uma política com base nos requisitos dele. As seções a seguir mostram alguns casos de uso comuns e o processo de decisão para oferecer suporte a eles seguindo as diretrizes da CSP.

Widgets de mídias sociais

• O botão de curtidas do Facebook tem várias opções de implementação. Recomendamos usar a versão <iframe> para manter o sandbox do resto do site. Ela precisa de uma diretiva child-src https://facebook.com para funcionar corretamente.
• O botão de Tuíte do X depende do acesso a um script. Mova o script que ele fornece para um arquivo JavaScript externo e use a diretiva script-src https://platform.twitter.com; child-src https://platform.twitter.com.
• Outras plataformas têm requisitos similares e podem ser endereçadas de forma parecida. Para testar esses recursos, recomendamos configurar um default-src de 'none' e consultar seu console para determinar quais recursos você precisará ativar.

Para usar vários widgets, combine as diretivas da seguinte maneira:

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Bloqueio total

Em alguns sites, é importante garantir que apenas recursos locais possam ser carregados. O exemplo a seguir desenvolve um CSP para um site bancário, começando com uma política padrão que bloqueia tudo (default-src 'none').

O site carrega todas as imagens, estilos e scripts de um CDN em https://cdn.mybank.net e se conecta a https://api.mybank.com/ usando XHR para extrair dados. Ele usa frames, mas apenas para páginas locais do site (sem origens de terceiros). Não há Flash, fontes nem extras no site. O cabeçalho CSP mais restritivo que ele pode enviar é este:

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Somente SSL

Confira abaixo um exemplo de CSP para um administrador de fórum que quer garantir que todos os recursos no fórum sejam carregados apenas usando canais seguros, mas não tem experiência em programação e não tem os recursos para reescrever o software de fórum de terceiros cheio de scripts e estilos inline:

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'

Embora https: seja especificado em default-src, as diretivas de script e estilo não herdam essa origem automaticamente. Cada diretiva substitui o padrão para esse tipo específico de recurso.

Desenvolvimento de CSP padrão

A Política de segurança de conteúdo de nível 2 é um padrão recomendado do W3C. O Web Application Security Working Group do W3C está desenvolvendo a próxima iteração da especificação, a Política de segurança de conteúdo de nível 3.

Para acompanhar a discussão sobre esses recursos futuros, consulte os arquivos da lista de e-mails public-webappsec@.