NPM Paket Nodemon mit Backdoor / Trojaner versehen

new Account() schrieb:
Die Gefahr Schadcode zu bekommen verringert sich nicht dadurch, dass ein Unternehmen seine 1500 Pakete auf eins zusammenfasst.
Siehe das was andy geschrieben hat:
andy_m4 schrieb:
Aber da ist dann halt zumindest noch eine Instanz die so ein bisschen ein Auge drauf hat.

Bei node.js fehlen solche oder ähnliche Prozesse ganz.
In die Richtung geht das.
Die Einbindung von Modulen anonymer nonames verringern, die tendenziell weniger zuverlässig sind und die Einbindung von gut gepflegten Modulen vergößern.
Mit den Maßnahmen die ich oben vorgeschlagen habe. Die du auch falsch verstanden hast. Entweder sollen die vielen module vieler maintainer zu einem modul zusammengefasst werden oder viele module bleiben, aber von einer vertrauenswürdigeren Instanz maintained, z.B. ein Unternehmen, das auf node.js setzt.
 
  • Gefällt mir
Reaktionen: new Account()
Kann mir einer mal ein Beispiel für ein großes, kommerzielles Projekt nennen, das mit Node.js umgesetzt ist?

Nur mal als kleines Beispiel zur Verdeutlichung des Problemes: Ich habe privat die Homematic Homekit-Bridge installiert. Das ist eine recht kleine und einfache Node.js Anwendung. Dafür sind 158 externe Module geladen worden.

Meine großen Softwareprojekte auf der Arbeit haben 19 Abhängigkeiten an externe Bibliotheken. Da habe ich bei so etwas wie XML-Security-Gelumpe (für SAML Token) auch schon selber den Code angeschaut, der für ein Patch in das Git commitet wurde. Bei 19 Libs ist das noch machbar. Bei 158 ist das absurd. Und wenn eine Node.js Anwendung mal eine gewisse Größe hat reden wir eher über tausende Module, die da geladen werden.

Aus meiner Sicht ist das Node.js Ökosystem an genau dieser Stelle kaputt und deswegen nicht für große, kommerzielle Projekte geeignet. Obwohl ich den Ansatz gut finde für Webapps und Mobile-Apps nur noch eine einzige Sprache zu verwenden. Aber die Umsetzung ist scheiße. Man hätte da auf signierte Code-Repositorys und vertrauenswürdige Maintainer und vor allem weniger Abhängigkeiten innerhalb von Modulen, dafür etwas größere Module achten müssen.

Ich verstehe z.B. auch nicht, warum ich für ein einziges Projekt (Homekit-Bridge) colors@1.0.3, colors@0.6.2 & colors@1.3.2 installiert haben muss. Was soll so ein Quatsch?
 
  • Gefällt mir
Reaktionen: BeBur
Sehr gruselig, allerdings:
PCI DSS bedingt, dass die Einbindung von Kreditkarten-Formularen in den (imHo) stark überwiegenden Fällen per iFrame passiert. Soweit ich weiß ist das Standard für alle Payment-Abwickler.
Aber sicherlich kann man mit genug Dummheit drum herum bauen und wird sicher auch gemacht.
Bottom Line: Niemals Kreditkarten-Infos rausgeben, wenn das Formular nicht per iFrame von einem großen Anbieter eingebunden wurde.

Frage: Wo kann ich Websites anschwärzen, die eigene Formulare verwenden, aber vermutlich nicht die PCI DSS Compliance aufweisen (und die ggf. auch nicht reagieren, wenn man sie darauf hinweist).
 
Wenn ich mir die eigenen Dev-Blogs, von z.B. Linkedin oder Netflix oder Paypal, zum Thema "Technology Stack" und "Node.js" durchlese, klingt das alles viel weniger Jubelperser-mäßig. Im großen und ganzen basiert sowohl Linkedin als auch Netflix und auch Paypal auf einen Mix aus Java/Python/Go/Node.js und nutzt Node.js dann hauptsächlich für den Datenaustausch zwischen den Microservices. Immerhin, ich hätte mich das nicht getraut und lieber etwas eigenes entwickelt aber das müssen die ja am Ende verantworten :) Was übrigens nichts darüber aussagt, ob die Unternehmen überhaupt auch nur ein einziges npm Modul nutzen oder nicht - so würde ich es dann wohl machen: Lieber "from the scratch" die notwendigen Node.js-Anwendungen entwerfen und in die Microservices einbinden. Ich glaube kaum, das sich Läden wie Pypal oder die Nasa auf ein so instabiles Ökosystem wie npm verlassen können. Verantwortung und so...

Am Ende stelle ich nach stundenlangen lesen von Dev-Blog Einträgen am dritten Advent fest, dass sich die "Node.js" Szene da auch gerne mal größer und wichtiger darstellt, als sie es eigentlich ist.
Am Ende muss man alles immer in Relation betrachten und jede Sprache hat so ihre Vor- und Nachteile. Wobei ich persönlich Node.js bzw. Javascript / Typeskript (insbesondere) echt gut finde, npm jedoch sehr schlecht und das damit verbundene Ökosystem erst recht.
 
  • Gefällt mir
Reaktionen: Yuuri und BeBur
Zurück
Oben