> Auto Dependency Resolution: If a file does require('underscore'), it is automatically installed and resolved. You can always create your own package.json file to install a specific version of a package.
This sounds like a security nightmare.
EDIT: to be clear, I don't meant he combination of both is a security concern, that each one of them separately is problematic.
# curl -v --path-as-is 127.0.0.1:3000/../../../../../etc/passwd
This project is brand new, I posted the repo publicly this morning. I frankly think this subthread is an overreaction. I don’t get the hate.
Due to PHP experience, this would've been something that I ensured was implemented properly from the outset. I know this to be true, because I've dabbled in the very space you're working in now, and it was one of the very first things I ensured: that no file could be served except from direct descendants. (I rethought my project and tossed the code)
For something like this you need to be absolutely sure about security. Have a look at the annals of PHP security issues - and most likely you'll see a lot of similarities that you'll need to make sure you address.
I'm sorry if you read hate in my words: definitely was NOT intended! I have nothing against you as a co-habitor of this wonderful planet! To me, the bug highlights that a few design considerations may have been overlooked.
Are you implying that you don’t think it’s ready for production use? If so, maybe you should do like a lot of projects, and warn about it loud and clear in the docs. It’s not clear at all that users should expect the type of blatant security problems that were discovered here.
People are allowed to screw up: it's how we learn. They got comments that pointed out flaws, they fixed them and posted a follow-up regarding that fix, why the hate? This person tried to make something cool, they learned important security lessons, and now have a deeper insight into what they made, and the world it operates in. How is this possibly a bad thing we don't want to have happen on HN?
 - https://www.npmjs.com/advisories
The moment I can upload files to the application folder that are executed, I can just `require('child_process').spawn("my_evil_stuff", )`. In particular "my_evil_stuff" could be some npm install command. I don't see how automatically installing the dependencies makes this worse than it already is.
EDIT: While this is a different attack vector than I was envisioning here, jexco has provided a scenario in which there are additional vulnerabilities: Vulnerable dependencies that cannot be managed.
At the risk of being presumptuous... When is security ever not a concern?
> small little one-off apps that might need _some_ backend functionality
The security implications of serving a static website vs. a dynamic application that processes payment and queries the database are two different beasts
If security is taught at the student level, by the time they get to junior developer they'll have an understanding of it / do it automatically.
When I was a hiring manager and scoped out juniors from bootcamps I had a conversation with some candidates and they would say, "I built user registration and login". When I asked them to talk more about it they said, "well I installed auth0"... Any student project which doesn't teach them how something works is not really teaching anything of value, is it?
Programming is not academic. It has more in common with plumbing and carpentry and electrician work: you learn only by doing, and you learn how to do it well by doing with critical supervision from a mentor.
Software development (and a lot of hardware development, to be fair) is unique in that doing it well requires functioning as both an engineer and a tradesperson. One's skill has to cover a wide section of the spectrum.
All joking aside, programming should be treated a lot more like engineering and a lot less like craft. Yes, it does have aspects of both, but neglecting the engineering aspects of it is proving to be increasingly harmful to our end users.
I think the curve of diminishing returns plays an important role. A near hack job will often get you 90% there, in terms of fulfilling what was exactly requested. I don't think this is true for any other skillset. It's so easy to make something featureful and fragile in software. The time and cost above that can be very difficult to justify to customers/management.
In the words of a previous boss, after I pointed out we need more testing, "Everything is working, we'll fix the bugs as they come".
Not everything runs online connected to the internet.
Internal applications where the entirety of the userbase are trusted employees. (Preferably, the userbase is small, too.)
Nobody’s going to bother finding vulnerabilities in an application where, if they break it, their own job gets harder.
Your sort of thinking is how you end up with Yahoo levels of account leaks.
Security always matters.
> Your sort of thinking is how you end up with Yahoo levels of account leaks.
I wouldn’t store any of my customers’ data on an insecure internal service! I know that’s mad!
> Security always matters.
The first part of securing a system is to come up with your threat model, isn’t it?
I'm completely sure that you're right. You know that would be irresponsible and reckless with lots of very sensitive data.
With that said, how sure can you be of every other person writing a simple, small, business app for just a handful of their coworkers? I've encountered some people doing exactly what you've described without the same level of cool-headed risk-weighing as you.
Famous last words.
And auto-dependency resolution also doesn't seem any larger a security concern, all it's doing is skipping an "npm install" command.
And as for automatic dependency resolution, this means you're not even aware of what transitive dependencies you're pulling in, what version they are and have no way to vet anything - everything is hidden behind a wall of magic.
Automatic dependency resolution however... Fantastic for experimentation, but that's a dealbreaker for production. Maybe it would be OK if it actually wrote the package-lock.json to the application directory, I'd have to think about that.
I think this framework hasn't been written with security in mind at all.
For instance, Rails has a public/ folder for files that are going to be served. And jekyll hides files by pattern-matching them.
Zero doesn't seem to have exclude folders by default. The solution would be to run Zero is a subfoler and require file in the parent folder which would act as the tree's root.
By this time it's already too late.
Some classes of bugs that would be otherwise tame due to the constraints (eg., file upload that might be able to only create new files in some part of the directory tree, or a buggy routine that lets you create arbitrary symlinks, or leftover VCS/CM files that happen to end in .js and are not filtered out by the router) now become the most powerful kind, remote code execution.
I could add `require('foo')` but I could also just require no third party code and have fun with the `process` module.