web-dev-qa-db-de.com

Wie kann ich sicherstellen, dass meine über ein CDN gelieferten JavaScript-Dateien nicht geändert werden?

Ich arbeite an einem Szenario, in dem einige JavaScript-Dateien auf einem CDN gehostet werden sollen. Ich möchte einen Mechanismus haben, mit dem ich beim Herunterladen dieser Dateien auf Benutzerseite sicherstellen kann, dass die Dateien nicht manipuliert wurden und tatsächlich von der angegebenen CDN stammen.

Ich verstehe, dass die Aufgabe sehr einfach ist, wenn ich SSL verwende, aber ich möchte trotzdem sicherstellen, dass die richtigen Dateien auch bei HTTP ohne SSL bereitgestellt werden.

Soweit ich suchen konnte, gibt es keinen Mechanismus wie die digitale Signatur für JavaScript-Dateien, der plattformübergreifend unterstützt wird. Vielleicht wird es nicht benötigt?

Verfügt der Browser über eine integrierte Methode, um den Autor der JavaScript-Dateien zu überprüfen? Kann ich irgendetwas tun, um dies auf sichere Weise zu tun?

87
baba26

Tatsächlich wird ein Feature wie dieses derzeit unter dem Namen Subresource Integrity entworfen . Untersuchen Sie das integrity Attribut des <script> tag. Obwohl es noch nicht vollständig übernommen wurde , erfüllt es genau diesen Zweck.

integrity

Enthält Inline-Metadaten, mit denen ein Benutzeragent überprüfen kann, ob eine abgerufene Ressource ohne unerwartete Manipulation bereitgestellt wurde. Siehe Subressourcenintegrität.

Quelle

Subresource Integrity (SRI) ist eine Sicherheitsfunktion, mit der Browser überprüfen können, ob von ihnen abgerufene Dateien (z. B. von einem CDN) ohne unerwartete Manipulation übermittelt werden. Hiermit können Sie einen kryptografischen Hash bereitstellen, mit dem eine abgerufene Datei übereinstimmen muss.

Quelle


Beispiel:

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

Beachten Sie jedoch, dass dies Sie nicht vor Man in the Middle-Angriffen schützt, wenn Sie Ihre Ressourcen übertragen über einfaches HTTP. In diesem Fall kann der Hash-Code vom Angreifer gefälscht werden, wodurch die Abwehr manipulierter Skriptdateien unbrauchbar wird.

Aus diesem Grund sollten Sie zusätzlich zu den oben beschriebenen Sicherheitsmaßnahmen immer sichere HTTPS-Verbindungen anstelle von einfachem HTTP verwenden.

139
Timo

Sie suchen nach Integrität der Subressourcen Prüfungen.

Hier ist zum Beispiel das jQuery-CDN-Snippet:

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>
35
Brian

Haftungsausschluss: Wie immer sollten Sie diese Mechanismen nur bei der Verwendung von https für sinnvoll halten, da sie über MitM mit http einfach deaktiviert werden können

Zusätzlich zu dem Mechanismus in den obigen Antworten können Sie auch die HTTP-Antwortheader der Inhaltssicherheitsrichtlinie auf der übergeordneten Seite verwenden.

http://www.html5rocks.com/de/tutorials/security/content-security-policy/

Inhaltssicherheitsrichtlinie: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

Hier sind einige Dinge zu beachten. Das sha * -Präfix gibt den Algorithmus an, mit dem der Hash generiert wird. Im obigen Beispiel wird sha256- verwendet. CSP unterstützt auch sha384- und sha512-. Berücksichtigen Sie beim Generieren des Hashs nicht die Tags. Auch Groß- und Kleinschreibung, einschließlich führender oder nachfolgender Leerzeichen, spielen eine Rolle.

Mit Chrome 40 oder höher können Sie DevTools öffnen und Ihre Seite neu laden. Die Registerkarte "Konsole" enthält Fehlermeldungen mit dem richtigen sha256-Hash für jedes Ihrer Inline-Skripte.

Dieser Mechanismus gibt es schon seit geraumer Zeit, daher ist die Browserunterstützung wahrscheinlich ziemlich gut.

Wenn Sie außerdem sicherstellen möchten, dass ältere nicht kompatible Browser nicht unsicher sind, können Sie oben auf der Seite ein synchrones Umleitungsskript einfügen, das von der Richtlinie nicht zugelassen wird.

6

Es gibt einen wichtigen Punkt darüber, was diese Art des Signierens kann und was nicht. Es kann den Benutzer vor hypothetischen Angriffen schützen, bei denen jemand Ihren Code ändert. Es kann nicht Ihrer Site versichern, dass Ihr Code der Code ist, der ausgeführt wird. Mit anderen Worten, Sie können immer noch nichts vertrauen, was vom Client auf Ihre Site gelangt.

3
ddyer

Wenn Ihr Gegnermodell es einem Angreifer erlaubt, JavaScript-Dateien so zu ändern, wie sie von einem CDN geliefert werden, dann erlaubt Ihr Gegnermodell einem Angreifer, die verweisende Quelle so zu ändern, wie sie geliefert wird, um jeden Verifizierungsversuch zu unterbinden und die Quelladresse in eine andere als zu ändern das CDN, und/oder den Verweis auf das JavaScript vollständig zu entfernen.

Und lassen Sie uns nicht die Dose mit Würmern öffnen, anhand derer Ihre Anwendung feststellen kann, ob der Resolver des Benutzers über HTTP-Anforderungen (oder einen anderen Mechanismus ohne überprüfte Vertrauenskette) in das CDN aufgelöst wird oder nicht.

/ etc/hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...
2
Eric Towers