Posted on 22/09/2022 20:45:00
It is much more common than you think. All a hacker needs to do is either hijack an existing registry user or “typosquat” a package on very popular packages. This is further made easier by registries listing statistics such as the “Weekly Downloads” and “Total Downloads” giving you a rough idea of how large of a pie you could poison. All of this is doable by social engineering or betting on people making typos, which we all do make.
Reduce amount of dependencies in your code. That’s the easiest thing you can do to minimize attack vectors. Usually libraries are created with “cover-all” functionality in mind, rather than just catering to your specific use case, and even if it does cater to your use case, chances are it’s overengineered. You will much more benefit in performance, security and code quality by creating a lot of those said dependencies yourself - an added bonus is becoming a much more versed programmer.
Another solution is to fork the dependencies if you do need them, audit the code of what you’re going to be using, use direct verifiable links rather than just the package names and if the package manger supports any form of hash checking or other means to do so, use it!
Which brings me to another point, the way a lot of current registries work are on blind trust basis - you trust the registry to retrieve you the code by a simple prompt - the package name and version, you do not ask for any hash verification, neither do you ask for means to verify the author. You can’t even be sure that package v0.0.1 is the same thing as it was a week ago, because that data can be overwritten by the package author. There are so many clear design flaws with these package managers that are essentially nothing more than just dumb downloaders without any regard to security.
Even the simplest sha256 check would improve the situation, if nothing else. The ReactOS Applications Manager is a lot more secure by design compared to all of the afforementioned package managers just by the hash check alone.
I never said that. There is nothing wrong with sharing code, but code should still be under scrutiny, be it open or not, it must be audited before being integrated into a project and re-checked on updates. Personally, my interests align for open source being a net positive - I share scripts for projects I do and even the source code for this very website.
If you fork a project using the above advice, please respect the license terms, give credit where due and if feasible, open a pull request upstream with your improvements.
Yes. You can’t always skip the hard work. If this post offended you, I’m not sorry either.
Thanks for reading,
Join us at Matrix: #based-quest:cernodile.com
© 2021 - 2022 based.quest | Powered by Hugo | Donate | Atom RSS