Live data from Hacker News

Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

zeroserver.io

61–70 of 256 posts

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#61
post #58

Earlier quoted context omitted.

> If security is a concern At the risk of being presumptuous... When is security ever not a concern?

Student projects

When you're learning, you need to also learn security implications of what you're writing. Insecure projects should never be allowed to pass.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#62

Minimalism has a cost. http://npm.broofa.com/?q=zero

Standing on the shoulders of giants :) You will eventually be adding all those packages when you develop a production-grade React / Node app anyway.

Perhaps this should be done gradually and thoughtfully, rather than pulling half the internet into each minimalist app out there.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#63
post #26

> File-system Based Routing: If your code resides in ./api/login.js it's exposed at /api/login" rel="nofollow">http:// /api/login . Inspired by good ol' PHP days. > 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 c…

So if an attacker already has access to your filesystem to modify your files, they can install stuff?

By this time it's already too late.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#64
post #63
post #26

> File-system Based Routing: If your code resides in ./api/login.js it's exposed at /api/login" rel="nofollow">http:// /api/login . Inspired by good ol' PHP days. > 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 c…

So if an attacker already has access to your filesystem to modify your files, they can install stuff? By this time it's already too late.

There's different levels of 'filesystem access' vulnerabilities.

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.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#65
post #44

Earlier quoted context omitted.

If security is a concern, this is probably a bad choice; this doesn't seem to be advertised as a bulletproof security solution to anything, rather a utility for small little one-off apps that might need _some_ backend functionality. Once you start adding features like file-uploading, youre obviously gonna want to pick a more robust option

> If security is a concern At the risk of being presumptuous... When is security ever not a concern?

> When is security ever not a concern?

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.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#66
Wow, I love that people can wrap express and many of its components and end with something so different from its foundation. That being said, this level of "batteries included" approach has a cost.

In this example, it is the complexity of this file[1] and the fact that if you were to write this as a single express middleware you could probably write it in less than 20 lines.

Guess this is just not my cup of tea?

[1] https://github.com/remoteinterview/zero/blob/master/packages...

Edit: also looks like the author decided to wrap their own multi process model? https://github.com/remoteinterview/zero/blob/master/packages...

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#68
post #26

> File-system Based Routing: If your code resides in ./api/login.js it's exposed at /api/login" rel="nofollow">http:// /api/login . Inspired by good ol' PHP days. > 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 c…

I don't disagree that this doesn't seem necessarily secure and the auto dependency resolution is a bad idea for other reasons in my opinion, but I don't see the security aspect of it.

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.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#69

Maybe a silly question, but is there anything one needs to consider before deploying this to, let's say, Heroku?

As others have pointed out, make sure to mark files that are not supposed to be exposed to the client by prefixing them with a underscore, otherwise you'll have a bit of a security issue. Otherwise, you're good to go.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#70
post #65

Earlier quoted context omitted.

> If security is a concern At the risk of being presumptuous... When is security ever not a concern?

> When is security ever not a concern? 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.

I agree with GP. Security is always a concern. I too used to think as long as it's behind the firewall, or a local only exploit, it doesn't matter. But it always matters. Small apps become big apps. Small user bases large ones. Someone gets onto your internal network and then your small userbase app for trusted employees becomes a jumping off point, etc.

Your sort of thinking is how you end up with Yahoo levels of account leaks.

Security always matters.

Post reply on HN