Solicitações de rede de origem cruzada

Páginas da Web normais podem usar as APIs fetch() ou XMLHttpRequest para enviar e receber dados de servidores remotos, mas são limitadas pela mesma política de origem. Os scripts de conteúdo iniciam solicitações em nome da origem da Web em que o script de conteúdo foi injetado. Portanto, eles também estão sujeitos à mesma política de origem. As origens da extensão não são tão limitadas. Um script executado em um service worker de extensão ou em uma guia em primeiro plano pode se comunicar com servidores remotos fora da origem, desde que a extensão solicite permissões de origem cruzada.

Origem da extensão

Cada extensão em execução existe na própria origem de segurança. Sem solicitar privilégios extras, a extensão pode chamar fetch() para receber recursos na instalação. Por exemplo, se uma extensão contiver um arquivo de configuração JSON chamado config.json, em uma pasta config_resources/, a extensão poderá recuperar o conteúdo do arquivo da seguinte forma:

const response = await fetch('/config_resources/config.json');
const jsonData = await response.json();

Se a extensão tentar usar uma origem de segurança diferente dela, como https://www.google.com, o navegador não vai permitir isso, a menos que a extensão tenha solicitado as permissões de origem cruzada apropriadas.

Solicitar permissões de origem cruzada

Para solicitar acesso a servidores remotos fora da origem de uma extensão, adicione hosts, padrões de correspondência ou ambos à seção host_permissions do arquivo manifest.

{
  "name": "My extension",
  ...
  "host_permissions": [
    "https://www.google.com/"
  ],
  ...
}

Os valores de permissão de origem cruzada podem ser nomes de host totalmente qualificados, como estes:

• "https://www.google.com/"
• "https://www.gmail.com/"

Ou podem corresponder padrões, como estes:

• "https://*.google.com/"
• "https://*/"

Um padrão de correspondência "https://*/" permite o acesso HTTPS a todos os domínios acessíveis. Aqui, os padrões de correspondência são semelhantes aos padrões de correspondência de scripts de conteúdo, mas qualquer informação de caminho que siga o host é ignorada.

O acesso é concedido pelo host e pelo esquema. Se uma extensão quiser acesso HTTP seguro e não seguro a um determinado host ou conjunto de hosts, ela precisará declarar as permissões separadamente:

"host_permissions": [
  "http://www.google.com/",
  "https://www.google.com/"
]

Fetch() x XMLHttpRequest()

O fetch() foi criado especificamente para service workers e segue uma tendência da Web mais ampla, além das operações síncronas. A API XMLHttpRequest() tem suporte de extensões fora do service worker, e chamá-la aciona o gerenciador de busca desse service worker. O novo trabalho precisa favorecer fetch() sempre que possível.

Considerações sobre segurança

Evite vulnerabilidades de scripting em vários sites

Ao usar recursos recuperados por fetch(), o documento fora da tela, o painel lateral ou o pop-up precisa ter cuidado para não ser vítima de scripts entre sites. Especificamente, evite o uso de APIs perigosas, como innerHTML. Exemplo:

const response = await fetch("https://api.example.com/data.json");
const jsonData = await response.json();
// WARNING! Might be injecting a malicious script!
document.getElementById("resp").innerHTML = jsonData;
    ...

Em vez disso, prefira APIs mais seguras que não executam scripts:

const response = await fetch("https://api.example.com/data.json");
const jsonData = await response.json();
// JSON.parse does not evaluate the attacker's scripts.
let resp = JSON.parse(jsonData);

const response = await fetch("https://api.example.com/data.json");
const jsonData = response.json();
// textContent does not let the attacker inject HTML elements.
document.getElementById("resp").textContent = jsonData;

Limitar o acesso ao script de conteúdo a solicitações de origem cruzada

Ao fazer solicitações de origem cruzada em nome de um script de conteúdo, tome cuidado para proteger contra páginas da Web maliciosas que podem tentar falsificar a identidade de um script de conteúdo. Especificamente, não permita que os scripts de conteúdo solicitem um URL arbitrário.

Considere um exemplo em que uma extensão executa uma solicitação de origem cruzada para permitir que um script de conteúdo descubra o preço de um item. Uma abordagem não tão segura seria fazer com que o script de conteúdo especifique o recurso exato a ser buscado pela página em segundo plano.

chrome.runtime.onMessage.addListener(
  function(request, sender, sendResponse) {
    if (request.contentScriptQuery == 'fetchUrl') {
      // WARNING: SECURITY PROBLEM - a malicious web page may abuse
      // the message handler to get access to arbitrary cross-origin
      // resources.
      fetch(request.url)
        .then(response => response.text())
        .then(text => sendResponse(text))
        .catch(error => ...)
      return true;  // Will respond asynchronously.
    }
  }
);

chrome.runtime.sendMessage(
  {
    contentScriptQuery: 'fetchUrl',
    url: `https://another-site.com/price-query?itemId=${encodeURIComponent(request.itemId)}`
  },
  response => parsePrice(response.text())
);

Na abordagem acima, o script de conteúdo pode solicitar que a extensão busque qualquer URL a que a extensão tenha acesso. Uma página da Web maliciosa pode forjar essas mensagens e enganar a extensão para conceder acesso a recursos de origem cruzada.

Em vez disso, crie gerenciadores de mensagens que limitem os recursos que podem ser buscados. Abaixo, somente o itemId é fornecido pelo script de conteúdo, e não o URL completo.

chrome.runtime.onMessage.addListener(
  function(request, sender, sendResponse) {
    if (request.contentScriptQuery == 'queryPrice') {
      const url = `https://another-site.com/price-query?itemId=${encodeURIComponent(request.itemId)}`
      fetch(url)
        .then(response => response.text())
        .then(text => parsePrice(text))
        .then(price => sendResponse(price))
        .catch(error => ...)
      return true;  // Will respond asynchronously.
    }
  }
);

chrome.runtime.sendMessage(
  {contentScriptQuery: 'queryPrice', itemId: 12345},
  price => ...
);

Preferir HTTPS em vez de HTTP

Além disso, tenha muito cuidado com recursos recuperados por HTTP. Se a extensão for usada em uma rede hostil, um invasor da rede (também conhecido como "man-in-the-middle") poderá modificar a resposta e possivelmente atacar sua extensão. Em vez disso, prefira HTTPS sempre que possível.

Ajustar a Política de Segurança de Conteúdo

Se você modificar a Política de Segurança de Conteúdo padrão da extensão adicionando um atributo content_security_policy ao manifesto, será necessário garantir que todos os hosts a que você quer se conectar sejam permitidos. Embora a política padrão não restrinja as conexões a hosts, tenha cuidado ao adicionar explicitamente as diretivas connect-src ou default-src.