Plugins für Anwendungssicherheit und Observability in Node.js direkt in Ihrer IDE

Als Entwickler verbringen wir viel Zeit in unseren IDEs: Wir schreiben neuen Code, überarbeiten bestehenden Code, fügen Tests hinzu, beheben Fehler und vieles mehr. In den letzten Jahren sind IDEs zu leistungsstarken Tools geworden, die Entwickler bei allem unterstützen – von der Arbeit mit HTTP-Anfragen bis hin zur allgemeinen Produktivitätssteigerung. Da stellt sich die Frage: Was wäre, wenn wir Sicherheitsprobleme in unserem Code verhindern könnten, bevor wir ihn veröffentlichen? Was wäre, wenn wir direkt in der IDE Einblick auf Code-Ebene in die Vorgänge innerhalb unserer Anwendungen in der Produktion erhalten könnten?

Hier kommen die besonderen Tools zum Einsatz, die Entwickler in den Mittelpunkt stellen. Mit dem richtigen IDE-Plugin lassen sich Observability und Sicherheit direkt in die täglichen Workflows von Entwicklern integrieren – genau dort, wo sie am effektivsten sind.

In diesem Blogbeitrag sehen wir uns Folgendes an:

• Wie Sie direkt in Ihrer IDE in Echtzeit Einblick auf Code-Ebene in Ihre Datenstrukturen erhalten

• Wie Sie schädliche Benutzereingaben in einer Node.js-Anwendung in der Produktion erkennen

• Wie Sie Sicherheitsprobleme in Ihrem Code und Ihren Open-Source-Abhängigkeiten finden und beheben

So erhalten Sie in Echtzeit Einblick in Ihre Anwendung – direkt in Ihrer IDE

Folgendes benötigen Sie, um diesem Beitrag zu folgen:

1. IntelliJ IDEA (Die Unterstützung für Visual Studio Code ist bei Lightrun in Kürze verfügbar – melden Sie sich hier für die Beta an, um sie als Erste zu erhalten!)

2. Ein Lightrun-Konto sowie das IntelliJ-Plugin von Lightrun und der Node.js-Agent, der derzeit noch in der Betaversion ist

Sobald das IntelliJ-IDEA-Plugin installiert ist, klicken Sie auf die Schaltfläche Register. Daraufhin werden Sie in Ihrem Browser durch einen unkomplizierten Registrierungsprozess geführt:

Als Nächstes müssen wir den Lightrun-Node.js-Agenten installieren und für die Node.js-Anwendung konfigurieren. Während der Registrierung werden Ihnen Anweisungen angezeigt. Falls Sie sie verpasst haben, finden Sie sie hier noch einmal:

1. Installieren Sie den Lightrun-Agenten im Projektordner, indem Sie Folgendes ausführen: npm install lightrun

2. Initialisieren Sie den Lightrun-Agenten am Anfang der Codebasis Ihrer Node.js-Anwendung, direkt im Einstiegscode der Datei app.js, wie folgt (die Werte <YOUR-COMPANY-NAME> und <YOUR-COMPANY-SECRET> werden Ihnen während der Registrierung auf dem Bildschirm angezeigt):

   require('lightrun').start({ company: '', apiEndpoint: 'app.lightrun.com', lightrunSecret: '', caPath: '',});

Es wäre nicht richtig, wenn ich nicht auf den Aufschrei Secrets im Code eingehen würde. Sobald Sie diesen Punkt erreicht haben, sollten Sie als Erstes die Codezeile für lightrunSecret wie folgt ändern:

1require('lightrun').start({
2    company: '<YOUR-COMPANY-NAME>',
3    apiEndpoint: 'app.lightrun.com',
4    lightrunSecret: '<YOUR-COMPANY-SECRET>',
5    caPath: '',
6});

Wenn Sie die Anwendung anschließend lokal starten, müssen Sie diese Umgebungsvariable zunächst verfügbar machen. Wenn Sie die Anwendung über die Befehlszeile starten, geht das so:

1lightrunSecret: process.env.LIGHTRUN_API_KEY

Hinweis: Sie müssen den Export-Befehl nur einmal ausführen. Danach ist die Variable in Ihrer Terminal-Sitzung verfügbar, solange Sie dieselbe Sitzung weiterverwenden.

Sobald Sie die Anwendung starten, sehen Sie in der rechten Seitenleiste, dass das Lightrun-Plugin nun korrekt konfiguriert und verbunden ist. Das erkennen Sie an der Anzeige des Namens Ihres Rechners (bei mir „Lirans-MBP“):

1export LIGHTRUN_API_KEY=<YOUR-COMPANY-SECRET>
2npm run start

So erkennen Sie schädliche Benutzereingaben in einer Node.js-Anwendung in der Produktion

Die Node.js-Anwendung, mit der wir experimentieren, ist Snyks Goof-TODO-Anwendung – eine JavaScript- und Node.js-To-do-Anwendung, mit der sich Notizen erstellen lassen.

Sie können eine Kopie herunterladen, indem Sie das GitHub-Projekt klonen. Folgen Sie anschließend den üblichen Installationsanweisungen für npm-Projekte, um die Abhängigkeiten einzurichten. Beachten Sie, dass die Anwendung beim Start außerdem eine MongoDB-Datenbank benötigt, mit der sie sich verbinden kann.

Sobald die Anwendung läuft, sollte sie wie im Screenshot unten aussehen. Sie werden feststellen, dass sie eine interessante Funktion hat. Wenn ich ihr eine To-do-Zeichenfolge wie Get my app secured in 15 minutes übergebe, verwendet sie das Open-Source-npm-Paket humanize-ms, um den Text 15 minutes in das formatierte Format [15m] umzuwandeln. Das Paket humanize-ms wird etwa 4.500.000 Mal pro Woche heruntergeladen und scheint daher eine gute Wahl zu sein.

Wenn Sie sich für Sicherheit interessieren und bereits Erfahrung mit der Backend-Entwicklung von Anwendungen haben, hätten Sie wahrscheinlich sichergestellt, dass die Eingabe bestimmten Validierungen und einem erwarteten Schema entspricht.

Diese Anwendung läuft jetzt jedoch in der Produktion. Ich weiß nicht, welche Benutzereingaben sie erhält, und möchte keine Funktionen beeinträchtigen. Gleichzeitig möchte ich Einblick in potenziell gefährliche Benutzereingaben erhalten. Genau hier glänzt Lightrun!

Ich möchte eine Benachrichtigung erhalten, falls jemand eine Benutzereingabe mit mehr als 10.000 Zeichen sendet. Dazu füge ich in IntelliJ direkt in der Codezeile, die den Eingabetext verarbeitet, ein Lightrun-Log mit einer Bedingung hinzu. So sieht das aus:

Wählen Sie dazu nach einem Rechtsklick auf die Codezeile den Anmerkungstyp Log aus und richten Sie die Protokollierungsregel wie folgt ein: item.length>10000

Damit wird in meiner laufenden Node.js-Anwendung eine Benachrichtigung eingerichtet, die ausgelöst wird, sobald eine Anfrage diesen Codepfad erreicht und die Bedingung erfüllt – also eine Eingabe mit mehr als 10.000 Zeichen enthält.

Nachdem ich die Aktion hinzugefügt habe, wird über der Codezeile eine praktische Anmerkung angezeigt, zusammen mit dem Namen der Person, die sie hinzugefügt hat. So wird die Aufmerksamkeit darauf gelenkt und Entwicklern, die sich künftig um technische Schulden und Code-Refactoring kümmern, wertvolle Informationen bereitgestellt:

Benachrichtigungen direkt in der IDE hinzuzufügen, ist großartig. Aber wissen Sie, was noch besser ist? Diese Benachrichtigungen direkt in der IDE-Konsole anzuzeigen, statt eine neue Webseite zu öffnen, um Protokolle zu durchsuchen.

Damit das funktioniert, öffnen Sie die rechte Seitenleiste des Lightrun-Plugins und klicken Sie beim Agenten-Eintrag auf das Symbol ganz rechts mit der Aufschrift PIPE. Klicken Sie anschließend auf die Schaltfläche Both. Dadurch werden die Benachrichtigungsprotokolle sowohl an die Lightrun-SaaS-App als auch direkt an das Lightrun-Konsolenfenster in meiner IDE gesendet. Juhu!

Nachdem wir nun eine Benachrichtigung eingerichtet haben, testen wir das Senden umfangreicher Payloads. Dafür verwende ich einige praktische Befehlszeilen-Tools, die mir zur Verfügung stehen:

1. Die Shell-Konfiguration Oh My Zsh (wer mag keine schicke Shell-Eingabeaufforderung?)

2. Das Tool HTTPie, um die HTTP-Anfrage zum Hinzufügen eines To-do-Eintrags zu senden

3. Das Unix-Tool seq, mit dem sich ein Zeichen ganz einfach X-mal wiederholen lässt

Damit sende ich die Payload mit folgendem Befehl:

1echo 'content=Buy milk in 'seq -s "" -f "5" 60000 'minutes' | http --form http://localhost:3001/create -v

Dadurch entsteht der To-do-Text Buy milk in 500000... minutes, wobei auf die Zahl 5 weitere 60.000 Nullen folgen – eine ziemlich lange Zeichenfolge.

In der Anwendungsoberfläche sieht das so aus:

Wie Sie sehen, ist die Anwendung nicht abgestürzt, und auch die MongoDB-Datenbank ist nicht abgestürzt. Der einzige erkennbare Nebeneffekt scheint zu sein, dass das npm-Paket humanize-ms die Zeitangabe einfach in das Wort Infinity umwandelt. Insgesamt ergibt das Sinn und ist offenbar kein echtes Problem.

Wissen Sie noch, dass wir dafür in der IDE eine Benachrichtigung eingerichtet haben?

Sehen wir uns an, wie das aussieht …

Sehen Sie die hervorgehobene Zeile im Lightrun-Konsolenfenster? Wir erhalten direkt in der IDE Benachrichtigungen, wenn die Protokollierungsbedingung für eine HTTP-Anfrage erfüllt ist, die an eine laufende Anwendung in der Produktion gesendet wurde. Das ist ziemlich praktisch – und wirklich hilfreich!

Doch worum geht es bei dieser Benachrichtigung eigentlich? Lesen Sie weiter …

So finden und beheben Sie Sicherheitsprobleme in Ihrem Code und Ihren Open-Source-Abhängigkeiten

Offenbar enthält diese Version des npm-Pakets humanize-ms indirekte Sicherheitslücken. Die 4.500.000 wöchentlichen Downloads waren irreführend! Die Sicherheitslücke in diesem Paket könnte für jede Node.js-Webanwendung verheerende Folgen haben.

Woher ich das weiß? Ich habe das IntelliJ-Plugin von Snyk installiert und mein Projekt damit scannen lassen. Dabei wurden diese und einige weitere Sicherheitslücken entdeckt. Sehen wir uns an, wie Sie einen Scan ausführen und wie schwerwiegend diese Sicherheitslücke ist – mithilfe der Benachrichtigung in Lightrun zu umfangreichen Benutzereingaben.

Sobald Sie das IntelliJ-Plugin von Snyk installiert und authentifiziert haben (eine Schritt-für-Schritt-Anleitung finden Sie unter Plugin installieren), klicken Sie im Fenster des Snyk-Plugins auf die grüne Schaltfläche Play, um einen Sicherheitsscan zu starten.

Die Scan-Ergebnisse umfassen die folgenden potenziellen Sicherheitsprobleme:

1. Sicherheitslücken in Ihren Open-Source-Bibliotheken von Drittanbietern, beispielsweise in npm-Paketen, die Sie in Ihre Codebasis importieren. Wenn Sie Projekte in anderen Sprachen wie Java, Ruby oder Python scannen, erkennt Snyk automatisch die Paketmanifestdatei und scannt auch diese Projekte.

2. Code-Sicherheitsprobleme in Ihrem eigenen Code. Derzeit werden JavaScript, TypeScript, Java und Python unterstützt.

Hier sehen Sie die Ergebnisse des Sicherheitsscans von Snyk Open Source für die npm-Pakete von Drittanbietern, die ich als Abhängigkeiten zu diesem TODO-Projekt hinzugefügt habe:

Beim Durchsehen der Ergebnisse sehen Sie, dass diese TODO-Anwendung einige Sicherheitslücken aufweist. Die Anwendung wurde absichtlich verwundbar gestaltet, damit wir diese Sicherheitslücken und ihre Behebung demonstrieren, üben und kennenlernen können.

Wissen Sie noch, dass wir das npm-Paket humanize-ms zum Parsen und Formatieren von Zeitzeichenfolgen verwenden? Offenbar bringt es eine Regular Expression Denial of Service-Sicherheitslücke (ReDoS) mit sich, da es von einem verwundbaren Versionsbereich des beliebten npm-Pakets ms abhängt:

Kehren wir zu unserer Payload für den Sicherheits-Exploit zurück und sehen sie uns noch einmal an:

1echo 'content=Buy milk in 'seq -s "" -f "5" 60000 'minutes' | http --form http://localhost:3001/create -v

Wie Sie sich erinnern, wurde bei der Ausführung dieses Befehls eine sehr lange Zeichenfolge als To-do-Eintrag gesendet. Soweit wir erkennen konnten, führte das jedoch zu keinem Denial-of-Service-Angriff. Die Anwendung verarbeitete weiterhin ganz normal Anfragen, und die Node.js-Anwendung sendete fast sofort eine Antwort zurück.

Reguläre Ausdrücke sind jedoch … knifflig. Wenn sie nicht richtig geschrieben sind, können sie anfällig für katastrophales Backtracking sein. Das bedeutet im Wesentlichen, dass die Berechnung bei einer linearen Eingabe überproportional lange dauert.

Um diese Anwendung effektiv anzugreifen, muss ich in meiner Exploit-Payload lediglich das Wort minutes in minutea umbenennen und den Befehl ausführen. Zum Vergleich sehen Sie sich diesen Screenshot an, der den Zustand vor dem Absenden der Anfrage und den Befehl htop mit normaler CPU-Auslastung auf meinem Laptop zeigt:

Bei einer ReDoS-Sicherheitslücke erwarte ich, dass die Node.js-Anwendung für die Berechnung des regulären Ausdrucks sehr viel Zeit benötigt. Da die Node.js-Architektur auf einem einzelnen Thread basiert, geraten alle nachfolgenden Anfragen ins Stocken. Die CPU-Auslastung steigt auf 100 %, während alle verfügbaren Ressourcen vergeblich für die Berechnung des regulären Ausdrucks aufgebraucht werden.

Senden wir unsere ReDoS-Exploit-Payload:

1echo 'content=Buy milk in 'seq -s "" -f "5" 60000 'minutea' | http --form http://localhost:3001/create -v

Und los! Im Terminalfenster oben rechts sehen Sie die gesendete HTTP-Anfrage, auf die keine sofortige Antwort eingeht. Im Terminalfenster unten links sehen Sie den Node.js-Prozess als grün hervorgehobenen obersten Tabelleneintrag, der 98,4 % der CPU-Ressourcen verbraucht:

Als Nächstes müssen natürlich diese und andere Sicherheitsprobleme behoben werden. Sobald Sie Ihre Projekte in die Snyk-Anwendung importieren, scannt und überwacht Snyk sie kontinuierlich im Hintergrund. Außerdem erstellt Snyk automatisch Pull Requests für Ihre Git-Repositories – auf GitHub oder anderswo –, um die verwundbaren Versionen in Ihren Projekten zu aktualisieren. Mehr dazu erfahren Sie im Artikel Erste Schritte mit Snyk Open Source.

Sicherheit und Observability, die Entwickler in den Mittelpunkt stellen

Tools wie Lightrun und Snyk, die Entwickler in den Mittelpunkt stellen, helfen Entwicklern, im Arbeitsalltag produktiver zu sein, indem sie ihnen die Daten bereitstellen, statt sie aus ihren Workflows herauszureißen.

Wenn Sie Observability und Sicherheit direkt in der IntelliJ-IDE oder über die Befehlszeile nutzen, können Entwickler den Datenverkehr in Echtzeit überwachen und Sicherheitsprobleme finden und beheben, bevor sie den Continuous-Integration-Server erreichen – geschweige denn die Produktion.

Die folgenden Ressourcen helfen Ihnen beim Einstieg in beide Bereiche:

1. Erste Schritte mit Snyk

2. Erste Schritte mit Lightrun