Diese Übersetzung zur VerfĂŒgung gestellt von StrongLoop / IBM.

Dieses Dokument kann im Vergleich zur englischen Dokumentation veraltet sein. Aktuelle Updates finden Sie in der englischen Dokumentation.

✖

Best Practices in Produktionsumgebungen: Sicherheit

Überblick

Der Begriff “Produktion” bezieht sich auf die Phase im Softwarelebenszyklus, in der eine Anwendung oder API fĂŒr Endbenutzer oder Verbraucher allgemein verfĂŒgbar ist. Im Gegensatz dazu wird in der Phase “Entwicklung” noch aktiv Code geschrieben und getestet. Die Anwendung ist in dieser Phase noch nicht fĂŒr externen Zugriff verfĂŒgbar. Die entsprechenden Systemumgebungen werden als Produktionsumgebungen und Entwicklungsumgebungen bezeichnet.

Entwicklungs- und Produktionsumgebungen werden in der Regel unterschiedlich konfiguriert und weisen deutliche Unterschiede bei den Anforderungen auf. Was in der Entwicklung funktioniert, muss in der Produktion nicht unbedingt akzeptabel sein. Beispiel: In einer Entwicklungsumgebung ist eine ausfĂŒhrliche Protokollierung von Fehlern fĂŒr Debuggingzwecke sinnvoll. Dieselbe Vorgehensweise kann in einer Produktionsumgebung jedoch zu einem Sicherheitsproblem fĂŒhren. In einer Entwicklungsumgebung mĂŒssen Sie sich keine Gedanken zu Themen wie Skalierbarkeit, ZuverlĂ€ssigkeit und Leistung machen, wĂ€hrend dies in einer Produktionsumgebung kritische Faktoren sind.

In diesem Beitrag werden einige der Best Practices in Bezug auf das Thema Sicherheit fĂŒr Express-Anwendungen behandelt, die in der Produktionsumgebung bereitgestellt werden.

Verwenden Sie keine veralteten oder anfÀlligen Versionen von Express

Express 2.x und 3.x werden nicht mehr gepflegt. Sicherheits- und Leistungsprobleme in diesen Versionen werden nicht mehr behoben. Verwenden Sie diese Versionen nicht! Wenn Sie noch nicht auf Version 4 umgestellt haben, befolgen Sie die Anweisungen im Migrationshandbuch.

Stellen Sie außerdem sicher, dass Sie keine anfĂ€lligen Express-Versionen verwenden, die auf der Seite mit den Sicherheitsupdates aufgelistet sind. Falls doch, fĂŒhren Sie ein Update auf eines der stabileren Releases durch, bevorzugt das aktuelle Release.

TLS verwenden

Wenn ĂŒber Ihre Anwendung vertrauliche Daten bearbeitet oder ĂŒbertragen werden, sollten Sie Transport Layer Security (TLS) verwenden, um die Verbindung und die Daten zu schĂŒtzen. Diese Technologie verschlĂŒsselt Daten, bevor sie vom Client zum Server gesendet werden. Dadurch lassen sich einige gĂ€ngige (und einfache) Hackerattacken vermeiden. Auch wenn Ajax- und POST-Anforderungen nicht sofort offensichtlich und in Browsern “versteckt” zu sein scheinen, ist deren Netzverkehr anfĂ€llig fĂŒr das Ausspionieren von Paketen und Man-in-the-Middle-Attacken.

Möglicherweise sind Sie mit SSL-VerschlĂŒsselung (Secure Socket Layer) bereits vertraut. TLS ist einfach der nĂ€chste Entwicklungsschritt bei SSL. In anderen Worten: Wenn Sie bisher SSL verwendet haben, sollten Sie ein Upgrade auf TLS in ErwĂ€gung ziehen. Generell empfehlen wir fĂŒr TLS den Nginx-Server. Eine gute Referenz zum Konfigurieren von TLS auf Nginx (und anderen Servern) ist Empfohlene Serverkonfigurationen (Mozilla Wiki).

Ein handliches Tool zum Abrufen eines kostenloses TLS-Zertifikats ist außerdem Let’s Encrypt, eine kostenlose, automatisierte und offene Zertifizierungsstelle der Internet Security Research Group (ISRG).

“Helmet” verwenden

Helmet kann beim Schutz Ihrer Anwendung gegen einige gÀngige Schwachstellen hilfreiche Dienste leisten, indem die HTTP-Header entsprechend konfiguriert werden.

“Helmet” ist eine Ansammlung von neun kleineren Middlewarefunktionen, ĂŒber die sicherheitsrelevante HTTP-Header festgelegt werden.

Installieren Sie “Helmet” wie alle anderen Module:


$ npm install --save helmet

So verwenden Sie “Helmet” in Ihrem Code:


...
var helmet = require('helmet');
app.use(helmet());
...

Deaktivieren Sie mindestens den X-Powered-By-Header

Wenn Sie “Helmet” nicht verwenden wollen, sollten Sie mindestens den X-Powered-By-Header deaktivieren. Angreifer können diesen Header (der standardmĂ€ĂŸig aktiviert ist) zum Erkennen von Anwendungen mit Express verwenden und dann gezielte Attacken in die Wege leiten.

Ein bewÀhrtes Verfahren ist also, diesen Header mit der Methode app.disable() zu deaktivieren:


app.disable('x-powered-by');

Wenn Sie helmet.js verwenden, kĂŒmmert sich das Tool darum.

Cookies sicher verwenden

Um sicherzustellen, dass Cookies Ihre Anwendung nicht fĂŒr Angriffsmöglichkeiten öffnen, sollten Sie den standardmĂ€ĂŸigen Namen des Sitzungscookies nicht verwenden und die Cookie-Sicherheitsoptionen entsprechend festlegen.

Es gibt zwei wesentliche Middleware-Cookie-Sitzungsmodule:

Der Hauptunterschied zwischen diesen beiden Modulen liegt darin, wie die Cookie-Sitzungsdaten gespeichert werden. Die express-session-Middleware speichert Sitzungsdaten auf dem Server. Sie speichert nur die Sitzungs-ID im Cookie und nicht die Sitzungsdaten. StandardmĂ€ĂŸig wird dabei der speicherinterne Speicher verwendet. Eine Verwendung der Middleware in der Produktionsumgebung ist nicht vorgesehen. In der Produktionsumgebung mĂŒssen Sie einen skalierbaren “Session-Store” einrichten. Siehe hierzu die Liste der kompatiblen Session-Stores.

Im Gegensatz dazu implementiert die cookie-session-Middleware cookiegestĂŒtzten Speicher: Sie serialisiert die gesamte Sitzung zum Cookie und nicht nur einen SitzungsschlĂŒssel. Diese Middleware sollten Sie nur verwenden, wenn Sitzungsdaten relativ klein sind und einfach als primitive Werte (und nicht als Objekte) codiert sind. Auch wenn Browser mindestens 4096 Byte pro Cookie unterstĂŒtzen sollten, mĂŒssen Sie sicherstellen, dass dieses Limit nicht ĂŒberschritten wird. Überschreiten Sie auf keinen Fall die GrĂ¶ĂŸe von 4093 Byte pro DomĂ€ne. Achten Sie zudem darauf, dass die Cookiedaten fĂŒr den Client sichtbar sind. Wenn also ein Grund vorliegt, die Daten sicher oder unkenntlich zu machen, ist “express-session” möglicherweise die bessere Wahl.

Verwenden Sie nicht den standardmĂ€ĂŸigen Namen des Sitzungscookies

Die Verwendung des standardmĂ€ĂŸigen Namens des Sitzungscookies kann Ihre Anwendung anfĂ€llig fĂŒr Attacken machen. Das mögliche Sicherheitsproblem ist vergleichbar mit X-Powered-By: ein potenzieller Angreifer kann diesen Header verwenden, um einen elektronischen Fingerabdruck des Servers zu erstellen und Attacken entsprechend zu platzieren.

Dieses Problem lÀsst sich vermeiden, wenn Sie allgemeine Cookienamen verwenden; z. B. durch Verwendung der express-session-Middleware:


var session = require('express-session');
app.set('trust proxy', 1) // trust first proxy
app.use( session({
   secret : 's3Cur3',
   name : 'sessionId',
  })
);

Legen Sie die folgenden Cookieoptionen fest, um die Sicherheit zu erhöhen:

Dies ist ein Beispiel zur Verwendung der cookie-session-Middleware:


var session = require('cookie-session');
var express = require('express');
var app = express();

var expiryDate = new Date( Date.now() + 60 * 60 * 1000 ); // 1 hour
app.use(session({
  name: 'session',
  keys: ['key1', 'key2'],
  cookie: { secure: true,
            httpOnly: true,
            domain: 'example.com',
            path: 'foo/bar',
            expires: expiryDate
          }
  })
);

Stellen Sie sicher, dass Ihre AbhÀngigkeiten sicher sind

Die Verwendung von “npm” zur Verwaltung der AnwendungsabhĂ€ngigkeiten ist leistungsfĂ€hig und bequem. Die Pakete, die Sie verwenden, können jedoch kritische SicherheitslĂŒcken enthalten, die sich auch auf Ihre Anwendung auswirken können. Die Sicherheit Ihrer Anwendung ist immer nur so gut wie das “schwĂ€chste Glied” in den AbhĂ€ngigkeiten.

Verwenden Sie eines oder beide der folgenden Tools, um sicherzustellen, dass die verwendeten Pakete von anderen Anbietern sicher sind: nsp und requireSafe. Die FunktionalitĂ€t der beiden Tools ist im Großen und Ganzen identisch.

nsp ist ein Befehlszeilentool, das die Node Security Project-Datenbank mit SicherheitslĂŒcken daraufhin ĂŒberprĂŒft, ob Ihre Anwendung Pakete mit bekannten SicherheitslĂŒcken verwendet. Installieren Sie dieses Tool wie folgt:


$ npm i nsp -g

Verwenden Sie diesen Befehl, um die Datei npm-shrinkwrap.json zur Validierung an nodesecurity.io zu senden:


$ nsp audit-shrinkwrap

Verwenden Sie diesen Befehl, um die Datei package.json zur Validierung an nodesecurity.io zu senden:


$ nsp audit-package

So verwenden Sie requireSafe, um Ihre Node-Module zu ĂŒberprĂŒfen:


$ npm install -g requiresafe
$ cd your-app
$ requiresafe check

Weitere Überlegungen

Dies sind einige weitere Empfehlungen aus der hervorragenden Node.js Security Checklist. In diesem Blogbeitrag finden Sie alle Details zu diesen Empfehlungen:

Vermeiden Sie andere Schwachstellen

Achten Sie auf Node Security Project-Empfehlungen, die Express oder andere Module, die Ihre Anwendung nutzt, beeintrÀchtigen können. Im Allgemeinen ist Node Security Project aber eine exzellente Ressource mit Wissen und Tools zur Sicherheit von Node.

Letztendlich können Express-Anwendungen – wie viele andere Webanwendungen auch – anfĂ€llig fĂŒr eine Vielzahl webbasierter Attacken sein. Machen Sie sich deshalb mit bekannten webspezifischen Schwachstellen vertraut und treffen Sie die geeigneten Vorkehrungen, um diese zu vermeiden.