Behebung einer Schwachstelle zur Umgehung des Prototyp-Override-Schutzes in qs

Letzten Monat haben wir eine schwerwiegende Schwachstelle zur Umgehung des Prototyp-Override-Schutzes im Paket qs in unsere Datenbank aufgenommen. Die Fehlerbehebung wurde vor etwa einer Woche in aktualisierten Versionen der Bibliothek veröffentlicht. In diesem Beitrag erfahren Sie mehr über die Schwachstelle und wie Sie sie beheben können.

qs ist ein beliebtes npm-Paket – knapp 40 Millionen Downloads im vergangenen Monat – und wird verwendet, um Querystring-Parameter in Objekte umzuwandeln. Zum Beispiel:

1qs.parse('a=b&c=d');
2// {a:'b', c: 'd'}

Das ist zwar hilfreich, doch die eigentliche Stärke von qs liegt in den erweiterten Funktionen, die es ermöglicht. Mit qs können Sie sogar verschachtelte Objekte in Ihren Querystrings erstellen, indem Sie Klammern ([ oder ]) verwenden.

1qs.parse('a[b]=c');
2// {
3//   a: {
4//     b: "c"
5//   }
6// }

Die Möglichkeit, verschachtelte Objekte in Querystring-Parametern zu erstellen, birgt auch gewisse Risiken. Wenn die Parameter nicht ordnungsgemäß geprüft werden, könnten Sie Eigenschaften im Prototyp des Objekts überschreiben. Sie könnten zum Beispiel versuchen, die Methode hasOwnProperty des Objekts zu überschreiben:

1qs.parse('a[hasOwnProperty]=b');

Zum Glück würde das oben gezeigte Beispiel nicht funktionieren. Standardmäßig ignoriert qs alle Parameter (wie hasOwnProperty), die Eigenschaften des Objektprototyps überschreiben würden. Dazu prüft qs, ob in dem Parameter öffnende und schließende Klammern vorhanden sind, liest den Inhalt dazwischen aus und vergleicht ihn anschließend mit dem Objektprototyp, um festzustellen, ob es sich um eine native Eigenschaft handelt. Es gibt eine Option, die das Überschreiben von Prototypen ermöglicht, doch qs rät ausdrücklich davon ab.

Leider gab es eine Lücke in der Validierung, durch die sich eine Eigenschaft im Objektprototyp weiterhin überschreiben ließ, wenn dem Parameter ein nicht passendes Zeichen [ oder ] vorangestellt wurde.

Mit dem folgenden Beispiel ließe sich etwa die Methode hasOwnProperty des Objekts überschreiben, obwohl wir qs ausdrücklich angewiesen haben, das Überschreiben von Prototypen zu verhindern:

1var paramData = qs.parse("]=hasOwnProperty", { allowPrototypes: false });
2// {hasOwnProperty = true}
3
4paramData.hasOwnProperty('toString');
5// Results in Type Error: paramData.hasOwnProperty is not a function

Am wahrscheinlichsten wären dadurch Fehler und unerwartete Instabilität in Ihrer Anwendung. Je nach Anwendungslogik könnte die Auswirkung jedoch deutlich schwerwiegender sein: In manchen Fällen könnten Angreifer sogar den Ausführungsablauf Ihrer Anwendung ändern.

Die Fehlerbehebung

Unser Sicherheitsteam entdeckte das Problem am 13. Februar und meldete es dem Paketverantwortlichen. Dieser reagierte schnell und veröffentlichte drei Tage später eine Fehlerbehebung in den Versionen 6.0.3, 6.1.1, 6.2.2 und 6.3.1.

Die Fehlerbehebung löste das Problem, wenn der Parameter mit ]= begann. Sie reichte jedoch nicht aus – wie sich herausstellte, war qs weiterhin anfällig, wenn der Angreifer [= verwendete. Daraufhin passte der Paketverantwortliche die Logik an und veröffentlichte eine umfassendere Fehlerbehebung in den Versionen 6.4.0, 6.3.2, 6.2.3, 6.1.2 und 6.0.4.

Um das Problem zu beheben, müssen Sie auf eine dieser Paketversionen aktualisieren. Wenn Sie Snyk zur Überwachung Ihres Projekts verwenden, wurden Sie wahrscheinlich bereits aufgefordert, das Update entweder über einen automatisch erstellten Pull Request oder durch Ausführen von snyk wizard über die CLI vorzunehmen.

Andernfalls müssen Sie prüfen, ob Ihre Anwendung das Paket qs verwendet – entweder als direkte Abhängigkeit, die in Ihrer Datei package.json aufgeführt ist, oder als nicht aufgeführte Abhängigkeit, die von einer Ihrer direkten Abhängigkeiten eingebunden wird – und auf die neueste Version aktualisieren.