Utiliser l'évaluation dans les extensions Chrome

Le système d'extensions de Chrome applique une règle Content Security Policy (CSP) par défaut assez stricte. Les restrictions des règles sont simples: le script doit être déplacé hors ligne dans des fichiers JavaScript distincts, les gestionnaires d'événements intégrés doivent être convertis pour utiliser addEventListener, et eval() est désactivé. Les applications Chrome appliquent des règles encore plus strictes et nous sommes satisfaits des propriétés de sécurité qu'elles fournissent.

Nous sommes toutefois conscients que diverses bibliothèques utilisent des constructions de type eval() et eval, telles que new Function(), pour optimiser les performances et faciliter l'expression. Les bibliothèques de modèles sont particulièrement sujettes à ce style d'implémentation. Bien que certains (comme Angular.js) soient compatibles avec CSP par défaut, de nombreux frameworks courants ne disposent pas encore d'un mécanisme compatible avec l'environnement sans eval des extensions. 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é permettant d'inclure ces bibliothèques dans vos projets sans compromettre la sécurité. Par souci de concision, nous utiliserons le terme extensions tout au long de la conception, mais ce concept s'applique également aux applications.

Pourquoi utiliser le bac à sable ?

eval est dangereux dans une extension, car le code qu'elle exécute a accès à tous les éléments de l'environnement de haute autorisation de l'extension. Une multitude d'API chrome.* performantes sont disponibles et peuvent avoir un impact important sur la sécurité et la confidentialité des utilisateurs. L'exfiltration simple des données ne nous pose pas de problème. La solution proposée est un bac à sable dans lequel eval peut exécuter du code sans accéder aux données de l'extension ni aux API à forte valeur ajoutée de celle-ci. Pas de données, pas d'API, pas de problème.

Pour ce faire, nous indiquons que des fichiers HTML spécifiques du package de l'extension sont en bac à sable. Chaque fois qu'une page en bac à sable est chargée, elle est déplacée vers une origine unique et se voit refuser l'accès aux API chrome.*. Si nous chargeons cette page en bac à sable dans notre extension via un iframe, nous pouvons lui transmettre des messages, le laisser agir sur ces messages d'une manière ou d'une autre et attendre qu'elle nous renvoie un résultat. Ce mécanisme de messagerie simple nous fournit tout ce dont nous avons besoin pour inclure en toute sécurité du code basé sur eval dans le workflow de notre extension.

Créer et utiliser un bac à sable

Si vous souhaitez vous plonger directement dans le code, veuillez vous procurer l'exemple d'extension de bac à sable et le décollage. Il s'agit d'un exemple concret d'API de messagerie miniature construite sur la bibliothèque de modèles Handlebars. Elle devrait vous fournir tout ce dont vous avez besoin pour commencer. Pour ceux d'entre vous qui souhaitent obtenir plus d'explications, examinons cet exemple ensemble.

Lister 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 une propriété sandbox. Il s'agit d'une étape essentielle et on peut facilement l'oublier. Veuillez donc vérifier que votre fichier en bac à sable figure dans le fichier manifeste. Dans cet exemple, nous exécutons un bac à sable pour le fichier astucieux nommé "sandbox.html". L'entrée du fichier manifeste se présente comme suit:

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

Charger le fichier en bac à sable

Pour effectuer une opération intéressante avec le fichier en bac à sable, nous devons le charger dans un contexte où le code de l'extension peut le résoudre. Ici, sandbox.html a été chargé dans la page d'événements de l'extension (eventpage.html) via un iframe. eventpage.js contient du code qui envoie un message dans le bac à sable chaque fois que l'utilisateur clique sur l'action du navigateur. Pour ce faire, il recherche iframe sur la page et exécute la méthode postMessage sur son contentWindow. Le message est un objet contenant deux propriétés: context et command. Nous les aborderons plus en détail dans un instant.

chrome.browserAction.onClicked.addListener(function() {
 var iframe = document.getElementById('theFrame');
 var message = {
   command: 'render',
   context: {thing: 'world'}
 };
 iframe.contentWindow.postMessage(message, '*');
});

Fait quelque chose de dangereux

Lorsque sandbox.html est chargé, il charge la bibliothèque Handlebars, puis crée et compile un modèle intégré comme indiqué par Handlebars:

<script src="handlebars-1.0.0.beta.6.js"></script>
<script id="hello-world-template" type="text/x-handlebars-template">
  <div class="entry">
    <h1>Hello, !</h1>
  </div>
</script>
<script>
  var templates = [];
  var source = document.getElementById('hello-world-template').innerHTML;
  templates['hello'] = Handlebars.compile(source);
</script>

Cela n'échoue pas ! 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'].

Renvoyer le résultat

Nous allons rendre ce modèle utilisable en configurant un écouteur de message qui accepte les commandes de la page d'événement. Nous utiliserons l'élément command transmis pour déterminer l'action à effectuer (vous pourriez imaginer faire plus que simplement afficher ; par exemple créer des modèles ? Peut-être les gérer d'une manière ou d'une autre ?), et context sera directement transmis au modèle pour le rendu. Le code HTML rendu sera renvoyé à la page d'événement afin que l'extension puisse en faire quelque chose d'utile par la suite:

<script>
  window.addEventListener('message', function(event) {
    var command = event.data.command;
    var name = event.data.name || 'hello';
    switch(command) {
      case 'render':
        event.source.postMessage({
          name: name,
          html: templates[name](event.data.context)
        }, event.origin);
        break;

      // case 'somethingElse':
      //   ...
    }
  });
</script>

De retour sur la page "Événement", nous allons recevoir ce message et effectuer une action intéressante avec les données html qui nous ont été transmises. Dans ce cas, nous nous contenterons de renvoyer ce code via une notification sur ordinateur, mais il est tout à fait possible d'utiliser ce code HTML de manière sécurisée dans l'interface utilisateur de l'extension. Son insertion via innerHTML ne présente pas de risque de sécurité important, car même un compromis complet du code en bac à sable par une attaque intelligente ne permettrait pas d'injecter du contenu dangereux de script ou de plug-in dans le contexte de l'extension à haute autorisation.

Ce mécanisme facilite la création de modèles, mais il ne se limite évidemment pas à la création de modèles. Tout code qui ne fonctionne pas directement avec une Content Security Policy stricte peut être exécuté en bac à sable. En fait, il est souvent utile de créer un bac à sable pour les composants de vos extensions qui s'exécutent correctement afin de limiter chaque élément de votre programme au plus petit ensemble de droits nécessaire à son exécution correcte. La présentation Écrire des applications Web sécurisées et des extensions Chrome de la conférence Google I/O 2012 présente de bons exemples d'utilisation concrète de ces techniques. Elle vaut 56 minutes de votre temps.