Node.js-Sicherheit: Erkenntnisse der Node.js Security Working Group bei der Triage von Sicherheitslücken

In einem früheren Blogbeitrag habe ich über eine Sicherheitsmeldung zum Fastify-Node.js-Framework an die Node.js Security Working Group auf HackerOne berichtet. Dabei ging es um eine serverseitige JavaScript-Code-Injection-Sicherheitslücke. Die abschließende Bewertung ergab, dass der Bericht weder für das Fastify-Node.js-Webframework noch für dessen JSON-Schema-Validierungskomponente fast-json-stringify sicherheitsrelevant war.

Warum wurde ein Sicherheitsbericht nicht als solcher eingestuft?

Um diese Frage zu beantworten, werfen wir einen kurzen Blick auf die Ergebnisse des Berichts und beleuchten einige Herausforderungen, die sich für das Incident-Response-Team der Node.js Security Working Group ergaben.

Der Sicherheitsbericht beschrieb einen Code-Injection-Angriff, bei dem ein Angreifer eine JSON-Datei manipulieren kann, die als Schema für die Request-Validierung dient. Ein Proof of Concept bestätigte die Sicherheitslücke, indem eine Reverse Shell gestartet wurde.

Wie der Fastify-Maintainer frühzeitig anmerkte, handelte es sich dabei jedoch nicht um eine Sicherheitslücke in Fastify selbst: Diese Sicherheitslücke tritt weder dynamisch noch aufgrund eines Sicherheitsfehlers im Framework-Code auf. Sie entsteht nur, wenn nicht vertrauenswürdiger Code als JSON-Validierungsschema verwendet wird – das meist von den Entwicklern selbst geschrieben und nicht aus Benutzereingaben übernommen wird.

Dieser Sicherheitslückenbericht macht einige Herausforderungen deutlich, denen wir in der Node.js Security Working Group als Sicherheitsanalysten bei der Reaktion auf Sicherheitsvorfälle begegnen:

1. zu beurteilen, ob ein Bericht zutrifft und als Sicherheitslücke einzustufen ist

2. die Quelle einer Sicherheitslücke zu ermitteln

Grenzfälle bei der Node.js-Sicherheit

Beim schnellen Überfliegen des Berichts scheint die gemeldete Sicherheitslücke valide zu sein. Schließlich wurde ein Proof of Concept vorgelegt, und das Angriffsszenario ließ sich unter Einbeziehung der genannten Komponente reproduzieren.

Dennoch müssen wir den Angriffspfad und die Details der Sicherheitslücke genau prüfen und auch die vorgesehene Verwendung der betroffenen Komponente verstehen. Im Fall von Fastify verhindert die Bibliothek bewusst das dynamische Parsen des bereitgestellten JSON-Schemas, mit dem Requests validiert werden, um solche Code-Injection-Angriffe zur Laufzeit abzuwehren.

Entwickler können jedoch weiterhin ein JSON-Parsing-Schema mit bösartigem Code verwenden, wie im Proof of Concept gezeigt. Aber handelt es sich dabei wirklich um eine Sicherheitslücke?

Hier wird die Lage unklar. Das Fastify-Team hat die Sicherheitsanforderungen in der Projektdokumentation klar formuliert: Die Eingabe für die JSON-Schema-Konfiguration ist als vertrauenswürdige Quelle zu behandeln. Damit liegt die Verantwortung bei den Entwicklern und dem Team, das die Bibliothek einsetzt: Sie müssen sicherstellen, dass die Eingabe vertrauenswürdig ist.

Wo liegt die Node.js-Sicherheitslücke?

Eine weitere Herausforderung, die leicht übersehen wird, ist die Quelle einer Sicherheitslücke. In diesem Bericht geht es beispielsweise um zwei Komponenten: das Node.js-Webframework fastify und die JSON-Parsing-Bibliothek fast-json-stingify. Welche davon sollte im Rahmen der Triage als betroffene Komponente behandelt werden?

Einerseits nutzt fastify lediglich eine andere Komponente, um das JSON-Schema zu parsen. Andererseits verfolgt fast-json-stringify nicht den erklärten Anspruch, vor allen denkbaren Eingaben sicher zu sein, sondern überlässt diese Verantwortung den Nutzern.

Diese Herausforderung wird anhand eines früheren Sicherheitsberichts deutlich, den wir als Beispiel erhalten haben. Darin wurde eine Cross-Site-Scripting-Sicherheitslücke (XSS) in einer Anwendung entdeckt, die Excel-Tabellen als HTML ausgibt und dafür eine Drittanbieterkomponente zum Parsen der Tabellendaten verwendet. Die XSS-Lücke betrifft die Anwendung selbst, da sie die Ausgabedaten für die HTML-Seite nicht bereinigt. Sie hängt nicht mit der Drittanbieterkomponente zusammen, denn diese kann nicht im Voraus wissen, ob die Eingabedaten in einem HTML-Kontext oder beispielsweise in einer einfachen CSV-Datei verwendet werden. Im Hinblick auf den Umfang der Excel-Parsing-Bibliothek ist diese Art von Sicherheitslücke daher nicht relevant.

Zusammenfassung

Die Triage von Sicherheitslücken erfordert viel Kontext und Erfahrung. Der Austausch zwischen Sicherheitsforschern und den Maintainerinnen und Maintainer der betroffenen Komponente ist entscheidend, um den Kontext zu verstehen, in dem sich die Sicherheitslücke ausnutzen lässt.

Eine weitere Herausforderung ist die korrekte Bewertung von Sicherheitslücken, auch bekannt als Common Vulnerability Scoring System (CVSS). Wenn Sie mehr zu diesem Thema erfahren und Sicherheitslücken in Node.js besser triagieren möchten, lesen Sie meinen früheren Beitrag über die Herausforderungen von CVSS und Tipps für eine korrekte Bewertung.