Política de segurança de conteúdo - Content Security Policy

A Política de Segurança de Conteúdo ( CSP ) é um padrão de segurança de computador introduzido para evitar cross-site scripting (XSS), clickjacking e outros ataques de injeção de código resultantes da execução de conteúdo malicioso no contexto de página da web confiável . É uma recomendação candidata do grupo de trabalho do W3C sobre segurança de aplicativos da Web, amplamente suportada por navegadores da Web modernos . O CSP fornece um método padrão para proprietários de sites declararem origens aprovadas de conteúdo que os navegadores devem ter permissão para carregar nesse site - os tipos cobertos são JavaScript , CSS , frames HTML , web workers , fontes , imagens, objetos incorporáveis, como miniaplicativos Java , ActiveX , arquivos de áudio e vídeo e outros recursos HTML5 .

Status

O padrão, originalmente denominado Content Restrictions, foi proposto por Robert Hansen em 2004, implementado pela primeira vez no Firefox 4 e rapidamente adotado por outros navegadores. A versão 1 do padrão foi publicada em 2012 como recomendação candidata do W3C e rapidamente com outras versões (Nível 2) publicadas em 2014. A partir de 2015, o rascunho do Nível 3 está sendo desenvolvido com os novos recursos sendo rapidamente adotados pelos navegadores da web.

Os seguintes nomes de cabeçalho estão em uso como parte de implementações experimentais de CSP:

  • Content-Security-Policy - nome do cabeçalho padrão proposto pelo documento W3C. O Google Chrome oferece suporte a partir da versão 25. O Firefox oferece suporte a partir da versão 23, lançada em 6 de agosto de 2013. O WebKit oferece suporte a partir da versão 528 (compilação noturna). O suporte do Microsoft Edge baseado em Chromium é semelhante ao do Chrome.
  • X-WebKit-CSP - cabeçalho experimental obsoleto introduzido no Google Chrome e outros navegadores baseados em WebKit ( Safari ) em 2011.
  • X-Content-Security-Policy - cabeçalho experimental obsoleto introduzido em navegadores baseados no Gecko 2 (Firefox 4 a Firefox 22, Thunderbird 3.3, SeaMonkey 2.1).

Um site pode declarar vários cabeçalhos CSP, também combinando os de aplicação e somente relatórios. Cada cabeçalho será processado separadamente pelo navegador.

CSP também pode ser entregue dentro do código HTML usando uma tag HTML META , embora neste caso sua eficácia seja limitada.

O Internet Explorer 10 e o Internet Explorer 11 também suportam CSP, mas apenas a diretiva sandbox, usando o X-Content-Security-Policy cabeçalho experimental .

Diversas estruturas de aplicativos da web suportam CSP, por exemplo AngularJS (nativamente) e Django (middleware). As instruções para Ruby on Rails foram postadas pelo GitHub . O suporte da estrutura da Web, entretanto, só é necessário se o conteúdo CSP de alguma forma depender do estado do aplicativo da Web - como o uso da nonce origem. Caso contrário, o CSP é bastante estático e pode ser entregue a partir de camadas de aplicativos da web acima do aplicativo, por exemplo, no balanceador de carga ou servidor da web .

A partir de 2015, uma série de novos padrões de segurança de navegador estão sendo propostos pelo W3C, a maioria deles complementar ao CSP:

  • Subresource Integrity (SRI) , para garantir que apenas arquivos de recursos conhecidos e confiáveis ​​(normalmente JavaScript , CSS ) sejam carregados de servidores de terceiros (normalmente CDNs )
  • Conteúdo misto , para esclarecer a política do navegador pretendido em páginas carregadas por HTTPS e vinculando conteúdo por HTTP de texto simples
  • Solicitações inseguras de atualização , sugerindo aos navegadores como lidar com links legados em páginas migradas para HTTPS
  • Gerenciamento de credenciais , uma API JavaScript unificada para acessar as credenciais do usuário e facilitar esquemas de login complexos,
  • Política de referência , extensão CSP para sugerir ao navegador a geração dos cabeçalhos de referência .

Bypasses

Em dezembro de 2015 e dezembro de 2016, 'nonce' foram publicados alguns métodos para contornar as origens da lista de permissões. Em janeiro de 2016, outro método foi publicado, que aproveita a lista de permissões de CSP em todo o servidor para explorar versões antigas e vulneráveis ​​de bibliotecas JavaScript hospedadas no mesmo servidor (caso frequente com servidores CDN). Em maio de 2017, mais um método foi publicado para contornar o CSP usando o código de estruturas de aplicativos da web.

Modo de operação

Mapeamento entre recursos HTML5 e JavaScript e controles da Política de Segurança de Conteúdo

Se o Content-Security-Policy cabeçalho estiver presente na resposta do servidor, um cliente compatível impõe a política de lista branca declarativa. Um exemplo de objetivo de política é um modo de execução mais rígido para JavaScript, a fim de evitar certos ataques de script entre sites. Na prática, isso significa que vários recursos são desativados por padrão:

  • Código JavaScript inline
    • <script> blocos,
    • Manipuladores de eventos DOM como atributos HTML (por exemplo onclick )
    • Os javascript: links
  • Declarações CSS inline
    • <style> quadra
    • style atribuído a elementos HTML
  • Avaliação de código JavaScript dinâmico
    • eval()
    • argumentos de string para funções setTimeout e setInterval
    • new Function() construtor
  • Declarações CSS Dinâmicas
    • CSSStyleSheet.insertRule() método

Embora o uso de CSP em um novo aplicativo possa ser bastante simples, especialmente com a estrutura JavaScript compatível com CSP , os aplicativos existentes podem exigir alguma refatoração - ou relaxamento da política. A prática de codificação recomendada para aplicativos da web compatíveis com CSP é carregar o código de arquivos de origem externa ( <script src> ), analisar JSON em vez de avaliá-lo e usar EventTarget.addEventListener() para definir manipuladores de eventos.

Notas

Comunicando

Sempre que um recurso solicitado ou execução de script viola a política, o navegador dispara uma POST solicitação com o valor especificado report-uri ou report-to contendo detalhes da violação.

Os relatórios CSP são estruturas JSON padrão e podem ser capturados pela própria API do aplicativo ou por receptores de relatório CSP públicos.

Em 2018, pesquisadores de segurança mostraram como enviar relatórios de falsos positivos para o receptor designado especificado em report-uri . Isso permite que invasores em potencial disparem arbitrariamente esses alarmes e pode torná-los menos úteis no caso de um ataque real. Este comportamento é intencional e não pode ser corrigido, pois o navegador (cliente) está enviando os relatórios.

Isenção de add-ons e extensões do navegador

De acordo com o modelo de processamento CSP (1.0) original (2012–2013), o CSP não deve interferir na operação de complementos ou extensões do navegador instalados pelo usuário. Esse recurso de CSP teria permitido que qualquer complemento, extensão ou Bookmarklet injetasse script em sites, independentemente da origem desse script, e, portanto, estaria isento das políticas de CSP.

No entanto, esta política foi modificada (a partir do CSP 1.1) com a seguinte redação. Observe o uso da palavra "pode" em vez do texto absoluto anterior "deveria (não)":

Nota: Os agentes do usuário podem permitir que os usuários modifiquem ou ignorem a aplicação da política por meio de preferências do usuário, bookmarklets, adições de terceiros ao agente do usuário e outros mecanismos.

O texto "deveria" absoluto estava sendo usado por usuários de navegadores para solicitar / exigir adesão à política e ter alterações instaladas em navegadores populares (Firefox, Chrome, Safari) para oferecer suporte a ela. Isso foi particularmente controverso quando sites como Twitter e GitHub começaram a usar políticas de CSP fortes, que 'quebraram' o uso de Bookmarklets.

O W3C Web Application Security Working Group considera esse script como parte da Trusted Computing Base implementada pelo navegador; no entanto, foi argumentado ao grupo de trabalho por um representante da Cox Communications que essa isenção é uma falha de segurança potencial que pode ser explorada por complementos ou extensões mal-intencionados ou comprometidos.

Veja também

Referências

links externos