Política de Segurança de Conteúdo

A Política de Segurança de Conteúdo (abreviado CSP ) é um mecanismo de segurança padronizado para restringir a origem do conteúdo (como um script JavaScript , folha de estilo etc.) em uma página da web para determinados sites autorizados. Em particular, torna possível proteger melhor contraataques de injeção de código , como ataques de cross-site scripting (abreviado como XSS) ou por sequestro . Esses ataques baseiam-se principalmente na execução de código malicioso em um site onde o usuário se sente confiante. Sua terceira versão é atualmente um candidato a recomendação para o W3C Working Group on Web Application Security.

O CSP fornece um método padrão para proprietários de sites declararem origens confiáveis ​​de conteúdo que os navegadores devem ter permissão para enviar para este site. Os tipos abrangidos são scripts JavaScript , CSS , frames HTML (in) , Worker Web (in) , fontes , imagens, objetos incorporáveis, como miniaplicativos Java , ActiveX , arquivos de áudio ou vídeo e outros recursos HTML5 .

A maioria dos navegadores modernos oferece suporte a esse mecanismo em sua primeira versão. Aqueles que não suportam esta especificação simplesmente ignoram o cabeçalho, de forma que seja transparente para o visitante.

Status

O padrão, originalmente chamado de Content Restrictions, foi proposto por Robert Hansen em 2004 e foi implementado pela primeira vez no Firefox 4, que logo foi seguido por outros navegadores. A primeira versão do padrão foi publicada em 2012 como uma recomendação do W3C que rapidamente gerou outras versões publicadas em 2014. Um rascunho da terceira versão ainda está em desenvolvimento com novos recursos já adotados pelos navegadores da web.

Os seguintes nomes de cabeçalho são usados ​​como implementações experimentais de CSP:

Um site pode declarar vários cabeçalhos CSP diferentes. Cada cabeçalho será processado separadamente pelo navegador.

Princípio da Operação

Os ataques de script entre sites ( XSS ) exploram a confiança que os navegadores têm no conteúdo recebido dos servidores. Scripts maliciosos podem ser executados nos navegadores das vítimas porque as vítimas confiam cegamente no servidor que lhes envia os dados, mesmo quando eles não vêm de onde parecem vir.

O CSP permite que os administradores do sistema reduzam ou eliminem os meios de realizar ataques XSS, permitindo especificar os domínios autorizados para fornecer scripts para a página visitada. Os navegadores compatíveis com CSP então executam scripts apenas de uma origem permitida pelas regras de CSP e ignoram aquelas que não são permitidas. Podemos então bloquear domínios não autorizados, scripts inline (incluídos em uma página HTML) ou associados a eventos por meio de atributos HTML dedicados.

O nível mais alto de proteção seria então não permitir a execução de nenhum script.

O CSP também permite forçar o uso de HTTPS para determinados domínios, bem como o uso de cookies seguros, que só podem ser enviados via HTTPS, a fim de melhorar a segurança. Além do uso espúrio de CSP para esta função, o uso do cabeçalho Strict-Transport-Securitygarante que os navegadores necessariamente usem conexões criptografadas TLS (HTTPS).

usar

O CSP pode ser ativado de duas maneiras diferentes por um servidor web:

O cabeçalho é seguido por uma string contendo a lista de regras que constituem a regra CSP: . Uma regra CSP permite que você especifique valores para controlar os recursos que o navegador tem permissão para carregar para a página fornecida. Content-Security-Policy: règle

Uma regra é definida por uma série de diretivas em que cada uma descreve um comportamento esperado para um determinado tipo de conteúdo ou para todas as solicitações.

Três diretrizes comuns são:

  1. default-src : que se aplica a recursos para os quais nenhuma regra foi definida.
  2. script-src : que define fontes válidas para scripts JavaScript .
  3. style-src : que define fontes válidas para folhas de estilo CSS .
Exemplos de regras CSP
  1. Queremos que todo o conteúdo do site seja fornecido pela mesma fonte (excluímos subdomínios): Content-Security-Policy: default-src 'self';
  2. Queremos que todo o conteúdo do site seja fornecido pelo próprio site ou pelos subdomínios de source-sure.example.net : Content-Security-Policy: default-src 'self' *.source-sure.example.net;
  3. Queremos que todos os dados sejam transmitidos por HTTPS de um domínio específico: Content-Security-Policy: default-src https://confidentiel.example.net esta regra força o uso de HTTPS e exclui qualquer uso de conteúdo que não venha de https://confidentiel.example.net.
Testes de regra CSP

Para testar a implantação de CSP em um servidor, ele pode ser configurado para relatar violações de regra sem realmente aplicar a regra. Dessa forma, não bloqueamos o uso do site, recuperando relatórios de violação de regra durante a fase de teste.

Para fazer isso, basta usar o cabeçalho Content-Security-Policy-Report-Only(CSPRO) da mesma forma que CSP:

Content-Security-Policy-Report-Only: règle

Se os cabeçalhos HTTP Content-Security-Policy-Report-Onlye Content-Security-Policyestiverem presentes em uma resposta do servidor, ambas as regras serão respeitadas, permitindo que uma nova regra seja testada, mantendo o uso de regras pré-existentes. As regras CSP são aplicadas enquanto as regras CSPRO geram relatórios, mas não são aplicadas.

Relatórios de erros

Se alguma vez a execução de um script ou recurso solicitado violar a Política, o navegador emitirá uma solicitação POSTaos URLs especificados em report-uri, que conterão os detalhes da violação. Portanto, a diretiva deve report-uriser especificada com pelo menos um URL válido.

Por exemplo :

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

Os relatórios de erros CSP são estruturas JSON padrão que podem ser capturadas pela API do aplicativo em uso ou por servidores públicos de relatórios de erros CSP.

Notas e referências

  1. (em) "  Política de Segurança de Conteúdo Nível 3  "
  2. (em) "  política de segurança de conteúdo 1.0  " em caniuse.com (acessado em 17 de dezembro de 2018 )
  3. (in) Robert Hansen, "  Política de segurança de conteúdo da Mozilla  " Restrições de conteúdo - uma maneira dos sites informarem o navegador para aumentar sua segurança nas páginas em que o site sabe que o conteúdo é do usuário e, portanto, enviado como potencialmente perigoso. [ arquivo de18 de março de 2015] , em web.archive.org ,11 de março de 2009(acessado em 27 de dezembro de 2018 )
  4. (em) Brandon Sterne e Adam Barth, "  Content Security Policy 1.0: W3C Candidate Recommendation  " on w3.org ,15 de novembro de 2012(acessado em 8 de junho de 2020 )
  5. (em) "  política de segurança de conteúdo Nível 3: Rascunho do Editor  " , Trabalho em andamento, em github.com ,4 de dezembro de 2018(acessado em 27 de dezembro de 2018 )
  6. (em) "  Chrome 25 Beta: política de segurança de conteúdo e Shadow DOM  " no blog.chromium.org ,14 de janeiro de 2013(acessado em 27 de dezembro de 2018 )
  7. (em) "  Política de segurança de conteúdo no Firefox 1.0 leva Aurora  " em hacks.mozilla.org ,19 de maio de 2013(acessado em 27 de dezembro de 2018 )
  8. (em) "  Calendário de lançamento do Firefox  " em mozilla.org ,29 de maio de 2013(acessado em 27 de dezembro de 2018 )
  9. (em) "  Bug 96765 - Implementar o cabeçalho" Content-Security-Policy ".  » , No WebKit ,31 de outubro de 2012(acessado em 27 de dezembro de 2018 )
  10. (em) "  Novos recursos de segurança do Chromium, junho de 2011  " em blog.chromium.org ,14 de junho de 2011(acessado em 27 de dezembro de 2018 )
  11. (em) "  Política de segurança de conteúdo (CSP)  " , em mozilla.org (acessado em 27 de dezembro de 2018 )
  12. Contribuidores de MDN, "  Política de Segurança de Conteúdo (CSP)  " , no Mozilla ,21 de novembro de 2019(acessado em 8 de junho de 2020 )
  13. (in) Contribuidores DND, "  CSP: default-src  " no Mozilla ,2 de junho de 2020(acessado em 8 de junho de 2020 )
  14. (in) Colaboradores DND, "  CSP: script src  " no Mozilla ,21 de julho de 2019(acessado em 8 de junho de 2020 )
  15. (in) Contributors DND "  Content-Security-Policy-Report-Only  " no Mozilla ,7 de maio de 2020(acessado em 8 de junho de 2020 )