XMLHttpRequest de origem cruzada

Aviso:você está vendo a versão descontinuada do Manifesto V2 deste artigo. Consulte Manifesto V3 - Solicitações de rede de origem cruzada para obter o equivalente em MV3. A Chrome Web Store não aceita mais extensões do Manifest V2. Siga o guia de migração do Manifest V3 para converter sua extensão para o Manifest V3.

Páginas da Web normais podem usar o objeto 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. Os scripts de conteúdo estão sujeitos à CORB desde o Chrome 73 e ao CORS desde o Chrome 83. As origens da extensão não são tão limitadas. Um script executado na página de plano de fundo de uma extensão ou na 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 adicionais, a extensão pode usar XMLHttpRequest para conseguir 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:

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = handleStateChange; // Implemented elsewhere.
xhr.open("GET", chrome.extension.getURL('/config_resources/config.json'), true);
xhr.send();

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.

Como solicitar permissões de origem cruzada

Ao adicionar hosts ou padrões de correspondência de host (ou ambos) à seção de permissões do arquivo de manifesto, a extensão pode solicitar acesso a servidores remotos fora da origem.

{
  "name": "My extension",
  ...
  "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:

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

Considerações sobre segurança

Como evitar vulnerabilidades de scripting em vários sites

Ao usar recursos recuperados por XMLHttpRequest, sua página em segundo plano precisa ter cuidado para não ser vítima de scripts entre sites. Especificamente, evite o uso de APIs perigosas como as abaixo:

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://api.example.com/data.json", true);
xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
    // WARNING! Might be evaluating an evil script!
    var resp = eval("(" + xhr.responseText + ")");
    ...
  }
}
xhr.send();

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://api.example.com/data.json", true);
xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
    // WARNING! Might be injecting a malicious script!
    document.getElementById("resp").innerHTML = xhr.responseText;
    ...
  }
}
xhr.send();

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

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://api.example.com/data.json", true);
xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
    // JSON.parse does not evaluate the attacker's scripts.
    var resp = JSON.parse(xhr.responseText);
  }
}
xhr.send();

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://api.example.com/data.json", true);
xhr.onreadystatechange = function() {
  if (xhr.readyState == 4) {
    // innerText does not let the attacker inject HTML elements.
    document.getElementById("resp").innerText = xhr.responseText;
  }
}
xhr.send();

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 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') {
        var 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 para apps ou extensões 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.