Live data from Hacker News

All Node.js servers are vulnerable to DoS

groups.google.com

31–37 of 37 posts

Re: All Node.js servers are vulnerable to DoS

#31
post #24

Earlier quoted context omitted.

I disagree. Node.js and client-side JavaScript should treat security issues differently because they face different risks. E.g. A DoS against client-side Javascript is not a big deal (because it might slow down a single browser, or even just a single tab within a browser). However, on the server side, a DoS could take down an entire service which is much more significant. Thus you could say that V8 is "secure" on the…

He's saying it's FUD because the headline is misleading, not because he's trying to downplay the security issue. You and grandparent are likely in agreement with respect to your comment. (The headline is misleading because the issue affects several major language runtimes, V8 included – yet only Node.js is mentioned.)

Thanks; upon re-reading the comment I see it now

Re: All Node.js servers are vulnerable to DoS

#32
post #26

Ryan Dahl commented on the thread, and it's being fixed in node. Nice to see assessment and responsiveness at the core of the project. I'm evaluating node.js as an application platform choice for a large public infrastructure project. One thing that concerns me is (my perception here) a lack of public hardening of the server that's yet to come. I've been around long enough to see that effect on PHP, Django, Rails, et…

A look at node's HTTP parsing code, 1500 lines of hand-coded and rather pretty C, makes it clear that Ryan Dahl cares a lot about HTTP in node doing the Right Thing. https://github.com/joyent/http-parser/blob/master/http_parse... (This is also very handy for people writing HTTP servers and clients in other languages, since it's independent of node, and really fast and feature-complete.)

I don't think Dahl takes credit for all of this code:

"Based on src/http/ngx_http_parse.c from NGINX copyright Igor Sysoev"

Re: All Node.js servers are vulnerable to DoS

#33
post #29

Earlier quoted context omitted.

I wonder if this is a bigger deal for Node because it's single-threaded? Just one malicious POST request could slow down the entire server, whereas other languages that spawn a process for each request could easily kill a process that's using 100% CPU, right?

you can just as easily spawn multiple node.js servers and kill off the unresponsive one's

yeah but you're encouraged to only spawn child processes for cpu-intensive tasks.

Re: All Node.js servers are vulnerable to DoS

#34
post #29

Earlier quoted context omitted.

you can just as easily spawn multiple node.js servers and kill off the unresponsive one's

yeah but you're encouraged to only spawn child processes for cpu-intensive tasks.

If you are using external processes (tools like gd's converters and so forth) yes. For code that is only running in node's environment it used to be that running a process or more per core (using something like nginx as a reverse proxy to tie them to one port) was considered the way to make better use of extra CPU resource.

There is even a cluster module built in now to remove the need for an extra external tool to manage the processes: http://nodejs.org/docs/latest/api/cluster.html (there are more fuller featured options available as extra modules, I'm not sure how they compare efficiency-wise with the in-built one). I'm guessing this isn't the way to go if the processes need to communicate, but I've not looked into it overly deeply yet (my experiments with node not having grown to the point of needing to take advantage of more than one core).

Re: All Node.js servers are vulnerable to DoS

#37
post #27

Not necessarily specific to node.js, but in general, instead of a standard webserver, use netcat, on multiple obscure ports, where each instance of netcat acts once and is discarded. http://en.wikipedia.org/wiki/Netcat

That plan sounds like half-assed voodoo, but it kind of resembles the approach that qmail uses for security, which is actually pretty neat: http://cr.yp.to/qmail/qmailsec-20071101.pdf

Thank you for the link, but my approach is neither "half-assed" nor "voodoo". I've used netcat, as described, for a small project, and it worked well. I'm about to do the same, for a big project, and I expect that it will again work well. Standard webservers are bloated. Speed, security and stability can be enhanced by distributing work across a system of one-shot processes. I take some inspiration from Jef Poskanzer's design decisions in thttpd.

http://acme.com/software/thttpd

http://en.wikipedia.org/wiki/Jef_Poskanzer

NOTE TO DOWNVOTERS: You shouldn't downvote a technical suggestion, no matter how strange, unless you are certain that it won't work.

Post reply on HN