Cette page a été traduite par l'API Cloud Translation.

XMLHttpRequest multi-origine

Les pages Web standards peuvent utiliser l'objet XMLHttpRequest pour envoyer et recevoir des données à partir de serveurs distants, mais elles sont limitées par les mêmes règles d'origine. Les scripts de contenu lancent des requêtes pour le compte de l'origine Web dans laquelle ils ont été injectés. Ils sont donc également soumis aux mêmes règles relatives à l'origine. (Les scripts de contenu sont soumis à la norme CORB depuis Chrome 73 et au CORS depuis Chrome 83.) Les origines des extensions ne sont pas aussi limitées. Un script exécuté sur la page en arrière-plan ou dans l'onglet au premier plan d'une extension peut communiquer avec des serveurs distants en dehors de son origine, à condition que l'extension demande des autorisations multi-origines.

Origine de l'extension

Chaque extension en cours d'exécution possède sa propre origine de sécurité. Sans demander de privilèges supplémentaires, l'extension peut utiliser XMLHttpRequest pour obtenir des ressources dans son installation. Par exemple, si une extension contient un fichier de configuration JSON appelé config.json situé dans un dossier config_resources, l'extension peut récupérer le contenu du fichier comme suit:

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

Si l'extension tente d'utiliser une origine de sécurité autre que la sienne, par exemple https://www.google.com, le navigateur l'interdit, sauf si l'extension a demandé les autorisations multi-origines appropriées.

Demander des autorisations multi-origines

En ajoutant des hôtes ou des modèles de correspondance d'hôte (ou les deux) à la section permissions du fichier manifeste, l'extension peut demander l'accès aux serveurs distants en dehors de son origine.

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

Les valeurs d'autorisation multi-origine peuvent être des noms d'hôte complets, comme suit:

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

Il peut également s'agir de modèles de correspondance, comme ceux-ci:

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

Le format de correspondance "https://*/" autorise l'accès HTTPS à tous les domaines accessibles. Notez qu'ici, les modèles de correspondance sont semblables aux modèles de correspondance de script de contenu, mais toutes les informations de chemin d'accès suivant l'hôte sont ignorées.

Notez également que l'accès est accordé à la fois par hôte et par schéma. Si une extension souhaite un accès HTTP sécurisé et non sécurisé à un hôte ou à un ensemble d'hôtes donné, elle doit déclarer les autorisations séparément:

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

Points à noter concernant la sécurité

Éviter les failles de script intersites (XSS)

Lorsque vous utilisez des ressources récupérées via XMLHttpRequest, votre page en arrière-plan ne doit pas être victime d'un script intersites. Plus précisément, évitez d'utiliser des API dangereuses telles que:

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();

Privilégiez plutôt des API plus sûres qui n'exécutent pas de 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();

Limiter l'accès au script de contenu pour les demandes multi-origines

Lorsque vous effectuez des requêtes multi-origines au nom d'un script de contenu, veillez à vous prémunir contre les pages Web malveillantes qui pourraient tenter d'usurper l'identité d'un script de contenu. En particulier, n'autorisez pas les scripts de contenu à demander une URL arbitraire.

Prenons l'exemple d'une extension qui effectue une requête multi-origine pour permettre à un script de contenu de découvrir le prix d'un article. Une approche (non sécurisée) consiste à faire en sorte que le script de contenu spécifie la ressource exacte à extraire par la page en arrière-plan.

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()));

Dans l'approche ci-dessus, le script de contenu peut demander à l'extension de récupérer n'importe quelle URL à laquelle elle a accès. Une page Web malveillante peut falsifier de tels messages et inciter l'extension à accéder à des ressources multi-origines.

À la place, concevez des gestionnaires de messages qui limitent les ressources pouvant être extraites. Dans l'exemple ci-dessous, seul itemId est fourni par le script de contenu, et non l'URL complète.

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 => ...);

Préférer HTTPS au HTTP

En outre, faites particulièrement attention aux ressources récupérées via HTTP. Si votre extension est utilisée sur un réseau hostile, un pirate informatique ("man-in-the-middle") pourrait modifier la réponse et potentiellement attaquer votre extension. Dans la mesure du possible, préférez le protocole HTTPS.

Ajuster la Content Security Policy

Si vous modifiez la Content Security Policy par défaut pour les applications ou les extensions en ajoutant un attribut content_security_policy à votre fichier manifeste, vous devez vous assurer que tous les hôtes auxquels vous souhaitez vous connecter sont autorisés. Bien que la stratégie par défaut ne limite pas les connexions aux hôtes, faites preuve de prudence lorsque vous ajoutez explicitement les instructions connect-src ou default-src.