Was macht Inline Javascript so gefährlich? Tipps zur Vermeidung

HTML-Code strukturiert den Text, die Bilder und Links eines Dokuments, für Style oder die Dynamik der Website ist HTML nicht zuständig. Um das Design sollte sich eine CSS-Datei kümmern, um das Verhalten eine JavaScript-Datei. Arbeiten Web Developer mit Inline Javascript wird es gefährlich, zudem werden wichtige Dinge wie zum Beispiel Caching dadurch gestört. Lernen Sie jetzt die Gründe kennen!

Was ist Inline Javascript?

Wird JavaScript direkt in eine HTML-Seite geschrieben, handelt es sich um Inline JavaScript:

test.html

Stattdessen kann das HTML-Dokument eine Referenz zu einer externen JavaScript-Datei beinhalten:

meinScript.js

alert('Ich bin externes JavaScript.');

test.html

Wichtig: Wenn in einem Tag sowohl „src“ als auch Inline Java steht, wird nur das externe Scripts ausgeführt.

Das Sicherheitsrisiko

Das Einfügen von schädlichem Inline JavaScript ist eine typische Angriffsmethode. Wenn Sie von Anwendern erzeugten Inhalten eine Verbindung zum DOM erlauben, zum Beispiel zur Beeinflussung der Darstellung, ist Ihre Website bei solch einem Angriffsszenario verwundbar. Kann ein Anwender folgenden Text einfügen?

dies ist ein <strong>formatierter</strong> Text

Wird dieser Text mit HTML-Tag als HTML in die Website eingefügt, kann ein Angreifer leicht schädlichen Code einschleusen und ein <script>-Tag integrieren:

dies ist ein <strong>formatierter</strong> Text mit einem Skript. Beim Laden erscheint die Info <script>alert('Die Website wurde gehackt');</script>

Es gibt viele Möglichkeiten, das <script>-Tag im HTML zu verstecken und darin beliebigen Code auszuführen. Auf diese Weise kann ein Cyberkrimineller zum Beispiel sensible Daten sammeln und an einen beliebigen Empfänger senden.

Die sichere Lösung: Inline JavaScript verbieten

Sie können sämtlichen JavaScript Code innerhalb des <script>-Tags verbieten, nur die Referenz auf eine externe Datei ist dann möglich: <script scr=“…“></script>.

Dafür setzen Sie im Browser die Content-Security-Policy (CSP) per meta-Attribut oder header. Ein sehr gutes Beispiel für einen sicheren CSP-Header finden Sie beispielsweise auf der Website von github. Führen Sie in der Kommandozeile den Befehl: curl https://github.com aus, es folgt:

Content-Security-Policy:

default-src 'none';
base-uri 'self';
block-all-mixed-content;
connect-src 'self' uploads.github.com status.github.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com wss://live.github.com;
font-src assets-cdn.github.com;
form-action 'self' github.com gist.github.com;
frame-ancestors 'none';
frame-src render.githubusercontent.com;
img-src 'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com;
manifest-src 'self';
  media-src 'none';
  script-src assets-cdn.github.com;
style-src 'unsafe-inline' assets-cdn.github.com

Wichtig ist hierbei vor allem die Eingrenzung der möglichen JavaScript-Quelle. Inline JavaScript wird somit nicht funktionieren und die Website ist besser vor Cross-Site-Scripting-Attacken geschützt.

Probieren Sie die Schutzmaßnahme aus: Öffnen Sie github.com im Browser, dann die Developer Tools und Console. Dort führen Sie folgenden Code aus:

var test = document.createElement('script');
test.innerText = 'alert("Dies ist Inline JavaScript");'
document.body.appendChild(test);

Die Antwort sollte aussehen, wie in der folgenden Abbildung dargestellt.

Das Test-Skript wurde vom Browser abgewiesen. Sie können den Test auf Ihrer Website wiederholen. Wenn die Alert-Box angezeigt wird und Seitenbesucher den Inhalt zum Beispiel per Kommentarfunktion verändern können, könnte von außen hinzugefügter Code direkt mit dem DOM verbunden werden. Mehr Funktionen zur Kontrolle der verwendeten Ressourcen bieten die Content Security Policy Level 2 und Level 3. Eine gute Übersicht finden Sie zum Beispiel bei Mozilla. So kann der Web Developer unter anderem für ein spezielles Inline JavaScript eine Ausnahme hinzufügen.

Weitere Gründe gegen die Verwendung von Inline JavaScript

Neben den Sicherheitsrisiken gibt es weitere Gründe, die gegen die Verwendung von Inline Javascript sprechen.

# 1: Pagespeed – Inline Script kann nicht verkleinert werden

Die Ladegeschwindigkeit zählt zu den wichtigsten Kriterien einer Website. Dauert der Ladevorgang länger als drei Sekunden, springen rund 40 Prozent der Besucher wieder ab. Das Minimieren von Code (Umwandlung in eine kürzere Version durch Reduzierung der Zeichen) verkleinert die zu ladende Datenmenge und beschleunigt den Ladevorgang. Inline Javascript kann jedoch nicht verkleinert werden.

# 2: Pagespeed – Caching funktioniert nicht mit Inline Javascript

Beim ersten Laden einer Website landen CSS- und JS-Dateien im Cache des Clients und müssen beim erneuten Seitenaufruf nicht neu geladen werden. Die Folge ist ein signifikanter Geschwindigkeitsgewinn bei Folgebesuchen. Das Caching von Inline Javascript ist hingegen nicht möglich und Sie verschwenden so die Möglichkeit kurzer Ladezeiten durch effektives Caching.

Hinweis: Das Caching erfordert allerdings eine weitere HTTP-Anfrage, was Web Developer möglichst vermeiden sollten. Wenn das Inline Javascript so klein ist, dass die zusätzliche Größe im Vergleich zu den Kosten einer HTTP-Anfrage vernachlässigbar ist, sollte das es gegebenenfalls beibehalten werden.

Die Frage sollte also sein: Ist eine weitere HTTP-Anfrage zum Cachen der Ressource lohnenswert oder sollte die Extra-Anfrage besser vermieden werden.

#3 – Inline Javascript macht debuggen schwieriger

Ein Fehler ist im Inline Javascript-Code schwieriger zu finden, da die beim Debuggen angezeigte Zeilennummer für den Fehler keine Bedeutung hat und sich die Ursache so schwieriger finden lässt. Zudem ist das Testen von Inline Javascript nicht unabhängig von der Seite möglich, hingegen können Web Developer externe JavcaScript-Dateien auch mit automatisierten Tests prüfen.

#4 – Sauberer und lesbarer Code: Trennung von HTML (View) und JavaScript (Controller)

Die Trennung der Darstellung und Anwendungslogik ist allgemein als „best practise“ empfohlen und gilt ebenso für HTML und JavaScript. Der Code wird dadurch sauberer, ist einfacher zu verstehen und prägnanter. Einige Web Developer sehen jedoch Nachteile in der kompletten Trennung, da sich beispielsweise für den Designer schwieriger herausfinden lässt, welche Elemente aktiv sind.

Fazit

Wenn Sie also Inline JavaScript aus guten Gründen verwenden möchten, dann möglichst nur im Rahmen entsprechend definierter Ausnahmen mithilfe von CSP Level 2 und dem Whitelisting durch SHA.

Über
Letzte Artikel

Benjamin Schmitz

Benjamin Schmitz ist selbstständiger Systemadministrator und passionierter Webdesigner. Im Host Europe Blog schreibt er über Webanwendungen und gibt Tipps für Einsteiger und Fortgeschrittene.

Letzte Artikel von Benjamin Schmitz (Alle anzeigen)