JavaScript-Sicherheit

Wie nahezu jede Programmiersprache ist auch JavaScript mit potenziellen Sicherheitsrisiken verbunden. Die Ausnutzung von JavaScript-Schwachstellen kann dazu führen, dass Daten manipuliert, Sitzungen umgeleitet sowie Daten verändert und gestohlen werden – und vieles mehr. JavaScript wird zwar meist als clientseitige Anwendung betrachtet, doch JavaScript-Sicherheitsprobleme können auch serverseitige Umgebungen beeinträchtigen.

Der beste Schutz vor häufigen JavaScript-Schwachstellen besteht darin, sie zu kennen und geeignete Maßnahmen zu ergreifen, um das Risiko zu verringern.

In diesem Artikel sehen wir uns die häufigsten JavaScript-Schwachstellen an und erläutern, wie sie sich durch gängige moderne Sicherheitsansätze in Kombination mit Testtools verhindern lassen (z. B. Audit- und Codeanalyse-Tools, JavaScript-Schwachstellen-Scanner usw.).

Was ist JavaScript-Sicherheit?

JavaScript-Sicherheit umfasst die Untersuchung, Prävention, den Schutz vor und die Behebung von Sicherheitsproblemen in Anwendungen, die JavaScript verwenden.

JavaScript ist eine grundlegende Technologie für die Entwicklung von Webanwendungen und wird auch häufig für serverseitige, Desktop- und sogar mobile Anwendungen genutzt. Seine weite Verbreitung macht JavaScript jedoch auch zu einem bevorzugten Ziel für Hacker, die es über verschiedene Angriffsvektoren ins Visier nehmen. Da JavaScript hauptsächlich im Frontend zum Einsatz kommt, ist es sinnvoll, zunächst die Sicherheitsprobleme von JavaScript in Browsern in den Blick zu nehmen.

Auch Softwareanbieter haben diese JavaScript-Sicherheitsprobleme erkannt und mit JavaScript-Sicherheitsscannern sowie verschiedenen JavaScript-Sicherheitstest-Tools reagiert. Sie machen Anwendungen sicherer und reduzieren JavaScript-Sicherheitsrisiken erheblich. Testen Sie unseren JavaScript-Code-Checker, um Schwachstellen in Ihrem Code zu finden.

Was sind die häufigsten JavaScript-Schwachstellen?

Zu den häufigsten JavaScript-Angriffsvektoren zählen das Ausführen schädlicher Skripte, der Diebstahl bereits etablierter Sitzungsdaten oder von Daten aus dem localStorage des Browsers, das Verleiten von Nutzern zu unbeabsichtigten Aktionen und das Ausnutzen von Schwachstellen im Quellcode von Webanwendungen.

Diese Liste ist natürlich keineswegs vollständig, sondern konzentriert sich vor allem auf den Frontend-Bereich von Webanwendungen.

8 JavaScript-Sicherheitsschwachstellen

8 JavaScript-Sicherheitslücken

1. Schwachstellen im Quellcode

Schwachstellen im Quellcode treten häufig zusammen mit anderen – mitunter mehreren – JavaScript-Sicherheitslücken auf. Leider lassen sich solche Schwachstellen in diesen Fällen nicht durch einfache JavaScript-Verschleierung verhindern oder verbergen. Da JavaScript interpretiert und nicht kompiliert wird, ist es praktisch unmöglich, den Anwendungscode mit dieser Methode vor der Untersuchung durch potenzielle Hacker zu schützen. Verschleierung ist dennoch eine sinnvolle Maßnahme, da sie die Reverse-Engineering-Versuche von Hackern erschwert.

Eine weitere Ursache für Sicherheitslücken im Quellcode ist die weitverbreitete Verwendung öffentlicher Pakete und Bibliotheken. NPM, ein wichtiger Akteur im JavaScript-Ökosystem, bietet mehr als eine Million Pakete in seiner Registry. Die große Auswahl ist zwar ein klarer Vorteil, bedeutet aber auch, dass in den Paketen, die in Webanwendungsprojekten installiert werden, zahlreiche versteckte Schwachstellen stecken können.

Darüber hinaus installieren Entwickler häufig Pakete selbst für einfachste Aufgaben und erweitern so die Abhängigkeiten ihres Projekts. Dies kann natürlich zu Sicherheitsproblemen und weiteren weitreichenden Folgen führen.

Die Überwachung und Behebung aller potenziellen Schwachstellen in Anwendungsabhängigkeiten kann zeitaufwendig und arbeitsintensiv sein. Audit-Tools können dabei helfen, den Prozess zu automatisieren und zu beschleunigen.

Ein mehrgleisiger Ansatz zur Vermeidung von JavaScript-Sicherheitsproblemen im Quellcode sollte Folgendes umfassen:

• Das Bewusstsein der Entwickler für Best Practices stärken

• Anwendungscode angemessen überprüfen, um potenzielle Schwachstellen zu erkennen

• Unit-Tests schreiben, um nicht nur sicherzustellen, dass sich der Code erwartungsgemäß verhält, sondern auch, dass er sicher ausgeführt wird

• Tools einsetzen, die Anwendungen dynamisch scannen und JavaScript-Sicherheitsprobleme in Paketen und Bibliotheken von Drittanbietern erkennen

2. Unbeabsichtigte Skriptausführung

Bei den meisten Angriffen durch unbeabsichtigte Skriptausführung handelt es sich um Cross-Site-Scripting (XSS). Ein besonderes Risiko im Zusammenhang mit JavaScript ergibt sich daraus, wie es mit dem Document Object Model (DOM) einer Webseite interagiert: Skripte können dadurch eingebettet und auf Client-Computern im Web ausgeführt werden. Es gibt zwar verschiedene Arten von XSS-Angriffen, doch alle haben gemeinsam, dass sie nicht vertrauenswürdige Skripte im Browser des Nutzers anzeigen und ausführen.

Ein einfaches Beispiel für einen XSS-Angriff findet sich häufig auf Foren-Websites, auf denen Nutzer die Beiträge anderer sehen können. Wenn HTML oder JavaScript in einem Beitrag nicht ordnungsgemäß kodiert wird, können skrupellose Nutzer ein Skript im Forum veröffentlichen.

Ein solches Skript würde jeden Endnutzer zum Opfer machen, der den Angriff unwissentlich ermöglicht, indem er die Anwendung einfach ausführt. Der schädliche Code scheint dabei Teil der Webseite zu sein.

Um XSS-Angriffe zu verhindern, sollten Entwickler beim Umgang mit Nutzereingaben und Serverausgaben eine Bereinigung durchführen – eine Kombination aus Escaping, Filterung und Validierung von Zeichenfolgendaten.

Nutzereingaben escapen und kodieren

XSS-Angriffe beruhen darauf, Daten einzuschleusen, die bestimmte Sonderzeichen enthalten, die im HTML-, JavaScript- oder CSS-Code einer Webseite verwendet werden. Beim Rendern der Webseite interpretiert der Browser diese Zeichen als Teil des Codes und nicht als anzuzeigenden Wert. So kann ein Angreifer aus einem Textfeld ausbrechen und zusätzlichen browserseitigen Code einschleusen, der dann ausgeführt wird.

Um dies zu verhindern, sollten Sonderzeichen immer dann durch Escape-Codes ersetzt werden, wenn vom Browser bereitgestellte Daten in einer Antwort zurückgegeben werden – unabhängig davon, ob sie direkt reflektiert oder aus einer Datenbank abgerufen werden.

So können beispielsweise die Zeichen < und >, die HTML-Entitäten begrenzen, durch < und > ersetzt werden. Dadurch wird dem Browser mitgeteilt, diese Zeichen anzuzeigen, statt sie als HTML-Entitäten zu interpretieren. Werden vom Browser bereitgestellte Daten in einem JavaScript-Kontext zurückgegeben, sollten nicht alphanumerische Zeichen mit xNN maskiert werden, wobei NN dem hexadezimalen ASCII-Wert des Zeichens entspricht.

Eingaben filtern

In manchen Fällen ist es möglicherweise besser, gefährliche Zeichen einfach aus den als Eingabe erhaltenen Daten zu entfernen. Dies bietet einen gewissen Schutz, sollte aber nicht als alleiniger Schutz vor Datenmanipulation dienen. Angreifer können verschiedene Techniken einsetzen, um solche Filter zu umgehen.

Eingaben validieren

Vom Browser bereitgestellte Eingaben sollten nach Möglichkeit validiert werden, um sicherzustellen, dass sie nur erwartete Zeichen enthalten. Telefonnummernfelder sollten beispielsweise nur Zahlen und gegebenenfalls Bindestriche oder Klammern zulassen. Eingaben mit Zeichen außerhalb des erwarteten Zeichensatzes sollten sofort abgelehnt werden. Richten Sie die Filter so ein, dass sie zulässige Zeichen erkennen und alle anderen zurückweisen.

Sich nicht allein auf die clientseitige Validierung verlassen

Die oben beschriebenen Methoden eignen sich zwar gut für Browser, doch Hacker können spezielle Tools verwenden, um Daten direkt an den Server zu senden und so die clientseitige Validierung zu umgehen. Dadurch können potenziell schädliche oder ungeprüfte Daten auf den Server gelangen. Ohne zusätzliche serverseitige Validierung könnten gespeicherte Daten beschädigt oder durch fehlerhafte Daten ersetzt werden.

Als Best Practice zur Vermeidung solcher Szenarien empfiehlt es sich, sowohl eine client- als auch eine serverseitige Validierung zu implementieren. Das verringert das Risiko fehlerhafter Daten und bietet gleichzeitig Validierungsfunktionen auf dem Client, die die Ergebnisse für Endnutzer verbessern.

Eine ausschließlich serverseitige Validierung kann für Nutzer lästig sein, da sie Onlineformulare möglicherweise mehrfach ausfüllen müssen, bevor alle Prüfungen bestanden sind. Die JavaScript-Validierung sollte Nutzer sofort auf Probleme mit ihren Eingaben hinweisen, während die serverseitige Validierung sicherstellt, dass nur erwartete Daten in die Anwendung gelangen.

Sitzungsdaten stehlen

Clientseitige Skripte im Browser können sehr leistungsfähig sein, da sie Zugriff auf alle Inhalte haben, die eine Webanwendung an den Browser zurückgibt. Dazu zählen Cookies, die sensible Daten wie Sitzungs-IDs von Nutzern enthalten können. Ein häufiger XSS-Angriff besteht darin, die Sitzungstoken eines Nutzers an den Angreifer zu senden, damit dieser die Sitzung übernehmen kann.

Um dies zu verhindern, unterstützen die meisten Browser inzwischen das Attribut Http-Only für Cookies. Wenn der Server ein Cookie im Browser setzt, sorgt das Attribut Http-Only dafür, dass der Browser den Zugriff auf das Cookie über das DOM unterbindet. Dadurch wird verhindert, dass clientseitige skriptbasierte Angriffe auf die sensiblen Daten in diesen Cookies zugreifen.

Daten im lokalen Speicher und im Sitzungsspeicher des Browsers lassen sich auf dieselbe Weise stehlen, können jedoch nicht durch den DOM-Zugriffsschutz gesichert werden. Daher sollten Sie sensible Informationen wie Token möglichst nicht im Browser-Speicher ablegen, es sei denn, bestimmte Funktionen der Webanwendungsarchitektur machen dies erforderlich.

Nutzer zu unbeabsichtigten Aktionen verleiten

Bei Cross-Site-Request-Forgery-Angriffen (CSRF) wird versucht, einen Browser dazu zu bringen, schädliche Anfragen an Websites auszuführen, bei denen der Nutzer bereits angemeldet ist – selbst wenn die Website zu diesem Zeitpunkt nicht geöffnet ist. Sind Sitzungen auf der Zielwebsite cookie-basiert, können Anfragen an diese Website automatisch mit Autorisierungs-Cookies versehen werden.

Hacker können auch eigene Webseiten erstellen, die beim Öffnen durch den Nutzer im Hintergrund schädliche Anfragen an andere Websites senden. Außerdem können sie in sozialen Medien, Foren und auf anderen Plattformen schädliche Links oder Inhalte veröffentlichen, die Browser dazu bringen, unbemerkt unter Verwendung der Sitzungscookies des Nutzers andere Websites aufzurufen.

Eine gängige Methode, diese Schwachstelle zu vermeiden, ist die Tokenisierung der Client-Server-Kommunikation. Dabei wird ein zusätzliches Token eingeführt, das nicht in Cookies gespeichert ist. Für jedes Formular auf der Website sollten bei Sitzungsbeginn Token generiert und zusammen mit jeder Anfrage übermittelt werden, solange der Nutzer auf der Website aktiv ist.

Wie lassen sich JavaScript-Sicherheitsprobleme beheben?

Anwendungen und Server lassen sich durch die Anwendung von Best Practices für die JavaScript-Sicherheit und den Einsatz leistungsfähiger Scan-Tools vor JavaScript-Schwachstellen schützen.

In der Webentwicklung müssen Softwareentwickler neue JavaScript-Sicherheitsrisiken ständig im Blick behalten. Funktionstests für Anwendungen sind wichtig, doch auch der regelmäßige Einsatz von JavaScript-Sicherheitstest-Tools ist entscheidend, um Schwachstellen zu verhindern. Schließlich lässt sich die Widerstandsfähigkeit Ihrer Anwendungen durch einige einfache, gängige Best Practices deutlich erhöhen.

Die folgenden Best Practices für die JavaScript-Sicherheit können dieses Risiko reduzieren.

• Vermeiden Sie**eval()**: Verwenden Sie diesen Befehl nicht im Code, da er ein übergebenes Argument ausführt, sofern es sich um einen JavaScript-Ausdruck handelt. Gelingt es einem Hacker, den Eingabewert zu manipulieren, kann er dadurch beliebige Skripte ausführen. Setzen Sie stattdessen auf sicherere Alternativen.

• Verschlüsseln: Verwenden Sie HTTPS/SSL, um Daten zu verschlüsseln, die zwischen Client und Server ausgetauscht werden.

• Sichere Cookies festlegen: Setzen Sie Ihre Cookies auf „secure“, um die Verwendung Ihrer Anwendungscookies auf sichere Webseiten zu beschränken und so die Nutzung von SSL/HTTPS sicherzustellen.

• API-Zugriffsschlüssel festlegen: Weisen Sie jedem Endnutzer individuelle Token zu. Stimmen diese Token nicht überein, kann der Zugriff verweigert oder widerrufen werden.

• Verwenden Sie sichere Methoden zur DOM-Manipulation:Methoden wie innerHTML sind leistungsstark und potenziell gefährlich, da sie die an sie übergebenen Werte weder einschränken noch maskieren oder kodieren. Eine Methode wie innerText maskiert potenziell schädliche Inhalte hingegen automatisch. Das ist besonders hilfreich, um DOM-basierte XSS-Angriffe zu verhindern.

Das Erkennen potenzieller JavaScript-Sicherheitsprobleme ist ein wichtiger erster Schritt, um Schwachstellen bei der Anwendungsentwicklung zu verhindern. Testen Sie Ihren Code jetzt mit einem Open-Source-Schwachstellen-Scanner.