Usando a Política de Segurança de Conteúdo (CSP) para controlar quais recursos podem ser executados

Para controlar qual conteúdo pode ser executado pela sua extensão, no arquivo da manifest.json extensão, use a content_security_policy chave e seu valor de cadeia de caracteres de política, de acordo com a seguinte sintaxe:

{
    ...,
    "content_security_policy": "[policy string]"
    ...
}

Por exemplo, a seguinte é a política de segurança de conteúdo padrão, conforme descrito abaixo em Restrições de política padrão:

{
    ...,
    "content_security_policy": "script-src 'self'; object-src 'self'; worker-src 'self'"
    ...
}

Para mitigar uma grande classe de possíveis problemas de script entre sites, o sistema de extensão Microsoft Edge incorpora a Política de Segurança de Conteúdo (CSP). O CSP apresenta algumas políticas estritas que tornam as extensões mais seguras por padrão e fornece a capacidade de criar e impor regras que regem os tipos de conteúdo que podem ser carregados e executados por suas extensões e aplicativos.

Em geral, o CSP funciona como um mecanismo de lista de bloqueios/permissões para recursos carregados ou executados por sua extensão. A definição de uma política razoável para sua extensão permite que você considere cuidadosamente os recursos que sua extensão requer e peça ao navegador para garantir que esses sejam os únicos recursos aos quais sua extensão tem acesso. As políticas fornecem segurança além das permissões de host que sua extensão solicita; Eles são uma camada adicional de proteção, não uma substituição.

Por outro lado, em uma página da Web, essa política é definida por meio de um cabeçalho HTTP ou por meio de um meta elemento. Mas dentro do sistema de extensão Microsoft Edge, um cabeçalho HTTP ou um meta elemento não é um mecanismo apropriado.

Confira:

Política de Segurança de Conteúdo (CSP) na MDN.
Manifesto - Política de segurança de conteúdo naReferência de extensões> do Chrome.

Restrições da política padrão

Os pacotes que não definem um manifest_version não têm uma política de segurança de conteúdo padrão.

Os pacotes que usam manifest_version têm a seguinte política de segurança de conteúdo padrão:

Manifesto V3
Manifesto V2

script-src 'self'; object-src 'self'; worker-src 'self'

script-src 'self'; object-src 'self'

A política adiciona segurança limitando extensões e aplicativos de três maneiras:

Códigos como os seguintes não funcionam:

alert(eval("foo.bar.baz"));
window.setTimeout("alert('hi')", 10);
window.setInterval("alert('hi')", 10);
new Function("return foo.bar.baz");

Avaliar cadeias de caracteres de JavaScript como essa é um vetor de ataque XSS comum. Em vez disso, você deve escrever código como:

alert(foo && foo.bar && foo.bar.baz);
window.setTimeout(function() { alert('hi'); }, 10);
window.setInterval(function() { alert('hi'); }, 10);
function() { return foo && foo.bar && foo.bar.baz };

JavaScript embutido não são executados

O JavaScript embutido não é executado. Essa restrição proíbe blocos embutidos <script> e manipuladores de eventos embutidos, como <button onclick="...">.

A primeira restrição elimina uma grande classe de ataques de script entre sites, tornando impossível para você executar acidentalmente o script fornecido por um terceiro mal-intencionado. No entanto, ele exige que você escreva seu código com uma separação limpa entre conteúdo e comportamento. Um exemplo pode tornar isso mais claro. Você pode tentar escrever um pop-up de Ação do Navegador como um único pop-up.html contendo o seguinte:

<!doctype html>
<html>
    <head>
        <title>My Awesome Pop-up!</title>
        <script>
            function awesome() {
                // do something awesome!
            }

            function totallyAwesome() {
                // do something TOTALLY awesome!
            }

            function clickHandler(element) {
                setTimeout("awesome(); totallyAwesome()", 1000);
            }

            function main() {
                // Initialization work goes here.
            }
        </script>
    </head>
    <body onload="main();">
        <button onclick="clickHandler(this)">
            Click for awesomeness!
        </button>
    </body>
</html>

Mas três coisas devem mudar para que isso funcione da maneira que você espera:

A clickHandler definição deve ser movida para um arquivo JavaScript externo (popup.js pode ser um bom destino).
As definições do manipulador de eventos embutido devem ser reescritas em termos de e extraídas addEventListener em popup.js. Se você estiver iniciando seu programa usando código como <body onload="main();">, considere substituí-lo conectando-se ao DOMContentLoaded evento do documento ou ao load evento da janela, dependendo de seus requisitos. Use o primeiro, pois geralmente é disparado mais rapidamente.
A setTimeout chamada deve ser reescrita para evitar converter a cadeia de caracteres "awesome(); totallyAwesome()" em JavaScript para execução.

Essas alterações podem ser semelhantes às seguintes:

function awesome() {
    // Do something awesome!
}

function totallyAwesome() {
    // do something TOTALLY awesome!
}

function awesomeTask() {
    awesome();
    totallyAwesome();
}

function clickHandler(e) {
    setTimeout(awesomeTask, 1000);
}

function main() {
    // Initialization work goes here.
}

// Add event listeners once the DOM has fully loaded by listening for the
// `DOMContentLoaded` event on the document, and adding your listeners to
// specific elements when it triggers.
document.addEventListener('DOMContentLoaded', function () {
    document.querySelector('button').addEventListener('click', clickHandler);
    main();
});

<!doctype html>
<html>
    <head>
        <title>My Awesome Pop-up!</title>
        <script src="popup.js"></script>
    </head>
    <body>
        <button>Click for awesomeness!</button>
    </body>
</html>

Somente os recursos locais de script e objeto são carregados

Os recursos de script e objeto só podem ser carregados a partir do pacote de extensão, não da Web em geral. Isso garante que sua extensão execute apenas o código que você aprovou especificamente, impedindo que um invasor de rede ativo redirecione maliciosamente sua solicitação de um recurso.

Em vez de escrever código que dependa do carregamento do jQuery (ou de qualquer outra biblioteca) de uma CDN externa, considere incluir a versão específica do jQuery em seu pacote de extensão. Ou seja, em vez de:

<!doctype html>
<html>
    <head>
        <title>My Awesome Pop-up!</title>
        <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
    </head>
    <body>
        <button>Click for awesomeness!</button>
    </body>
</html>

Em vez disso, use a seguinte abordagem. Baixe o arquivo, inclua-o no seu pacote e escreva:

<!doctype html>
<html>
    <head>
        <title>My Awesome Pop-up!</title>
        <script src="jquery.min.js"></script>
    </head>
    <body>
        <button>Click for awesomeness!</button>
    </body>
</html>

Relaxamento da política padrão

Você pode permitir a execução dos seguintes tipos de script:

Script embutido
Script remoto
JavaScript avaliado

Os detalhes estão abaixo.

Script embutido

Os scripts embutidos podem ser permitidos especificando o hash codificado em base64 do código-fonte na política. Esse hash deve ser prefixado pelo algoritmo de hash usado (sha256, sha384 ou sha512). Para obter um exemplo, consulte Uso de hash do W3C > para <elementos de script>.

Script remoto

Se você precisar de alguns recursos externos de JavaScript ou objeto, poderá relaxar a política até certo ponto colocando na lista de permitidos origens seguras das quais os scripts devem ser aceitos. Verifique se os recursos de tempo de execução carregados com permissões elevadas de uma extensão são exatamente os recursos esperados e não são substituídos por um invasor de rede ativo. Como os ataques man-in-the-middle são triviais e indetectáveis por HTTP, essas origens não são aceitas.

Atualmente, você pode incluir na lista de permitidos origens que têm os seguintes esquemas: blob, filesystem, httpse extension. A parte do host da origem deve ser especificada explicitamente para os https esquemas and extension . Caracteres curinga genéricos, como https:, e https://*.com não são permitidos; curingas de subdomínio, https://* como https://*.example.com são permitidos. Os domínios na lista de sufixos públicos também são vistos como domínios genéricos de nível superior. Para carregar um recurso desses domínios, o subdomínio deve ser listado explicitamente. Por exemplo, https://*.cloudfront.net não é válido, mas https://XXXX.cloudfront.net e https://*.XXXX.cloudfront.net pode ser allowlisted.

Para facilitar o desenvolvimento, os recursos carregados por HTTP de servidores em seu computador local podem ser allowlisted. Você pode incluir na lista de permitidos fontes de script e objeto em qualquer porta de um http://127.0.0.1 ou http://localhost.

A restrição contra recursos carregados por HTTP se aplica somente aos recursos que são executados diretamente. Você ainda é livre, por exemplo, para fazer XMLHTTPRequest conexões com qualquer origem que desejar; a política padrão não restringe connect-src nenhuma das outras diretivas CSP de forma alguma.

Uma definição de política simplificada que permite que os recursos de script sejam carregados por example.com HTTPS pode ter a seguinte aparência:

"content_security_policy": "script-src 'self' https://example.com; object-src 'self'"

Ambos script-src e object-src são definidos pela política. O Microsoft Edge não aceita uma política que não limite cada um desses valores a (pelo menos) 'self'.

JavaScript avaliado

A política em eval() relação a e funções relacionadas, como setTimeout(String), setInterval(String), e new Function(String) pode ser relaxada adicionando-se unsafe-eval à sua política:

"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"

No entanto, você deve evitar relaxar as políticas. Esses tipos de funções são vetores de ataque XSS notórios.

Tornando mais rigorosa a política padrão

Você pode restringir essa política até que ponto sua extensão permitir, a fim de aumentar a segurança, em detrimento da conveniência. Para especificar que sua extensão só pode carregar recursos de qualquer tipo (imagens e assim por diante) do pacote de extensão associado, por exemplo, uma política de default-src 'self' pode ser apropriada.

Scripts de conteúdo

A política que está sendo discutida se aplica às páginas de plano de fundo e às páginas de eventos da extensão. A maneira como os scripts de conteúdo se aplicam aos scripts de conteúdo da extensão é mais complicada.

Os scripts de conteúdo geralmente não estão sujeitos ao CSP da extensão. Como os scripts de conteúdo não são HTML, o principal impacto disso é que eles podem usar eval mesmo que o CSP da extensão não especifique unsafe-eval, embora isso não seja recomendado. Além disso, o CSP da página não se aplica a scripts de conteúdo. Mais complicadas são <script> as marcas que os scripts de conteúdo criam e colocam no DOM da página em que estão sendo executados. Eles são referenciados como scripts injetados no DOM daqui para frente.

Os scripts injetados no DOM que são executados imediatamente após a injeção na página são executados conforme o esperado. Imagine um script de conteúdo com o seguinte código como um exemplo simples:

document.write("<script>alert(1);</script>");

Este script de conteúdo causa um alert imediatamente após o document.write(). Isso é executado independentemente da política especificada por uma página. No entanto, o comportamento se torna mais complicado dentro desse script injetado por DOM e para qualquer script que não seja executado imediatamente após a injeção.

Imagine que sua extensão esteja em execução em uma página que fornece um CSP associado que especifica script-src 'self'. Agora imagine que o script de conteúdo executa o seguinte código:

document.write("<button onclick='alert(1);'>click me</button>'");

Se um usuário clicar nesse botão, o onclick script não será executado. Isso ocorre porque o script não foi executado imediatamente e o código que não é interpretado até que o click evento ocorra não é considerado parte do script de conteúdo, portanto, o CSP da página (não da extensão) restringe o comportamento. E como esse CSP não especifica unsafe-inline, o manipulador de eventos embutido está bloqueado.

A maneira correta de implementar o comportamento desejado nesse caso é adicionar o onclick manipulador como uma função do script de conteúdo, da seguinte maneira:

document.write("<button id='mybutton'>click me</button>'");
var button = document.getElementById('mybutton');
button.onclick = function() {
      alert(1);
};

Outro problema semelhante surge se o script de conteúdo executar o seguinte:

var script = document.createElement('script');
script.innerHTML = 'alert(1);'
document.getElementById('body').appendChild(script);

Nesse caso, o script é executado e o alerta é exibido. No entanto, considere este caso:

var script = document.createElement('script');
script.innerHTML = 'eval("alert(1);")';
=document.getElementById('body').appendChild(script);

Enquanto o script inicial é executado, a chamada para eval é bloqueada. Ou seja, embora o tempo de execução do script inicial seja permitido, o comportamento dentro do script é regulado pelo CSP da página. Portanto, dependendo de como você escreve scripts injetados em DOM em sua extensão, as alterações no CSP da página podem afetar o comportamento de sua extensão.

Como os scripts de conteúdo não são afetados pelo CSP da página, esse é um ótimo motivo para colocar o máximo de comportamento possível de sua extensão no script de conteúdo, em vez de scripts injetados em DOM.

Confira também

Política de Segurança de Conteúdo (CSP) na MDN.
Manifesto - Política de segurança de conteúdo naReferência de extensões> do Chrome.

Observação

Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Google e usadas de acordo com os termos descritos na Licença Creative Commons Atribuição 4.0 Internacional. A página original é encontrada aqui.

Este trabalho está licenciado sob uma Licença Creative Commons Atribuição 4.0 Internacional.

Comentários

Esta página foi útil?

Last updated on 2026-08-24