Hacker News Reader

Comment by sh1mmer | Hacker News Reader

This title is a great piece of FUD. Anyone paying a little more attention would have seen the original paper (http://www.nruns.com/_downloads/advisory28122011.pdf) which states: "PHP 5, Java, ASP.NET as well as v8 are fully vulnerable to this issue and PHP 4, Python and Ruby are partially vulnerable".

That's not to say that Node doesn't need to fix this (and it seems like Bert from the core team is) but it's not a Node specific issue.

View on HN

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 client side but "insecure" on the server side because of the different risk assessments. It is poor security practice to take software designed for one security environment and assume it will be secure in other environments. If Node.js wants to have a secure system they will need to take these security issues into consideration and harden their system appropriately.

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

Ruby 1.9, the current production version of Ruby, is not vulnerable. Rails 4, the next version of Rails, will require Ruby 1.9.

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.

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).

Reply on news.ycombinator.com