1. 13

Hi,

At my current client I’ve been doing more and more security related tasks such as audits on external software. Currently the type of software I audit are WordPress plugins. I have more than 15yrs of experience with WordPress and in the past I could fairly easily assess a WordPress plugin’s potential security impact(s). Nowadays not so much due to the seemingly increased usage of npm packages included with these plugins.

Often these plugins do not include a package.json, package-lock.json nor are the javascript files readable (bundled & minified). This makes using npm audit near impossible. Good for production, less for audits.

Sometimes I can grab development files such as package.json, package-lock.json from a public repo, but in the case of so-called ‘premium’ plugins a public repo is usually absent.

So my question is: How do you (security) audit external software depending on npm packages?

PS: I’ve asked this question also on Hacker News. I did not see any rules about cross-posting so if this is not ok, please let me know and I won’t cross-post in the future anymore.

  1.  

  2. 5

    I’ve had the same problem, so I’ve been working on a side project to help with this: xray.computer. It lets you view the published code of any npm package, and supports auto-formatting with Prettier for minified code. It’s not a panacea (sometimes, the published code is still unreadable, even when formatted) but it helps.

    I also like to look up packages on Snyk Advisor to ensure that they get timely updates when vulnerabilities are found.

    (Hopefully it’s okay to promote your own side projects here; please let me know if not.)

    1. 3

      It is absolutely acceptable to mention your own side projects here, so long as it’s not spammy. We have the “show” tag for a reason. :)

      1. 1

        Thanks for sharing your side-project! It is helpful to see the differences between versions. I can use it to see if a security issue was indeed solved between versions of a package. I’m also using Snyk to get an idea of certain packages.

        However, I think my problem is a bit more complex: a WordPress plugin may contain hundreds of interdependent npm packages all neatly bundled and minified. Without access to a package.json or package-lock.json it is quite hard to find out which individual packages have been used. Quite often there is also no public repo available of the development files.

        To give an example of my process thus far:

        Someone in my team wants to see if we can use plugin X. I’m downloading the plugin to have a look at the code. Luckily this plugin has included a non-minified version of the js file. I can derive the use of npm packages from this file. Using Snyk I have a look at the first package mentioned. It’s axios. The included version is vulnerable (high & medium severity) and has been for almost a year (Note: the last version of the plugin is 3 months old and does not exclude this vulnerable version in it’s package.json which I found in a Github repo later on).

        Since I have no package.json nor package-lock.json (all I have is the distributed build) I can’t easily update the npm package. I have no clue as to how this package relates to the other packages and how their version might depend on each other. Even if I would update the package, all other users of this plugin are still vulnerable. I contacted the plugin author. He tells me he will update the plugin as soon as possible. The plugin is (as of today) still not updated & has not released a new version. In the meantime there have been two new versions of the axios package released.

        Every user of plugin X is still vulnerable to the issues mentioned on Snyk, but is this a real problem in this specific WordPress plugin context? I’m not sure how to interpret the high & medium severity in the context of this plugin. How exploitable are these issues & what is the impact of the exploits in the context of this plugin? Do I need to be a logged in user? Is this something which can be triggered by any visitor? What am I able to do when I can exploit these vulnerabilities? I can only try to find answers to these questions if I’m willing to invest a lot more time into this, which more or less beats the purpose of using a ‘ready-made’ WordPress plugin. And this is just one package of multiple npm packages used in this plugin. Packages which also have their own dependencies as well….

        At this moment I’m wondering if any WordPress plugin using npm packages can be trusted at all.

        ps: The way the npm ecosystem is structured is, in my view at least, problematic. Often packages are not like libraries as I’d expect, but look more like a function call or method call. I’d prefer to write these short pieces of code myself instead of depending on external code which also includes extra risks. The very rapid release schedules makes it even harder to trust external software (like a WordPress plugin) using npm packages as it seems they cannot keep up with it.

        I’m sorry if this seems like a npm rant, but I’m seriously looking for methods on how to deal with these issues so we can use external software (like WordPress plugins) built with npm packages.

        1. 3

          I think it’s perfectly reasonable to say no to this plugin.

          A WordPress plugin may contain hundreds of interdependent npm packages all neatly bundled and minified. Without access to a package.json or package-lock.json it is quite hard to find out which individual packages have been used. Quite often there is also no public repo available of the development files… At this moment I’m wondering if any WordPress plugin using npm packages can be trusted at all.

          I’d be pretty skeptical of any proprietary software that has npm dependencies but doesn’t include its package files. Just taking woocommerce (one of the more popular plugins) for example, they do include their package files in their source code. That ought to be the norm. When you have access to the package files, you can run the following to automatically install patches to vulnerable dependencies and subdependencies.

          npm audit fix
          

          Without the package files, the plugin developer left you up a creek.

          The included version [of axios] is vulnerable (high & medium severity) and has been for almost a year… I’m not sure how to interpret the high & medium severity in the context of this plugin. How exploitable are these issues & what is the impact of the exploits in the context of this plugin?

          It really depends on the context. Some subdependencies are only used in the development or build of the dependency. If the vulnerability assumes the subdependency is running in a public node server, it’s probably not relevant to you. The hard part is knowing the difference. Take this vulnerability in glob-parent for example. I see it a lot in single page apps that have a webpack dev server. It’s hard to imagine how a DoS vulnerability is relevant when the only place the code is going to be run is your local development environment. In your case, it’s worth asking, is the axios vulnerability in the HTTP client or the server? If the vulnerability is just in the server and you’re not running a node server, you might be able to ignore it.

          The way the npm ecosystem is structured is, in my view at least, problematic. Often packages are not like libraries as I’d expect, but look more like a function call or method call. I’d prefer to write these short pieces of code myself instead of depending on external code which also includes extra risks. The very rapid release schedules makes it even harder to trust external software (like a WordPress plugin) using npm packages as it seems they cannot keep up with it.

          I agree that npm is problematic, but I have a slightly different take on it. There was a time when it was popular to mock projects like Bower for keeping front-end dependencies separate from node.js dependencies. The thinking was, why use two package managers when there’s one perfectly decent one? As it turns out, security vulnerabilities are impossible to assess without knowing in what environment the code is going to be run. I’m not suggesting we all go back to using Bower, but it would be nice if npm and its auditing tools would better distinguish between back-end, front-end, and build dependencies. As it is now, most npm users are being blasted with vulnerability warnings that probably aren’t relevant to what they’re doing.

          1. 1

            I’d be pretty skeptical of any proprietary software that has npm dependencies but doesn’t include its package files.

            I agree. I think this will be one of the main ‘rules’ for deciding if we want to use a particular WordPress plugin. Without the package.json or package-lock.json and npm audit it is near impossible to audit or update (fork) a plugin

            It really depends on the context. Some subdependencies are only used in the development or build of the dependency.

            You’ve hit the nail right on the head! And that’s what makes it hard to determine the impact: context.

            As far as I can tell, determining context can only be done with (extensive) knowledge on how the npm package has been implemented in the WordPress plugin. It requires knowledge of the WordPress plugin, WordPress, the specific npm package, its dependencies and how all these relate to each other. Just like you said with the axios package.

            Creating this context thus requires quite some time & skills, which would be fine if we would deal with just a few npm packages. However due to npm’s nature we usually have to deal with way more interdependent packages, which makes manually creating context near impossible. So even though there’s npm audit we’re still left with how to determine the context of the vulnerabilities found by npm audit. And for this I have yet to find a solution.

            PS: npm audit fix is in my view not the solution to solve this. It just hides the problems a bit better ;)

      2. 2

        At the scale of source code you mention, I’d reassess what risks and threats you have in mind.

        First of all, I don’t think it’s possible to manually audit at the scale you mention. Static Analysis might be interesting but you also said it’s minified, which will probably defeat most if not all automatic source code analysis. If the code wasn’t minified I’d start with a regex search just to get a feel for code quality and common (anti)patterns. I’m also working on an eslint plugin to detect and prevent typical XSS sinks (innerHTML and friends) called eslint-plugin-no-unsanitized.

        If this is all frontend code (WordPress is PHP so the JS in a plugin is not part of the backend. Correct?), you might want to look at mitigation strategies instead: The only (the main?) risk in frontend JS code is XSS. Maybe it’s worthwhile to experiment with CSP. I’ll admit it’s really hard to do for existing websites and can be a really long process of trial and error.

        1. 2

          WordPress nowadays uses a REST API to talk with the “new” editor called Gutenberg which is built upon React. The use of npm packages therefor might be more used in the wp-admin (backend) than in the front-end actually. For now at least. I’d expect the usage of npm packages in WordPress plugins continue to grow and perhaps even take a larger responsibility in theme (frontend) rendering as well.

          I agree that the main risk probably is unauthenticated users or visitors of a particular website. However there’s also a few where we don’t know all the authenticated users so there is also an internal risk (although I’d assume it to be low) of “adversarial” authenticated users.

          1. 1

            Ah well. That’ll include csrf and role-specific issues which might make stuff even more challenging. Wish I had more ideas at this point.