Achtung! npm ist unsicher (by Design …) // deutsch

Vor knapp zwei Wochen wurde eine schwere Sicherheitslücke in npm entdeckt, die dazu führt, dass Entwicklerinnen und Entwickler sich bei der Installation von npm-Modulen unter gewissen Umständen Schadcode einfangen können. Wie funktioniert diese Sicherheitslücke, warum wird sie voraussichtlich nicht geschlossen, und wie kann man sich schützen?

00:00 – Einleitung
00:42 – npm und Semantic Versioning
02:20 – Vorabversionen als Sonderfall
03:28 – Das Dilemma von npm
04:43 – Eine Lücke in der Spezifikation
06:42 – Konform, aber trotzdem falsch
07:54 – Die Sicherheitsprüfung von npm
09:07 – Eine unklare Ursache
09:43 – Es funktioniert "wie erwartet"
10:11 – Wie kann man sich schützen?

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[makusgast]

Sehr gutes Format! Dieser Channel ist der Hammer!

[anihe]

Dazu fällt mir nur ein: Schmetterling-Monarch-Programm, das in gewissen dubiosen Kreisen gerne angewendet wird. Sobald die Negativ-Schlagzeilen beginnen, wird das positive Schmetterlings-Programm beendet und es beginnt das verderbliche Monarch-Programm. Ist wahrscheinlich auch für die KI geplant. Danke für die Hinweise. Das ist auch der Grund, , warum ehemals sehr gute Produkte nicht, wie erwartet, weiter verbessert, sondern "verhunzt" werden. Schön, dass es aufmerksame Menschen gibt.

[basti]

Sehr guter Node/Go Kanal. Hab angefangen meine APIs von Node auf Go umzustellen, unter anderem wegen genau solchen Gründen, weil Go einfach schneller ist und weil man dann nur noch eine single file executable hat, anstatt die ganze node runtime etc...

[daheck]

Ich höre die so gerne zu Golo, so entspannend ❤

[khmarbaise]

Bei einer Release Version, ist das auch in Maven exakt so. Auf SNAPSHOT Versionen (Das sind keine "Releases"; Releases sind immutable) bezieht man sich nur innerhalb einer Organisation (wenn überhaupt! Best Practice: Nein). Abgesehen davon gibt es im Central Repository keine SNAPSHOT Versionen... Das Central Repository liefert immer nur Release Versionen, somit ist auch der exakte Bezug zwischen Version und Code Stand garantiert! Das hat Maven bzw. das Central Repository schon vor NPM gemacht.
Der Kanal ist Klasse!

[pinkeHelga]

Ich betrachte Abhängigkeiten von Drittanbietern generell kritisch und versuche sie, wo nur irgendwie möglich, zu vermeiden. Allein schon, wenn die Unterstützung eines Tages eingestellt wird, ist es hoch problematisch, auf Alternativen umzustellen.

[TwilightTitus]

Eine Vorabversion ist immer unsicher und hat in produktiven Systemen nie was zu suchen. Und es gielt ebenfalls grundsätzlich, verwende niemals libs von Quellen die du nicht kennst oder selbst geprüft hast. Hier wird ein Problem skizziert und auf npm geschoben, was einfach in der Natur der Dinge liegt. Es gilt sowieso für jeden Entwickler, traue nie anderen Quellen. Es muss immer geprüft werden, was genutzt werden soll. Das gilt für alles was man nicht selbst erstellt hat und eigentlich gilt dieser Grundsatz auch für den eigenen Code.

[thomasspornraft]

npm verwendet "semver", das hat ein eingebautes Problem mit Vorabständen umzugehen und deswegen scheitert die Sicherheitsprüfung und das macht die Tür auf für Angriffe ? Hab ich das so halbwegs?

[micha]

Aus irgendeinem Grund kann ich das Problem nicht nachstellen. Zu deinem Beispiel von 6:29 liefert `semver.lt('1.0.0-alpha', '0.5.0')` als Ergebnis `false` zurück, was doch zu erwarten ist. Meiner Meinung nach ist der Part mit der Vorveröffentlichung nur dann anzuwenden wenn Major, Minor und Patch gleich sind. Da bei 0.5.0 und 1.0.0-alpha.1 der Unterschied schon in der Major-Version liegt, wird der gar nicht mehr hinzugezogen.

[makusgast]

Danke noch einmal für dieses Video. Gibt es zu dieser Lücke einen CVE Eintrag?

[woife]

Tolles Video danke für die Infos! Muss ich dann auch prüfen, ob Sub-Dependencies solche Versionen verwenden?

[apoc]

Ich habe nicht ganz verstanden wo hier der Angriffsvektor liegen soll. Geht es darum, dass Paketautoren malicious code einfügen können? Was hindert sie das einfach unter einer regulären Version zu veröffentlichen? Ist ja schließlich schon vorgekommen.

[yannickLamp]

In dem Projekt nutzen wir kein npm sondern binden die dependencies per cdn ein bzw. legen diese mit ab

wir benötigen NPM/Node glücklicherweise nur während der Entwicklung - aber ja wie hier erwähnt: Abhängigkeiten reduzieren, keine Prereleases und nach Möglichkeit auch keine "sehr neuen" Versionen (es gab ja leider auch schon die Fälle, wo Schadcode in sehr häufig verwendete Packages geladen wurde, weil der Zugang einzelner Entwickler gehackt wude).

[marcotroster]

Ich glaub ein echtes Problem wird es erst, wenn man über ne transitive Abhängigkeit Preview Pakete referenziert 😅 Ich entwickle zum Glück kein JavaScript aber hört sich echt fies an 🤔

[NachtmahrNebenan]

Na, das hat ja lange gedauert das festzustellen.

[michaelihde]

Da frag ich mich wie das zb bei php composer aussieht oder auch bei anderen pkg manager 🤔

[devchannel]

Verdammt, ich habe vor ein paar Monaten ein neues Projekt mit npm angefangen 😞

[thepaulcraft]

Warum kommen eure Videos eigentlich immer zu so super unpassenden uhrzeiten raus? 😅die meisten arbeiten doch oder sind in der schule