Configure webpack to allow host requests inside docker containers

[jameshiebert]

[corviday]

This security feature was added in webpack 2.4.3 (released late April). An article explaining the issue is here: Webpack Dev Server Security Issues. Here's the issue that was addressed.

Webpack-dev-server wants to know, at startup, its host and the URL it will be accessed with. It will refuse requests to any other URL in order to prevent DNS rebinding attacks (the attacker pretends to be hosted on the same server as the defender in order to gain the special access normally reserved for processes on the same machine). Where proxies or containers are involved and the address webpack is accessed with isn't the obvious one it's expecting, this check rather complicates things.

Possible solutions:

1. Disable webpack's host check (set disableHostCheck=true). Normally disabling security features is a bad idea, but I don't think the test docker servers are even accessible outside PCIC, and our source code is pretty much the only thing in the docker containers and it's already 100% public, so I don't know what we'd lose even if a docker container was compromised, but we'd want a way to make sure it wasn't disabled for a production build.
2. Equivalent to the above, require an older version of webpack.
3. Hand-edit the webpack config in package.json every single time you want to build and run a docker with webpack-dev-server or climate explorer inside a docker and tell it what its public address will be. This is what we have to do now - it's a pitfall if you're not used to it, and still pretty forgettable if you are. Limits portability and reusability of docker images.
4. Edit the Dockerfile to do something like check hostname when the docker image is being built and automatically add [hostname].pcic.uvic.ca to webpack's config as the public-facing address, and probably print a message to screen telling the docker-building user it's doing this, in case they wanted to do something else. This limits the portability of climate explorer docker images between hosts, and production builds are unlikely to have their server's hostname in their URL, but it would make firing up a test docker a lot easier.
5. Switch to a different node.js bundler and server. Probably rather more more trouble than hand-editing webpack config every time you want to build a docker.

[jameshiebert]

our source code is pretty much the only thing in the docker containers and it's already 100% public

Yeah, we're using webpack to compile and server our code for efficiency, not for obfuscation. We really don't care if someone gets our source code from webpack.

Any tool that opens ports on your computer, even only on localhost, can potentially accessed from the internet.

Yeah... that's kind of what we're intending to do! One thing that we may want to consider is having a dev profile that has disableHostCheck=false, and then prod mode where disableHostCheck=true. The Dockerfile could set an environment variable or just sed the config file and disable the host check during the build process.

The only thing that might be of concern is from here:

worse, if webpack-dev-server's proxy feature [6] is being used, then this exposes any remote code execution vulnerabilities in the backend stack.

That sounds super sketchy. Would you be able to investigate that a bit more?

As an alternative, we could also just allow the server process to take an environment variable that specifies the correct host, and then run docker with that variable set.

[corviday]

The only thing that might be of concern is from here:

worse, if webpack-dev-server's proxy feature [6] is being used, then this exposes any remote code execution vulnerabilities in the backend stack.

I think the concern is that if webpack is acting as a proxy to another service, compromising webpack gives the attacker the ability to have webpack use its privileged access to forward arbitrary requests of the attacker's choosing to the other service too. Depending on what the second service is, this could be a larger vulnerability than just letting someone read your all JS code. It could give the attacker the ability to request whatever they want from your backend databases or write things into your databases or something.

We don't use webpack as a proxy to anything or give it access to anything beside the web frontend and development environment code, so I don't think this particular concern affects us at all. I'm going to talk to Matthew about it Wednesday or Thursday to double-check that conclusion.

[corviday]

Possibly a better option I've just learned about: webpack added the ability to list multiple expected hostnames. So I think we could put all the docker servers into the config file as allowable hostnames, and then should be able to run webpack in a container on any of them without trouble and move the containers around as needed, put images on our docker repository, etc, without disabling the security feature.

Described here: webpack/webpack-dev-server#899

That seems like the best solution to me, unless we don't want the names of the development docker servers to be publically visible in a config file on github.

[corviday]

Per conversation we just had, since we're not planning to use webpack dev server in production, and development instances aren't accessible outside PCIC, there's no reason not to just disable the host check.