4 ms·

Wow I've only played with js a few days and I can interpret that pretty easily, so this seems pretty simple.

nkrisc 11y ago
The JS is inconsequential, really. Just making the correct HTTP request, even by typing it in your browser, is the exploit.
- jondubois 11y ago
  Lol. Yes, funny how people love to throw JavaScript/Node.js into the mix. It's like "They're using JS; how could it possibly be secure?!". That's actually highly ironic considering that JS is so far the only language that is secure enough to run universally in every browser on the planet. People can't get around the fact that JS has evolved a LOT since it was launched and it still suffers a bad name.
  - detaro 11y ago
    Where here has JS been given a bad name? I didn't get that vibe.
    - dopamean 11y ago
      One of those JS devs who gets really defensive when people are talking about JS and not screaming about how awesome it is.
      - taurath 11y ago
        Most of my experience saying you mostly do javascript in a room full of other coders is that they'll all scream at you to use a "better" language (on HN too).
  - smt88 11y ago
    You misunderstand why people think JS is insecure. The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc. The result is that your server-side JS is more prone to different kinds of security issues. On the client side, in the browser, JS is sandboxed, so the language is almost irrelevant. If JS can't actually access the underlying system, no number of bugs make the code insecure.
    - sangnoir 11y ago
      > The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc. All those are not a factor in this instance. It seems to me it's a result of calling exec() on unscrubbed user input, and this can be done in any language.
      - smt88 11y ago
        I agree. I was responding to a tangential comment, rather than the root post.
  - johnmaguire2013 11y ago
    Languages aren't inherently secure or insecure. In any case, nobody was accusing Node.js of being insecure here. JS is not "the only language that is secure enough to run universally in every browser on the planet." In fact, JS has had many, many security issues in browsers. Rather, JS is the only language nearly every browser on the planet has implemented in the browser (hopefully sandboxed!)
    - gragas 11y ago
      >Languages aren't inherently secure or insecure. This is just not true.
      - kcbanner 11y ago
        Explain?
        smt88 11y ago
        A language's specification can forbid you from doing things that you probably didn't intend to do. Rust is an entire language intended to be safer by design (as opposed to C, which is the cause of a lot of secure issues). You can write less safe code in Rust, but you have to tell the compiler that you're doing it on purpose. It's also much, much easier to introduce bugs in certain languages because of the way they handle errors, or because the syntax is confusing and ambiguous. Even permissive handling of boolean logic, like what you get in PHP/JavaScript ("0" == true, for example) can result in massive security holes.
        gragas 11y ago
        As another example, Go's := makes it much harder to do things you aren't intending to do.
  - nkrisc 11y ago
    Though it sounds like you're agreeing with me, that is not at all what I was saying.
    - jondubois 11y ago
      Yes, I was just adding to your comment. Just pointing out that there is a pattern of people blaming JS even though it's not related at all to the problem. The same vulnerability would have existed regardless of whether the code was written in Python, Go, C, Erlang, Haskell, PHP or Scala... This is a logic error - Not something that a compiler would pick up.
      - DonaldFoss 11y ago
        This is a massive design flaw, not a logic error. While I applaud the use of API's for modular design and communication, this is the wrong place for it.
      - PeCaN 11y ago
        In Haskell or Scala you could quite easily structure the code such that concatenating strings from different sources like that would be a compile error.

The JS is inconsequential, really. Just making the correct HTTP request, even by typing it in your browser, is the exploit.

jondubois 11y ago
Lol. Yes, funny how people love to throw JavaScript/Node.js into the mix. It's like "They're using JS; how could it possibly be secure?!". That's actually highly ironic considering that JS is so far the only language that is secure enough to run universally in every browser on the planet. People can't get around the fact that JS has evolved a LOT since it was launched and it still suffers a bad name.
- detaro 11y ago
  Where here has JS been given a bad name? I didn't get that vibe.
  - dopamean 11y ago
    One of those JS devs who gets really defensive when people are talking about JS and not screaming about how awesome it is.
    - taurath 11y ago
      Most of my experience saying you mostly do javascript in a room full of other coders is that they'll all scream at you to use a "better" language (on HN too).
- smt88 11y ago
  You misunderstand why people think JS is insecure. The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc. The result is that your server-side JS is more prone to different kinds of security issues. On the client side, in the browser, JS is sandboxed, so the language is almost irrelevant. If JS can't actually access the underlying system, no number of bugs make the code insecure.
  - sangnoir 11y ago
    > The problem is that JS is really easy to make mistakes in because of silent errors, dynamic typing, type coercion, etc. All those are not a factor in this instance. It seems to me it's a result of calling exec() on unscrubbed user input, and this can be done in any language.
    - smt88 11y ago
      I agree. I was responding to a tangential comment, rather than the root post.
- johnmaguire2013 11y ago
  Languages aren't inherently secure or insecure. In any case, nobody was accusing Node.js of being insecure here. JS is not "the only language that is secure enough to run universally in every browser on the planet." In fact, JS has had many, many security issues in browsers. Rather, JS is the only language nearly every browser on the planet has implemented in the browser (hopefully sandboxed!)
  - gragas 11y ago
    >Languages aren't inherently secure or insecure. This is just not true.
    - kcbanner 11y ago
      Explain?
      - smt88 11y ago
        A language's specification can forbid you from doing things that you probably didn't intend to do. Rust is an entire language intended to be safer by design (as opposed to C, which is the cause of a lot of secure issues). You can write less safe code in Rust, but you have to tell the compiler that you're doing it on purpose. It's also much, much easier to introduce bugs in certain languages because of the way they handle errors, or because the syntax is confusing and ambiguous. Even permissive handling of boolean logic, like what you get in PHP/JavaScript ("0" == true, for example) can result in massive security holes.
        gragas 11y ago
        As another example, Go's := makes it much harder to do things you aren't intending to do.
- nkrisc 11y ago
  Though it sounds like you're agreeing with me, that is not at all what I was saying.
  - jondubois 11y ago
    Yes, I was just adding to your comment. Just pointing out that there is a pattern of people blaming JS even though it's not related at all to the problem. The same vulnerability would have existed regardless of whether the code was written in Python, Go, C, Erlang, Haskell, PHP or Scala... This is a logic error - Not something that a compiler would pick up.
    - DonaldFoss 11y ago
      This is a massive design flaw, not a logic error. While I applaud the use of API's for modular design and communication, this is the wrong place for it.
    - PeCaN 11y ago
      In Haskell or Scala you could quite easily structure the code such that concatenating strings from different sources like that would be a compile error.