Talk: Are these my assets?

Lightning Talk bei Web and Wine

Hinter dem Begriff Subressource Integrity (SRI) versteckt sich ein noch junges Konzept, um nachgeladene Assets auf Vollständigkeit und Unversehrtheit zu überprüfen. Bei Web and Wine, dem regelmäßigen Treffen der Augsburger Webentwickercommunity, stellte Michael Fürmann SRI im Rahmen eines Lightning Talks vor. Die Folien des Vortrags sind auf dem Repositoryserver der Hochschule Augsburg zu finden.

Empfehlung des W3C

Eine vom World Wide Web Consortium veröffentliche Empfehlung aus dem Juni 2016 beschreibt ausführlich den Einsatz von Prüfsummen zur Überprüfung von Assets. Dieser ist nach Angabe im offiziellen Dokument dazu gedacht, Assets auf Unversehrtheit zu prüfen. Dazu wird im HTML-Code der Seite ein weiterer Parameter integrityzur Angabe der Prüfsumme genutzt. Als Prefix wird einer Prüfsumme der genutzte Hashingalgorithmus vorne angestellt. Eine Nennung mehrerer Prüfsummen mit unterschiedlichen Algorithmen ist möglich. Diese müssen nur durch Leerzeichen voneinander getrennt werden.

<script
        src="script.js"
        crossorigin="anonymous"
        integrity="sha384-r3CXcejLa9Rhj9dcft/KmEbwYzCdCtYEwsohRGLdIOOipftyZh8Um2R8bRGv+PMR sha512-sG+Ez27OjzA8ygZk0s7+BAG/5c/RgAXbLZjcDRHwe+PJiGJ/KCoh4S7bO+SS6jcKxjmtPcKM9n+5OtR0LE3MCA=="
    ></script>

Mit crossorigin="anonymous" muss ferner die Überprüfung der Herkunft eines Assets deaktiviert werden. Durch die Validierung des Inhalts der Datei über die Prüfsumme ist die Herkunft des Assets nicht mehr von Bedeutung.

Reaktion des Browsers

Zum Zeitpukt des Vortrags wird SRI von etwa 60% der Browser, darunter bereits fast alle wichtigen Vertreter, unterstützt. Es kann dennoch bereits eingesetzt werden. Ein Browser, der das neue Attribut integrity nicht kennt, wird es im Zweifel ignorieren. Hier gibt es zwar keinen Zugewinn an Sicherheit, es schadet aber auch nicht der normalen Funktionsweise der Seite.

Browser mit Unterstützung für SRI prüfen jedes Asset mit integrity Angabe auf übereinstimmende Prüfsummen. Sind, wie im obigen Codebeispiel, mehrere Prüfsummen angegeben, so genügt die Übereinstimmung mit einer der angegebenen Summen.
Findet der Browser keine Übereinstimmung, so wird ein Fehler auf der Entwicklerkonsole angezeigt und das Asset vollständig verworfen. Sollen diese Fehler in einer Produktivanwendung erfasst werden, kann ein Reportingtool wie Sentry eingesetzt werden.

Erzeugung der Prüfsumme

Zur Erzeugung der Prüfsumme existieren bereits zahlreiche Online-Tools. Allerdings stellt sich die Frage, ob diese Anwendungen vertrauenswürdig genug für diesen Zweck sind. Auf diese Weise wird das Erstellen der sicherheitssensitiven Summe an einen unbekannten Anbieter ausgelagert. Besser ist es, die Buchstabenkolonnen auf dem eigenen Rechner zu erstellen.

Unter Linux etwa kann dies mit folgendem Kommando geschehen:

› cat script.js | openssl dgst -sha512 -binary | openssl enc -base64 -A
sG+Ez27OjzA8ygZk0s7+BAG/5c/RgAXbLZjcDRHwe+PJiGJ/KCoh4S7bO+SS6jcKxjmtPcKM9n+5OtR0LE3MCA==

Mit vorangestelltem sha512- für die Angabe des verwendeten Hashingalgorithmus ergibt dies den Wert für das integrity Attribut.

Für viele Tools und Frameworks, die sich um Generierung des HTML Codes und die Verwaltung der Asset-Pipeline kümmern (Webpack, Laravel, Rails, etc.) gibt es bereits Plugins, welche sich um die Erzeugung und Einbettung der Informationen für SRI kümmern. Damit reduziert sich der Arbeitsaufwand in das Installieren und Konfigurieren eines Plugins.

Nutzen

Da SRI bereits von den meisten wichtigen Browsern unterstützt wird, bringt der Einsatz einen wertvollen Sicherheitsgewinn mit vergleichsweise niedrigem Arbeitsaufwand. Allerdings bringt das Verwerfen von ungültigen Assets unvorhersehbare Reaktionen und Fehler in der nun nicht vollständig geladenen Anwendung. In vielen Szenarien ist es aber besser, die Applikation funktioniert gar nicht, als Gefahr zu Laufen, dass ein Angreifer die Anwendung auf dem Weg zum Browser des Nutzers manipuliert.

Auch SRI bringt keinen vollständigen Schutz gegen zielgerichtete Man-in-the-Middle Angriffe auf die Anwendung. Gerade bei Einsatz mehrerer Server für die Auslieferung von HTML-Seiten und Assets beziehungsweise bei Nutzung eines CDN erhöht es die Schwierigkeit eines Angriffs merklich.
Es ist im einfachsten Falle ein kleiner Zugewinn an Sichereit, welcher mit wenig Aufwand erreicht werden kann.