Implications, fixes and more

Tobias Koppers

Follow

Apr 24, 2017 · 3 min read

TL;DR

• Ed Morley from Mozilla reported a security issue.
• I found some other security issues.
• These issues was fixed in
  webpack-dev-server@^2.4.3,
  webpack-dev-server@^1.16.4,
  webpack-dev-middleware@^1.10.2.
• Fixes are breaking changes for insecure configurations.
• Don’t use disableHostCheck or Access-Control-Allow-Origin: *

Disclaimer

I’m not a security expert so maybe some details are incorrect/inaccure.

This post is intended to explain the implications and create awareness.
So things are kept simple.

Issues

Issue #1: DNS Rebinding to access the webpack-dev-server

This issue was reported by Ed Morley from Mozilla. Here is the full report: https://github.com/webpack/webpack-dev-server/issues/887

DNS Rebinding: A DNS record to 127.0.0.1 allows a bad site to make requests to localhost and they are not considered as cross-origin by the browser. These requests allow to leak information from local services.

The attack uses DNS rebinding to access the webpack-dev-server. This assumes attacker knows the port of the dev-server and makes you open a malicious site while the dev-server is running.

Implication: The attacker is able to make any request to the webpack-dev-server and is able to read the response. This could leak your compiled source code and give the attacker access to your internal services when you are using the proxy feature to proxy internal services.

Fix: The webpack-dev-server needs to validate the Host header of the request to make sure request can only be made from the correct URL. This disallows DNS Rebinding. Note: Attackers can still make any request to the dev-server as always, but these requests are made according to the cross-origin policy.

For the fix the dev-server needs to know the Host/URL you are using to access the dev-server. By default we use the listening address (i. e. for--host my-computer --port 8080 the url must be http://my-computer:8080). If you provide a public URL the dev-server also accepts this one (i. e. --host 0.0.0.0 --public example.company.com). This should be the normal way to provide the url for the security check.

These is an option to disable the security check (disableHostCheck) but please don’t use it! If you really want to, please make sure to fully understand this security problem.

Issue #2: webpack-dev-server sockjs server accept all connections

Everybody is allowed to make a connection to the sockjs server of the dev-server.

Implication: The attacker gets access to the webpack stats, which contains your source code.

Fix: Same as above. Validate Host header for incoming connections.

Issue #3: webpack-dev-middleware sends Access-Control-Allow-Origin: *

Everybody is allowed to make requests to the webpack assets for the webpack-dev-server.

Implication: This leaks the compiled source code.

Fix: Remove the default header in webpack-dev-middleware. User should manually set Access-Control-Allow-Origin with the correct host.

Don’t set Access-Control-Allow-Origin: *, because this opens the attack vector again.

Releasing these breaking changes as patch version

Yeah, I know this is weird and against semver, but I’ve chosen to publish these changes as patch version. This maybe breaks your dev-tools.

I went this road, because I know if these fixes were published as new major version, the majority of users won’t upgrade to the new version and would be affected by theses security issues.

I know this will annoy some users, because their development setups are broken now, but I take the risk to protect them. Maybe they read the release notes when it breaks.

I think a secure setup is worth breaking some setups… It’s only the development stuff…

If your setup is broken pass --public xxx:yyy resp. public: "xxx:yyy" and/or headers: { "Access-Control-Allow-Origin": "xxx:yyy" } as devServer options (xxx: host, yyy: port).

Conclusion

Before these issues I considered a development tool as not security critical. So I didn’t care much about security. I was wrong. Any tool that opens ports on your computer, even only on localhost, can potentially accessed from the internet.

So make sure tools that open ports are protected against DNS Rebinding and CSRF. I guess more devtools are affected here…

Notes

• Some DNS-Servers filter DNS records to local IPs.
• Consider all passwords/keys in your “content base” (which defaults to the current directory) as leaked.