„eval“ in Chrome-Erweiterungen verwenden

Für das Erweiterungssystem von Chrome gilt eine ziemlich strenge Standard-Content Security Policy (CSP). Die Richtlinieneinschränkungen sind einfach: Das Skript muss in separate JavaScript-Dateien verschoben und Inline-Event-Handler zur Verwendung von addEventListener konvertiert werden. eval() ist deaktiviert. Für Chrome-Apps gelten noch strengere Richtlinien, und wir sind mit den Sicherheitseigenschaften dieser Richtlinien sehr zufrieden.

Uns ist jedoch bewusst, dass bei einer Vielzahl von Bibliotheken eval()- und eval-ähnliche Konstrukte wie new Function() zur Leistungsoptimierung und einfachen Ausdrucksweise verwendet werden. Vorlagenbibliotheken sind für diesen Implementierungsstil besonders anfällig. Einige (wie Angular.js) unterstützen CSP, aber viele beliebte Frameworks wurden noch nicht auf einen Mechanismus aktualisiert, der mit der Welt ohne eval kompatibel ist. Das Entfernen der Unterstützung für diese Funktionen hat sich für Entwickler daher als problematischer erwiesen.

In diesem Dokument wird das Sandboxing als sicherer Mechanismus vorgestellt, um diese Bibliotheken in Ihre Projekte einzubinden, ohne die Sicherheit zu beeinträchtigen. Der Einfachheit halber verwenden wir den Begriff Erweiterungen durchgehend, aber das Konzept gilt gleichermaßen für Anwendungen.

Warum Sandbox?

eval ist in einer Erweiterung gefährlich, da der ausgeführte Code Zugriff auf alles in der Umgebung mit hohen Berechtigungen der Erweiterung hat. Es gibt eine Vielzahl von leistungsstarken chrome.* APIs, die die Sicherheit und den Datenschutz eines Nutzers erheblich beeinträchtigen können. Eine einfache Daten-Exfiltration ist für uns kein Problem. Die angebotene Lösung ist eine Sandbox, in der eval Code ausführen kann, ohne entweder auf die Daten der Erweiterung oder die hochwertigen APIs der Erweiterung zuzugreifen. Keine Daten, keine APIs, kein Problem.

Dies erreichen wir, indem wir bestimmte HTML-Dateien im Erweiterungspaket als in einer Sandbox ausgeführte Dateien auflisten. Immer wenn eine Seite geladen wird, die in einer Sandbox ausgeführt wird, wird sie an einen eindeutigen Ursprung verschoben und ihnen wird der Zugriff auf chrome.*-APIs verweigert. Wenn wir diese Sandbox-Seite über einen iframe in unsere Erweiterung laden, können wir Nachrichten an sie übergeben, sie in irgendeiner Form auf diese Nachrichten reagieren lassen und warten, bis sie ein Ergebnis zurückgibt. Dieser einfache Messaging-Mechanismus bietet uns alles, was wir benötigen, um eval-gesteuerten Code sicher in den Workflow unserer Erweiterung aufzunehmen.

Sandbox erstellen und verwenden

Wenn Sie direkt mit dem Programmieren beginnen möchten, greifen Sie auf die Sandboxing-Beispielerweiterung zurück. Das ist ein funktionierendes Beispiel für eine kleine Messaging-API, die auf der Vorlagenbibliothek Handlebars aufbaut und Ihnen alles bietet, was Sie für den Anfang brauchen. Diejenigen unter Ihnen, die etwas mehr darüber erfahren möchten, gehen wir das Beispiel hier durch.

Dateien im Manifest auflisten

Jede Datei, die in einer Sandbox ausgeführt werden soll, muss im Erweiterungsmanifest durch Hinzufügen des Attributs sandbox aufgeführt werden. Das ist ein wichtiger Schritt, den man leicht vergessen kann. Prüfe daher noch einmal, ob deine in der Sandbox ausgeführte Datei im Manifest aufgeführt ist. In diesem Beispiel wird die Datei namens "sandbox.html" in einer Sandbox ausgeführt. Der Manifesteintrag sieht so aus:

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

In der Sandbox ausgeführte Datei laden

Um etwas Interessantes mit der Sandbox-Datei zu machen, müssen wir sie in einem Kontext laden, in dem sie vom Code der Erweiterung angesprochen werden kann. Hier wurde sandbox.html über einen iframe in die Ereignisseite der Erweiterung (eventpage.html) geladen. eventpage.js enthält Code, der bei jedem Klick auf die Browseraktion eine Nachricht an die Sandbox sendet. Dazu wird das iframe auf der Seite gesucht und die Methode postMessage auf der zugehörigen contentWindow ausgeführt. Die Nachricht ist ein Objekt mit zwei Attributen: context und command. Wir werden gleich auf beide eingehen.

chrome.browserAction.onClicked.addListener(function() {
 var iframe = document.getElementById('theFrame');
 var message = {
   command: 'render',
   context: {thing: 'world'}
 };
 iframe.contentWindow.postMessage(message, '*');
});
Allgemeine Informationen zur postMessage API findest du in der postMessage-Dokumentation auf der MDN . Er ist vollständig und lesenswert. Beachten Sie insbesondere, dass Daten nur dann hin- und hergereicht werden können, wenn sie serialisierbar sind. Funktionen sind es beispielsweise nicht.

Etwas Gefährliches unternehmen

Wenn sandbox.html geladen wird, wird die Handlebars-Bibliothek geladen und eine Inline-Vorlage erstellt und kompiliert, wie von Handlebars vorgeschlagen:

<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>

Das ist kein Scheitern! Obwohl Handlebars.compile am Ende new Function verwendet, funktioniert alles genau wie erwartet und wir haben am Ende eine kompilierte Vorlage in templates['hello'].

Ergebnis zurücksenden

Wir stellen diese Vorlage zur Verfügung, indem wir einen Nachrichten-Listener einrichten, der Befehle von der Ereignisseite akzeptiert. Wir verwenden das übergebene command, um zu bestimmen, was zu tun ist. (Sie könnten sich mehr vorstellen, als nur zu rendern. Vielleicht könnten Sie Vorlagen erstellen? Verwalten Sie sie vielleicht auf irgendeine Weise?) und context wird zum Rendern direkt an die Vorlage übergeben. Der gerenderte HTML-Code wird an die Ereignisseite zurückgegeben, damit die Erweiterung später nützliche Aktionen ausführen kann:

<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>

Auf der Veranstaltungsseite erhalten wir diese Nachricht und machen etwas Interessantes mit den html-Daten, die uns übergeben wurden. In diesem Fall wird es einfach über eine Desktop-Benachrichtigung wiedergegeben, aber es ist durchaus möglich, den HTML-Code sicher als Teil der Benutzeroberfläche der Erweiterung zu verwenden. Das Einfügen über innerHTML stellt kein nennenswertes Sicherheitsrisiko dar, da selbst eine vollständige Manipulation des in der Sandbox ausgeführten Codes durch einen cleveren Angriff gefährliche Skript- oder Plug-in-Inhalte nicht in den Kontext einer Erweiterung mit Berechtigungen einschleusen könnte.

Dieser Mechanismus macht das Erstellen von Vorlagen einfach, ist aber natürlich nicht auf Vorlagen beschränkt. Jeder Code, der im Rahmen einer strengen Content Security Policy nicht sofort einsatzbereit ist, kann in einer Sandbox ausgeführt werden. Tatsächlich ist es oft nützlich, Komponenten Ihrer Erweiterungen, die ordnungsgemäß ausgeführt würden, in einer Sandbox auszuführen. So begrenzen Sie jedes Teil Ihres Programms auf den kleinsten Berechtigungssatz, der für eine ordnungsgemäße Ausführung erforderlich ist. Die Präsentation Writing Secure Web Apps and Chrome Extensions von Google I/O 2012 enthält einige gute Beispiele für diese Techniken in der Praxis und ist 56 Minuten Ihrer Zeit wert.