Utiliser eval() dans des iFrames en bac à sable

Le système d'extensions de Chrome applique une Content Security Policy (CSP) par défaut assez stricte. Les restrictions imposées par nos règles sont simples: le script doit être déplacé hors ligne dans les fichiers JavaScript, les gestionnaires d'événements intégrés doivent être convertis pour utiliser addEventListener, et eval() est est désactivé.

Nous reconnaissons toutefois que de nombreuses bibliothèques utilisent des constructions semblables à eval() et eval, comme new Function(), pour optimiser les performances et faciliter l'expression. Les bibliothèques de modèles particulièrement sujette à ce style d’implémentation. Certains (comme Angular.js) sont compatibles avec CSP. standard, de nombreux frameworks populaires n'ont pas encore adopté de mécanisme compatible avec "Extensions" dans un monde sans eval. La suppression de la prise en charge de cette fonctionnalité s'est donc révélée plus problématique que prévu pour les développeurs.

Ce document présente le bac à sable, un mécanisme sécurisé pour inclure ces bibliothèques dans vos projets. sans compromettre la sécurité.

Pourquoi utiliser le bac à sable ?

eval est dangereux dans une extension, car le code qu'il exécute a accès à tout dans l'environnement à autorisation élevée de l'extension. De nombreuses API chrome.* puissantes sont disponibles et peuvent avoir un impact important sur la sécurité et la confidentialité d'un utilisateur. L'exfiltration de données simple n'est que le moindre de nos soucis. La solution proposée est un bac à sable dans lequel eval peut exécuter du code sans accéder aux ou ses API à forte valeur ajoutée. Pas de données, pas d'API, pas de problème.

Pour ce faire, nous classons certains fichiers HTML dans le package d'extension comme étant "bac à sable". Chaque fois qu'une page en bac à sable est chargée, elle est déplacée vers une origine unique et sa diffusion est refusée. Accès aux API chrome.*. Si nous chargeons cette page en bac à sable dans notre extension via un iframe, nous pouvons transmettre des messages, le laisser agir en fonction de ces messages et attendre qu'il nous renvoie résultat. Ce mécanisme de messagerie simple nous fournit tout ce dont nous avons besoin pour inclure de manière sécurisée le code eval dans le workflow de notre extension.

Créer et utiliser un bac à sable

Si vous souhaitez vous lancer directement dans le code, téléchargez l'extension d'exemple de bac à sable et commencez. Il s'agit d'un exemple fonctionnel d'une petite API de messagerie basée sur la bibliothèque de modèles Handlebars. Elle devrait vous fournir tout ce dont vous avez besoin pour vous lancer. Pour ceux d'entre vous qui un peu plus d'explications, examinons ensemble cet exemple ici.

Répertorier les fichiers dans le fichier manifeste

Chaque fichier devant être exécuté dans un bac à sable doit être répertorié dans le fichier manifeste de l'extension en ajoutant un sandbox. Il s'agit d'une étape critique et facile à oublier, alors vérifiez que votre fichier en bac à sable est listé dans le fichier manifeste. Dans cet exemple, nous mettons en bac à sable le fichier astucieusement nommé "sandbox.html". L'entrée du fichier manifeste se présente comme suit:

{
  ...,
  "sandbox": {
     "pages": ["sandbox.html"]
  },
  ...
}

Charger le fichier dans un bac à sable

Pour effectuer des opérations intéressantes avec le fichier en bac à sable, nous devons le charger dans un contexte où il peut être adressé par le code de l'extension. Ici, sandbox.html a été chargé dans une page d'extension via un iframe. Le fichier JavaScript de la page contient du code qui envoie un message dans le bac à sable dès qu'un clic est effectué sur l'action du navigateur en recherchant iframe sur la page et appeler postMessage() sur son contentWindow. Le message est un objet contenant trois propriétés: context, templateName et command. Nous allons examiner context et command dans un instant.

service-worker.js :

chrome.action.onClicked.addListener(() => {
  chrome.tabs.create({
    url: 'mainpage.html'
  });
  console.log('Opened a tab with a sandboxed page!');
});

extension-page.js:

let counter = 0;
document.addEventListener('DOMContentLoaded', () => {
  document.getElementById('reset').addEventListener('click', function () {
    counter = 0;
    document.querySelector('#result').innerHTML = '';
  });

  document.getElementById('sendMessage').addEventListener('click', function () {
    counter++;
    let message = {
      command: 'render',
      templateName: 'sample-template-' + counter,
      context: { counter: counter }
    };
    document.getElementById('theFrame').contentWindow.postMessage(message, '*');
  });

Faire quelque chose de dangereux

Lors du chargement de sandbox.html, il charge la bibliothèque Handlebars, puis crée et compile une ligne de la même manière que Handlebars suggère:

extension-page.html:

<!DOCTYPE html>
<html>
  <head>
    <script src="mainpage.js"></script>
    <link href="styles/main.css" rel="stylesheet" />
  </head>
  <body>
    <div id="buttons">
      <button id="sendMessage">Click me</button>
      <button id="reset">Reset counter</button>
    </div>

    <div id="result"></div>

    <iframe id="theFrame" src="sandbox.html" style="display: none"></iframe>
  </body>
</html>

sandbox.html :

   <script id="sample-template-1" type="text/x-handlebars-template">
      <div class='entry'>
        <h1>Hello</h1>
        <p>This is a Handlebar template compiled inside a hidden sandboxed
          iframe.</p>
        <p>The counter parameter from postMessage() (outer frame) is:
          </p>
      </div>
    </script>

    <script id="sample-template-2" type="text/x-handlebars-template">
      <div class='entry'>
        <h1>Welcome back</h1>
        <p>This is another Handlebar template compiled inside a hidden sandboxed
          iframe.</p>
        <p>The counter parameter from postMessage() (outer frame) is:
          </p>
      </div>
    </script>

Cela ne doit pas échouer. Même si Handlebars.compile finit par utiliser new Function, tout fonctionne exactement comme prévu, et nous obtenons un modèle compilé dans templates['hello'].

Transmettre le résultat

Nous allons rendre ce modèle disponible en configurant un écouteur de messages qui accepte les commandes de la page de l'extension. Nous utiliserons l'command transmise pour déterminer ce qui doit être fait (vous pouvez imaginer faire plus que simplement effectuer un rendu, peut-être créer des modèles ? Peut-être que vous les gérerez méthode ?), et l'élément context est transmis directement au modèle pour l'affichage. Le code HTML affiché sera renvoyé à la page de l'extension afin qu'elle puisse l'utiliser plus tard :

 <script>
      const templatesElements = document.querySelectorAll(
        "script[type='text/x-handlebars-template']"
      );
      let templates = {},
        source,
        name;

      // precompile all templates in this page
      for (let i = 0; i < templatesElements.length; i++) {
        source = templatesElements[i].innerHTML;
        name = templatesElements[i].id;
        templates[name] = Handlebars.compile(source);
      }

      // Set up message event handler:
      window.addEventListener('message', function (event) {
        const command = event.data.command;
        const template = templates[event.data.templateName];
        let result = 'invalid request';

       // if we don't know the templateName requested, return an error message
        if (template) {
          switch (command) {
            case 'render':
              result = template(event.data.context);
              break;
            // you could even do dynamic compilation, by accepting a command
            // to compile a new template instead of using static ones, for example:
            // case 'new':
            //   template = Handlebars.compile(event.data.templateSource);
            //   result = template(event.data.context);
            //   break;
              }
        } else {
            result = 'Unknown template: ' + event.data.templateName;
        }
        event.source.postMessage({ result: result }, event.origin);
      });
    </script>

De retour sur la page de l'extension, nous recevrons ce message. Nous effectuerons une opération intéressante avec html de données qui ont été transmises. Dans ce cas, nous allons simplement l'échouer via une notification, mais il est tout à fait possible d'utiliser ce code HTML en toute sécurité dans l'interface utilisateur de l'extension. Insertion via innerHTML ne présente pas de risque de sécurité important, car nous faisons confiance au contenu affiché dans le bac à sable.

Ce mécanisme facilite la création de modèles, mais ne se limite évidemment pas à la création de modèles. Tout code qui ne fonctionne pas immédiatement sous une règle de sécurité du contenu stricte peut être placé dans un bac à sable. En fait, il est souvent utile de placer dans un bac à sable les composants de vos extensions qui s'exécuteraient correctement afin de limiter chaque partie de votre programme au plus petit ensemble de privilèges nécessaire pour son exécution. La présentation Écrire des applications Web sécurisées et des extensions Chrome de Google I/O 2012 donne de bons exemples de ces techniques en action et vous fera gagner 56 minutes.