21–30 of 37 posts
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.
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.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.
Earlier quoted context omitted.
That's the spirit of those "penis enlargement" ads. To be pedantic, there are hardcore limits on stuff, that we can not improve upon. We cannot sort a list of n items in less than O(n) for example.
O(n) only applies to non-comparison based sorts; for comparison based sorts that might be used on "items" the lower bound is indeed O(n.log n)
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…
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…
(The headline is misleading because the issue affects several major language runtimes, V8 included – yet only Node.js is mentioned.)
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…
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…
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.)
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
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…
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…
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?