Sicherheitsleitfaden bei Erweiterungen

Dieses Dokument ist dazu gedacht, für Entwickler als Leitfaden zu bestmöglichen Vorgensweisen bei der Absicherung ihrer Erweiterung zu dienen. Dein Ziel ist es, deine Nutzer zu schützen. Einige Einträge sind strikte Richtlinien, was Bedeutet, dass wenn Du diesen nicht folgst, dein Add-On im Gegenzug auf Mozilla Add-Ons nicht akzeptiert wird. Andere Einträge sind Empfehlungen. Der Unterschied wird klar gekennzeichnet.

Es ist aus der Perspektive einer Firefox Erweiterung geschrieben, aber die meisten Einträge beziehen sich auf Erweiterungen für andere Mozilla-basierte Applikationen wie Thunderbird oder SeaMonkey.

Handhabung von Webinhalten

Im Allgemeinen ist der beste Weg sicherzustellen, dass der Browser beim Laden von Inhalten nicht kompromittiert wird, dafür zu sorgen, dass diese keine entsprechenden Rechte haben. Eine detailliertere Erklärung dieses Prozesses findet sich unter Webinhalte ohne Sicherheitsprobleme in einer Erweiterung anzeigen.

Die Rechte, die ein Dokument bekommt, hängen auch davon ab, wo es herkommt.  Zum Beispiel: Wenn Du eine chrome URL lädst, bedeutet es, dass der Inhalt in Firefox registriert wurde und vollen Zugriff hat. Inhalt von einer Domain (wie https://example.com) kann nur auf die gleiche Domain zugreifen. Über das File Protocol geladene Dateien können auf solche zugreifen, die auf der Festplatte und anderen lokalen Datenträgern liegen. Es gibt Wege, die content/chrome Sicherheitsbarriere zu umgehen, falls Du zum Beispiel möchtest, dass eine Webseite eine Notifikation an ein Add-On sendet (oder umgekehrt). Ein Weg das zu tun ist es, eigene DOM Events zu nutzen; siehe Interaktionen zwischen priviligierten und nicht-priviligierten Seiten.

Unabhängig davon, wo das Dokument herkommt, kannst du weiter Beschränken, was es kann, indem du Eigenschaften zum Dokumentenhalter - auch bekannt als docshell - zuweist.

frame.docShell.allowImages = false;
frame.docShell.allowJavascript = false;
frame.docShell.allowPlugins = false;

Es gibt mehr Beispiele in dem oben gelisteten Dokument. Unter gewissen Umständen möchte man Code in der Erweiterung ausführen, allerdings solltest du ihm eingeschränkte Rechte geben. Einer der besten Wege das zu tun ist Components.utils.evalInSandbox() zu nutzen. Beachte, dass Objekte, die an die Sandbox weitergegeben werden, eingeschränkt sind, aber solche, die wieder herauskommen es nicht sind. Nimm Bezug auf den Artikel, um herauszufinden, wie du solche Tücken vermeidest. Für weitere Informationen, siehe den Abschnitt evalInSandbox.

Die Sidebar: Ein Anwendungsfall

Die Sidebar in Firefox ist dafür gestaltet, sowohl chrome (priviligierte) Inhalte, als auch Web (nichtpriviligierte) Inhalte zu beinhalten - letzteres in Form von Webseiten. Diese Webseiten können von einem Server oder von lokalen HTML Dateien, die mit der Erweiterung gekommen sind, stammen. Für Seiten, die vom Server kommen, musst du Schritte vornehmen, um zu sicherzustellen, dass die Inhalte nicht in den Browser rückrufen und Schadcode ausführen. Hauptsächlich wird dies bewerkstelligt, indem man ein Iframe- oder Browserelement in der Sidebar erstellt und dort die Inhalte lädt. Gebe dem Inhalt ein type="content" Attribut, welches den Code im Wesentlichen sandboxed und alle Rückrufe direkt nach chrome blockiert.

eval() in einer Erweiterung nutzen

Das Nutzen der eingebauten JavaScript Funktion eval ist im Kontext von Erweiterungen verpönt. Während es einige Fälle gibt, in denen die Nutzung legitim ist, gibt es meist sicherere Alternativen. Dieser Blogeintrag bietet einige exzellente Beispiele, warum man eval() nicht nutzen sollte.

Gesandboxte HTTP Verbindungen

Der Hauptzweck von gesandboxten HTTP Verbindungen ist es, mit einem Webdienst zu kommunizieren, ohne mit im Browser zu der Website/dem Service gesetzten Cookies zu interferieren. Wenn Du zum Beispiel Fotos oder andere Daten von einer photo sharing Seite lädst, kannst du die Verbindungen sandboxen, sodass normales Surfen des Nutzers auf der Webseite nicht beeinflusst wird. Für einen echten Anwendungsfall, siehe diesen Blogeintrag.

Umgang mit Logins und Passwörtern

Es gibt viele Möglichkeiten, Daten in Firefox zu speichern, aber für Logins und Passwörter, solltest Du den Login Manager nutzen. Das ist der gleiche Speicher, welcher Logins von Webseiten beinhaltet und Passwörter können nur abgerufen werden, indem die Kombination von Seite/Username dem Author bekannt sind. Die Gepflogenheit für Erweiterungen ist es, eine chrome URL als den Seitenidentifikator zu nutzen, um Konflikte mit Logins für Seiten zu verhindern. Es könnte der Fall sein, dass deine Erweiterung ein anderes Werkzeug oder andere Werkzeuge für Dienste auf deiner Seite anbietet.

Diese Herangehensweise ist vorzuziehen, da es den Nutzern eine gewohnte Oberfläche für die Interaktion mit Logins über den Firefox Passwort Manager bietet. Wenn Nutzer Logins über die "Neueste Chronik löschen" Option säubern, wird das die Daten deiner Erweiterung miteinbeziehen.

APIs und Umgang mit anderen Daten

Web Inhalte sind mehr als nur Seiten, und mehr und mehr Add-Ons interagieren über das Application Programming Interfae (API) mit Webdiensten.

• API Provider sollten das HTTPS Protokoll nutzen, welches besseren Schutz für Daten über das Netzwerk bietet.
• JSON ist ein beliebtes Datenformat für Antwortenformate von Webdienste geworden. Gehe sicher, Natives JSON nutzen zu lesen, um den richten Umgang damit herauszufinden.
• APIs können nicht mit selbst-signierten Zertifikaten genutzt werden.

Remote Javascript und -Inhalte

Es gibt eine Zahl von Arten, wie Remotescripte in Erweiterungen genutzt werden können. Sie können in Inhalten eingebettet oder in Intervallen heruntergeladen werden.

Nicht-chrome URLs in chrome XUL oder HTML, so wie im folgenden Beispiel sind nicht erlaubt:

<script type="text/javascript" src="https://mysite.greatsite.com/js/wow-content.js" />

Im Allgemeinen sind Skripte von Remotequellen, die im Kontext von chrome laufen, nicht akzeptabel, da die Quelle der Skripte nie zu 100% garantiert werden kann und sie für Man-In-The-Middle Attacken empfindlich sind. Die einzig legitime Umgebung für Remoteskripte ist es, in einer Sandbox zu laufen. Für mehr Informationen, siehe die Sektion evalInSandbox().

evalInSandbox

Das evalInSandbox Dokument erklärt die Funktion ziemlich gut, also wird es hier keine Wiederholung geben. Die Nützlichkeit und Kraft der Funktionsweise wird von der beliebten Erweiterung Greasemonkey veranschaulich, welche unter der Prämisse arbeitet, dass Skripte heruntergeladen und gespeichert werden, um im Kontext von Webinhalten via der Sandbox injiziert zu werden. Viele Erweiterungen nutzen den Greasemonkey compiler, um die Funktion aus Bequemlichkeit in ihrer Erweiterung zu bündeln. Wenn Du dich entscheidest das zu tun, sei vorsichtig beim Editieren von gebündelten Dateien, insofern als, gut durchdachte Sicherheitsarchitekturen nicht zu verletzen.

Drittanbieter JavaScript

Im Kontext von Webseiten, ist das Nutzen von JavaScripten, welche von anderen geschrieben wurden sehr geläufig. Auch in Add-Ons ist es nicht unbekannt und kann einen nützlichen Weg darstellen, um Codewiederholungen zu vermeiden und die Entwicklung zu beschleunigen. Dieser Artikel ist über Webseiten, aber liefert einige Einsichten in generelle Risiken. Wenn Du andere Skripte einbettest, gibt es eine Reihe von Dingen, die du tun kannst, um ihre Integrität und Sicherheit für Nutzer zu gewährleisten. Als erstes, es immer von einer glaubwürdigen Quelle zu beziehen. Eine andere Sache, die du tun solltest, ist das Namespacen, nur für den Fall, dass andere Add-Ons es inkludieren. Zum Beispiel, wenn Du jQuery nutzt, gibt es da jQuery.noConflict().

Fazit

Sicherheit kann nicht als selbstverständlich angesehen werden und jede Veröffentlichung deines Add-Ons, sollte es eine neue Sicherheitsprüfung geben. Ein guter Ort, um mit Mozillas Sicherheitsmeldungen und Sicherheitsdiskussionen mitzuhalten, ist im  Mozilla Security Blog.