1. 5
  1. 5

    Where’s the “it doesn’t have to be this way” part? Cause it doesn’t have to be this way.

    1. 2

      Ask them to run your code

      The code works and is trivial

      Something a newbie really might write

      Oh, but it has an NPM dependency whose subdependency pwns them

      NPM: the Node Pwnage Maker? To be fair to Node, this can happen in any language with a package manager. It’s just a more likely scenario with NPM, and maybe Cargo. How long before we collectively learn the lesson that deep dependency trees including lots of microdependencies are a terrible idea?

      1. 9

        Never, because it’s not such easy to answer and to an amount a red herring. Microdependencies aren’t in and by themselves bad. E.g. I’ve heard an argument by an assessor for safety critical software that they would love if they got functions as packages (because the package is the scope of assessment). Instead, they e.g. have math functions that come in libraries with 200 and then need to make an argument that they are only using 2 of those and the rest is out of scope for checking.

        The problem they pointed out is that they want to have those functions acquired and managed from one vendor. The problem in the node world is the acceptance to work with essentially 200 vendors, not the willingness to depend on 200 packages.

      2. 1

        I was confused that this isn’t the substack version of Patrick Wyatts blog Code of Honor. (https://www.codeofhonor.com/blog/) I had secretly hoped for a war story where someone would hack StarCraft or something with such attacks.

        1. 1

          Yup, I’ve learned it the hard way that you have to be systematic about it. You can’t ever cut corners for “oh, it’s just a simple string”, “it’s trusted data”, etc. It may feel silly to escape benign values like alphanumeric usernames or dates or numbers, but keeping track of what is de-facto safe and maybe not always safe (now or in the future) is way harder and riskier than to just escape everything as it needs to be, all the time.

          Every context (HTML, Markdown, regex, SQL, URL, e-mail header, cookie value) needs its form of escaping, and the only way to prevail is to use tools that escape by default.

          I have also got “vulnerability” reports about echoing user’s string back on the page with claims it could be used for spam or phishing, but I think that is a separate problem, orthogonal to preventing code injection. If you allow XSS people won’t bother with phishing, but that’s not how it’s supposed to work :)

          (BTW: I’m getting obnoxious signup modal on this article)