-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--host 0.0.0.0 Not working #882
Comments
I ran in to "Invalid Host header" as well today after upgrading to webpack-dev-server 2.4.3. My specific instance involved some shenanigans behind nginx reverse proxy to a another ssh tunneled reverse proxy (handles my vhosts for any dev projects with out the man telling me I can't serve up specific ports)... so after spending a short time actually looking over my config/headers, I just rolled ack to 2.4.2 and it fixed it right up with no other changes. Doubt that is any news/that helpful, but thought I'd chime in that it seems isolated to 2.4.3/went away when I downgraded. Oh, and I also using 0.0.0.0 specifically for my host settings. |
https://github.com/webpack/webpack-dev-server/releases/tag/v2.4.3 best add |
btw. it's intended to not work when just using |
behind proxy you can use the |
I should have pulled my head out of my ass and read the v2.4.3 release. Right on, appreciate the attention to the potential vulnerability, and I dig the disableHostCheck ability being put right in even more. Thanks =) |
@sokra thx for reply. |
@hooraygith I added it and released a new version. Try to update. |
hi @sokra . Thanks for fixing the security issue. It seems like the disable host check option is not available on CLI. Is it possible to get that added? I'm happy to make a PR if that's an ok change. also, in general I think these changes could use more documentation. I'm pretty confused and not totally sure I need the disable option, but I haven't found a good alternative yet from the release notes or the issues that are filed because I need to hit my local dev server from a tablet. Also, I have custom hosts in my etc/hosts which my app uses to determine things. like foo-local.com vs bar-local.com, both of which are aliased to 127.0.0.1 Either way, I think it'd be good to expose the disable option in the CLI for people who are using it. |
@sokra I understand the security fix and am grateful as always for all the work done on webpack but I would like to know why this was included in a patch and not a major version. Presumably this security risk has been present for quite some time and as such I don't see the urgency. I assume that webpack tries to follow semver which is pretty clear that almost any breaking change should be a major version bump, especially if what you're versioning has a huge audience, which certainly webpack does. A major patch bump is also much better for communicating to users that there are breaking changes which would have saved at least a few people on this thread and presumably more elsewhere hours of lost work. As it is, I'm still trying to figure out how to make this change work with my team's somewhat unique configuration (that's actually somewhat similar to @bdwain's). My guess is that I'll end up rolling back the version but that certainly can't be a permanent solution. While we could have avoided this by locking down the versions in our package.json we are still in the development and as such haven't done that yet but if packages followed semver it shouldn't be too much of a problem. |
@sokra, perhaps in addition to whitelisting localhost, if the Host header contains any IP, then the request can be accepted? If the request was made to a specific IP (and not a DNS rebound malicious domain), then this cannot have been an attack as made via DNS rebinding. The only concern with this approach would be if a domain could be registered that matched the regex for an IP. However RFC 3696 section 2 seems to suggest that the top level domain can never contain all numeric characters, so a hostname can never overlap with an IPv4 IP. |
@edmorley i also have another use case that seems to have been broken by this. Not sure if the current implementation has a solution for this. For development, i have a few aliases to 127.0.0.1 in my etc/hosts file. like 127.0.0.1 foo-local.com bar-local.com and my app uses the url format to determine certain things about how it behaves. I noticed i could no longer hit foo-local.com:PORT after this change though. |
I've filed a retrospective GitHub issue with the original private disclosure email wording, which should hopefully make things a bit clearer: #887 - happy to answer any additional questions.
For this case, I think we need a way to whitelist multiple hostnames, similar to Django's |
@bdwain That's no problem, you just have to pass the public name of the dev-server via |
Currently it's not possible to have multiple host, but feel free to send a PR. |
@sokra How to use |
So what do you do if you're using webpack-dev-server from node script instead of CLI? --public is only available on CLI from what I gather? EDIT: public is available from node as well. Example: const server = new WebpackDevServer(compiler, {
public: '<you public ip>'
}); |
i feel like every option should be available from node (except what is impossible, like maybe some console output options) and the CLI options should be a subset of that |
As a followup to the post by @phairoh. I understand this was considered a security flaw, however this should have been handled more gracefully. There are entirely valid cases where developers will want to use multiple hostnames. A more graceful way of handling this would have been one of the following options: Option 1Default This has a few benefits:
Option 2Wait for a major version bump, then add the security fix / feature. This option is less than ideal because the user has to wait for a major version bump for his fix to be available. Obviously this is a fairly simple fix, but it concerns me because rather then following |
Semver concerns aside, there is an error in the implementation that is addressed by #888 |
I'm trying to understand the problem this patch fixes. Does it make sense to have this option enabled on local servers? What if we don't use |
See #882 (comment) |
we need to explicitly configure webpack-dev-server with hostname port ref webpack/webpack-dev-server#882 (comment)
I am developing on Cloud9. Without this flag set to true, the page just returned 'Invalid Host header'. More discussion of this issue here: webpack/webpack-dev-server#882
Am using Angular CLI: 6.2.2 , Node: 8.11.1 and OS: darwin x64 This is my etc hosts 127.0.0.1 dinesh.mysocialapi.com This is my comment node_modules/@angular/cli/bin/ng serve --host 0.0.0.0 --disableHostCheck true am getting this error how to fix ? Loading failed for the with source “http://dinesh.mysocialapi.com/vendor.js”. dinesh.mysocialapi.com:34 |
confusing problem:
it worked
it doesn't work, still |
As per this [github issue](webpack/webpack-dev-server#882), `behind proxy you can use the disableHostCheck: true flag.`
It took me a lot of combinations to figure this one out. So if you want to develop locally and test with a remote computer/cell phone, this seems to do the trick:
|
For some reason this worked for me... webpack-dev-server --host=0.0.0.0 --disable-host-check --useLocalIp |
The docker-compose set worked for me. docker-compose.ymlversion: '3'
services:
nginx:
image: nginx:1-alpine
volumes:
- ./docker-nginx-app.conf:/etc/nginx/conf.d/default.conf
ports:
- "80:80"
links:
- app
app:
image: node:12-alpine
volumes:
- ./:/app
working_dir: /app
working_dir: /app
command:
- /bin/sh
- -c
- |
npm i
npm run dev docker-nginx-app.conf
webpack.config.dev.jsconst webpack = require('webpack')
const merge = require('webpack-merge')
const webpackBaseConfig = require('./webpack.config.base.js')
const webpackConfig = merge(webpackBaseConfig, {
mode: process.env.NODE_ENV,
devServer: {
...
host: '0.0.0.0',
port: 80,
disableHostCheck: true,
...
},
...
})
module.exports = webpackConfig |
Hi, guys! The reason of this is that I suggest to add a separate option ( But since we need to proceed to workaround this issue in our case I had to apply a temporary and very dirty hack in our webpack configuration file (use a getter and check if the stack trace contains line with let stackStopLines = [];
if (!isBuildMode) {
const webpackDevServerSource = fs.readFileSync(path.resolve(__dirname, 'node_modules/.bin/webpack-dev-server'));
stackStopLines = webpackDevServerSource.toString().split('\n').reduce((accum, lineText, lineNumber) => {
if (lineText.includes('server.listen(')) {
accum.push(`webpack-dev-server.js:${lineNumber + 1}`);
}
return accum;
}, []);
}
module.exports = {
// ...
devServer: {
// ...
disableHostCheck: true,
get host() {
// see comment above near definition of `stackStopLines` of what we are doing here
const stack = new Error('').stack;
if (stackStopLines.some(stopLine => stack.includes(stopLine))) {
return '0.0.0.0';
}
return server.host;
}, |
@olegstepura Can you make a separate issue for this? I'm having a problem with websocket listeners on ngrok It'd be nice to see a potential PR for it as well Possibly related? #1418 |
we need to explicitly configure webpack-dev-server with hostname port ref webpack/webpack-dev-server#882 (comment)
we need to explicitly configure webpack-dev-server with hostname port ref webpack/webpack-dev-server#882 (comment)
I run the webpack-dev-server with params
--host 0.0.0.0
, then visit the page through my ip, the page shows "Invalid Host header".I look into the code, it seems the
Server.prototype.checkHost
in filelib/Server.js
is wrong, it don't deal with the params of--host 0.0.0.0
The text was updated successfully, but these errors were encountered: