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

Closed
hooraygith opened this Issue Apr 22, 2017 · 56 comments

Comments

Projects
None yet
@hooraygith

hooraygith commented Apr 22, 2017

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 file lib/Server.js is wrong, it don't deal with the params of --host 0.0.0.0

@fielding

This comment has been minimized.

Show comment
Hide comment
@fielding

fielding Apr 23, 2017

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.

fielding commented Apr 23, 2017

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.

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 23, 2017

Member

https://github.com/webpack/webpack-dev-server/releases/tag/v2.4.3

best add --public your-host:8080 to fix it.

Member

sokra commented Apr 23, 2017

https://github.com/webpack/webpack-dev-server/releases/tag/v2.4.3

best add --public your-host:8080 to fix it.

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 23, 2017

Member

btw. it's intended to not work when just using --host 0.0.0.0. This is a security risk.

Member

sokra commented Apr 23, 2017

btw. it's intended to not work when just using --host 0.0.0.0. This is a security risk.

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 23, 2017

Member

behind proxy you can use the disableHostCheck: true flag.

Member

sokra commented Apr 23, 2017

behind proxy you can use the disableHostCheck: true flag.

@fielding

This comment has been minimized.

Show comment
Hide comment
@fielding

fielding Apr 23, 2017

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 =)

fielding commented Apr 23, 2017

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 =)

@hooraygith

This comment has been minimized.

Show comment
Hide comment
@hooraygith

hooraygith Apr 23, 2017

@sokra thx for reply.
I tried disableHostCheck,and there is a problem that disableHostCheck not in the lib/optionsSchema.json

hooraygith commented Apr 23, 2017

@sokra thx for reply.
I tried disableHostCheck,and there is a problem that disableHostCheck not in the lib/optionsSchema.json

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 24, 2017

Member

@hooraygith I added it and released a new version. Try to update.

Member

sokra commented Apr 24, 2017

@hooraygith I added it and released a new version. Try to update.

@bdwain

This comment has been minimized.

Show comment
Hide comment
@bdwain

bdwain Apr 24, 2017

Contributor

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.

Contributor

bdwain commented Apr 24, 2017

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.

@phairoh

This comment has been minimized.

Show comment
Hide comment
@phairoh

phairoh Apr 24, 2017

Contributor

@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.

Contributor

phairoh commented Apr 24, 2017

@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.

@edmorley

This comment has been minimized.

Show comment
Hide comment
@edmorley

edmorley Apr 24, 2017

@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 commented Apr 24, 2017

@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.

@bdwain

This comment has been minimized.

Show comment
Hide comment
@bdwain

bdwain Apr 24, 2017

Contributor

@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.

Contributor

bdwain commented Apr 24, 2017

@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.

@edmorley

This comment has been minimized.

Show comment
Hide comment
@edmorley

edmorley Apr 24, 2017

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 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

For this case, I think we need a way to whitelist multiple hostnames, similar to Django's ALLOWED_HOSTS setting:
https://docs.djangoproject.com/en/1.11/ref/settings/#allowed-hosts

edmorley commented Apr 24, 2017

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 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

For this case, I think we need a way to whitelist multiple hostnames, similar to Django's ALLOWED_HOSTS setting:
https://docs.djangoproject.com/en/1.11/ref/settings/#allowed-hosts

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 24, 2017

Member

127.0.0.1 foo-local.com bar-local.com

@bdwain That's no problem, you just have to pass the public name of the dev-server via --public bar-local.com:8080.

Member

sokra commented Apr 24, 2017

127.0.0.1 foo-local.com bar-local.com

@bdwain That's no problem, you just have to pass the public name of the dev-server via --public bar-local.com:8080.

@bdwain

This comment has been minimized.

Show comment
Hide comment
@bdwain

bdwain Apr 24, 2017

Contributor

@sokra thanks that is good to know. Would I have to set the --host option also? Or would the default be ok?

Also, is it possible to have more than one host allowed currently? Or would that require something like ALLOWED_HOSTS that @edmorley mentioned?

Contributor

bdwain commented Apr 24, 2017

@sokra thanks that is good to know. Would I have to set the --host option also? Or would the default be ok?

Also, is it possible to have more than one host allowed currently? Or would that require something like ALLOWED_HOSTS that @edmorley mentioned?

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 24, 2017

Member

Currently it's not possible to have multiple host, but feel free to send a PR.

Member

sokra commented Apr 24, 2017

Currently it's not possible to have multiple host, but feel free to send a PR.

@rwu823

This comment has been minimized.

Show comment
Hide comment
@rwu823

rwu823 Apr 25, 2017

@sokra How to use disableHostCheck option from webpack-dev-server cli?

rwu823 commented Apr 25, 2017

@sokra How to use disableHostCheck option from webpack-dev-server cli?

@ekulabuhov

This comment has been minimized.

Show comment
Hide comment
@ekulabuhov

ekulabuhov Apr 25, 2017

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>'
});

ekulabuhov commented Apr 25, 2017

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>'
});
@bdwain

This comment has been minimized.

Show comment
Hide comment
@bdwain

bdwain Apr 25, 2017

Contributor

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

Contributor

bdwain commented Apr 25, 2017

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

@nick-woodward

This comment has been minimized.

Show comment
Hide comment
@nick-woodward

nick-woodward Apr 25, 2017

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.
My own example being we have multiple companies that have different logos based on the host.

A more graceful way of handling this would have been one of the following options:

Option 1

Default disableHostCheck to true.
Then once webpack-dev-server is ready for a major version bump default disableHostCheck to false.

This has a few benefits:

  1. This prevents us from breaking users via a minor version bump
  2. Users who actually care about the feature can set it to false
  3. You eventually get it to your ideal default value which is to prevent the security flaw by default

Option 2

Wait 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 webpack-dev-server is allowing breaking changes in minor version bumps.

nick-woodward commented Apr 25, 2017

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.
My own example being we have multiple companies that have different logos based on the host.

A more graceful way of handling this would have been one of the following options:

Option 1

Default disableHostCheck to true.
Then once webpack-dev-server is ready for a major version bump default disableHostCheck to false.

This has a few benefits:

  1. This prevents us from breaking users via a minor version bump
  2. Users who actually care about the feature can set it to false
  3. You eventually get it to your ideal default value which is to prevent the security flaw by default

Option 2

Wait 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 webpack-dev-server is allowing breaking changes in minor version bumps.

@phairoh

This comment has been minimized.

Show comment
Hide comment
@phairoh

phairoh Apr 25, 2017

Contributor

Semver concerns aside, there is an error in the implementation that is addressed by #888

Contributor

phairoh commented Apr 25, 2017

Semver concerns aside, there is an error in the implementation that is addressed by #888

@ekulabuhov

This comment has been minimized.

Show comment
Hide comment
@ekulabuhov

ekulabuhov Apr 26, 2017

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 webpack-dev-server in production?

ekulabuhov commented Apr 26, 2017

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 webpack-dev-server in production?

@edmorley

This comment has been minimized.

Show comment
Hide comment
@edmorley

edmorley Apr 26, 2017

I'm trying to understand the problem this patch fixes.

See #882 (comment)

edmorley commented Apr 26, 2017

I'm trying to understand the problem this patch fixes.

See #882 (comment)

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 26, 2017

Member

@phairoh oh yeah, thanks for the hint. Should be fixed now.

Member

sokra commented Apr 26, 2017

@phairoh oh yeah, thanks for the hint. Should be fixed now.

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 26, 2017

Member

What if we don't use webpack-dev-server in production?

That's good. webpack-dev-server should not be used in production. But you are still affected!

Does it make sense to have this option enabled on local servers?

yes.

I'm trying to understand the problem this patch fixes.

check the details here: https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a

Member

sokra commented Apr 26, 2017

What if we don't use webpack-dev-server in production?

That's good. webpack-dev-server should not be used in production. But you are still affected!

Does it make sense to have this option enabled on local servers?

yes.

I'm trying to understand the problem this patch fixes.

check the details here: https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 26, 2017

Member

@nick-woodward yes in a perfect world you are right.

From my experience how many people update to the latest major version, I've chosen to release this as patch version. I know that this breaks some setups, but I took this risk for security reasons.

Member

sokra commented Apr 26, 2017

@nick-woodward yes in a perfect world you are right.

From my experience how many people update to the latest major version, I've chosen to release this as patch version. I know that this breaks some setups, but I took this risk for security reasons.

@adam-beck

This comment has been minimized.

Show comment
Hide comment
@adam-beck

adam-beck Apr 26, 2017

Would someone mind explaining this in a little more detail for me

behind proxy you can use the disableHostCheck: true flag

So I can set up an nginx server that forwards all requests to my webpackDevServer? How would this fix the security issue? Because in the medium article:

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.

adam-beck commented Apr 26, 2017

Would someone mind explaining this in a little more detail for me

behind proxy you can use the disableHostCheck: true flag

So I can set up an nginx server that forwards all requests to my webpackDevServer? How would this fix the security issue? Because in the medium article:

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.

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Apr 26, 2017

Member

So I can set up an nginx server that forwards all requests to my webpackDevServer? How would this fix the security issue?

Assuming

  • the nginx server validates the Host header
  • the server is only used for the webpack-dev-server and nginx server (not using the browser)
  • the webpack-dev-server port is not accessible from local network.
Member

sokra commented Apr 26, 2017

So I can set up an nginx server that forwards all requests to my webpackDevServer? How would this fix the security issue?

Assuming

  • the nginx server validates the Host header
  • the server is only used for the webpack-dev-server and nginx server (not using the browser)
  • the webpack-dev-server port is not accessible from local network.
@JemarJones

This comment has been minimized.

Show comment
Hide comment
@JemarJones

JemarJones Apr 26, 2017

Would've been nice to make the response something like "Invalid Host Header (Explanation and link to release notes)" for this version (and remove in the next major), rather than just breaking peoples builds suddenly without explanation.

JemarJones commented Apr 26, 2017

Would've been nice to make the response something like "Invalid Host Header (Explanation and link to release notes)" for this version (and remove in the next major), rather than just breaking peoples builds suddenly without explanation.

@flackjap

This comment has been minimized.

Show comment
Hide comment
@flackjap

flackjap Apr 26, 2017

I am developing an app using the Angular CLI which in turn uses Webpack dev server that is served through the Vagrant environment using Nginx.

Of course, I use an Nginx setup where I just forward (proxy_pass) the hostname request (e.g. app.myapp.com) to the the default ng serve IP and port (http://localhost:4200), and then request it from a browser with a desired hostname.

The only solution for me was to also pass that hostname (app.myapp.com) to the ng serve and also change it in the nginx config file because now they have to match everywhere (in browser, in nginx and in webpack dev server).

Here's an example:

server {
    listen 80;
    listen [::]:80 ipv6only=on;

    server_name app.myapp.com;
    root "/home/vagrant/projects/jb/Laravel/ng-jb/out";
    index index.html index.htm;

    client_max_body_size 10G;

    location / {
        proxy_pass http://app.myapp.com:4200;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
    } 

}

And then just serve it from the Webpack or NG CLI with the added parameters:

Angular CLI:
ng serve --host app.myapp.com

or

Webpack
webpack-dev-server --host app.myapp.com --port 4200

On the other hand, I wouldn't recommend hacking in the optionsSchema.json file of the lib and changing the disableHostCheck. But if an option wasn't there, you can then just change the line 402 in Server.js to always/immediately return true.

flackjap commented Apr 26, 2017

I am developing an app using the Angular CLI which in turn uses Webpack dev server that is served through the Vagrant environment using Nginx.

Of course, I use an Nginx setup where I just forward (proxy_pass) the hostname request (e.g. app.myapp.com) to the the default ng serve IP and port (http://localhost:4200), and then request it from a browser with a desired hostname.

The only solution for me was to also pass that hostname (app.myapp.com) to the ng serve and also change it in the nginx config file because now they have to match everywhere (in browser, in nginx and in webpack dev server).

Here's an example:

server {
    listen 80;
    listen [::]:80 ipv6only=on;

    server_name app.myapp.com;
    root "/home/vagrant/projects/jb/Laravel/ng-jb/out";
    index index.html index.htm;

    client_max_body_size 10G;

    location / {
        proxy_pass http://app.myapp.com:4200;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
    } 

}

And then just serve it from the Webpack or NG CLI with the added parameters:

Angular CLI:
ng serve --host app.myapp.com

or

Webpack
webpack-dev-server --host app.myapp.com --port 4200

On the other hand, I wouldn't recommend hacking in the optionsSchema.json file of the lib and changing the disableHostCheck. But if an option wasn't there, you can then just change the line 402 in Server.js to always/immediately return true.

@Mario-Eis

This comment has been minimized.

Show comment
Hide comment
@Mario-Eis

Mario-Eis Jul 4, 2017

Is it possible to set disableHostCheck via command line? Do we have to modify the webpack config for this?

Mario-Eis commented Jul 4, 2017

Is it possible to set disableHostCheck via command line? Do we have to modify the webpack config for this?

@ApertureSecurity

This comment has been minimized.

Show comment
Hide comment
@ApertureSecurity

ApertureSecurity Jul 9, 2017

Good lord all the security maddness!

I want to ask , if it's okay to ask here...

I am trying to read into as much as configuring webpack as possible. I have webpak behind a reverse proxy.

Public seemed to be ok, but I realized that the server wasn't listening on an externally listening interface, which results in proxy connections failing with 503....

I assume that host 0.0.0.0 is a problem due to DNS rebind attacks(among other things) ...

Is this a secure setting?

--public blah.com:8080 --host 192.168.x.x

ApertureSecurity commented Jul 9, 2017

Good lord all the security maddness!

I want to ask , if it's okay to ask here...

I am trying to read into as much as configuring webpack as possible. I have webpak behind a reverse proxy.

Public seemed to be ok, but I realized that the server wasn't listening on an externally listening interface, which results in proxy connections failing with 503....

I assume that host 0.0.0.0 is a problem due to DNS rebind attacks(among other things) ...

Is this a secure setting?

--public blah.com:8080 --host 192.168.x.x

@shellscape shellscape closed this in #980 Jul 10, 2017

choonkeat pushed a commit to choonkeat/webpacker that referenced this issue Jul 26, 2017

Chew Choon Keat
To use custom dev_server.host configured in webpacker.yml
we need to explicitly configure webpack-dev-server with hostname port
ref webpack/webpack-dev-server#882 (comment)

gauravtiwari added a commit to rails/webpacker that referenced this issue Aug 6, 2017

To use custom dev_server.host configured in webpacker.yml (#593)
we need to explicitly configure webpack-dev-server with hostname port
ref webpack/webpack-dev-server#882 (comment)
@jrohatiner

This comment has been minimized.

Show comment
Hide comment
@jrohatiner

jrohatiner Aug 24, 2017

solution for me:
open node_modules/webpack-dev-server/lib server.js
edit line 451 change false to true
edit line 473 change false to true

I think this allows “public host name” of listening address and the allowedHost === hostname
It appears that server must accept that public hostname and allowedHost are exactly ===

I am using ubuntu, angular/cli latest

jrohatiner commented Aug 24, 2017

solution for me:
open node_modules/webpack-dev-server/lib server.js
edit line 451 change false to true
edit line 473 change false to true

I think this allows “public host name” of listening address and the allowedHost === hostname
It appears that server must accept that public hostname and allowedHost are exactly ===

I am using ubuntu, angular/cli latest

@theohogberg

This comment has been minimized.

Show comment
Hide comment
@theohogberg

theohogberg Aug 30, 2017

Is it too much to ask that the webpack devs stop breaking api and CLI commands?

btw, this should be a priority ONE feature imo, considering most people are not using the "dev-server" as a production environment therefore minimizing the need to block requests as per security concerns.

theohogberg commented Aug 30, 2017

Is it too much to ask that the webpack devs stop breaking api and CLI commands?

btw, this should be a priority ONE feature imo, considering most people are not using the "dev-server" as a production environment therefore minimizing the need to block requests as per security concerns.

@edmorley

This comment has been minimized.

Show comment
Hide comment
@edmorley

edmorley Aug 30, 2017

considering most people are not using the "dev-server" as a production environment therefore minimizing the need to block requests for security concerns.

RCE and information disclosure still affects local development too, so that statement isn't accurate. See #887 for more info.

edmorley commented Aug 30, 2017

considering most people are not using the "dev-server" as a production environment therefore minimizing the need to block requests for security concerns.

RCE and information disclosure still affects local development too, so that statement isn't accurate. See #887 for more info.

@ApertureSecurity

This comment has been minimized.

Show comment
Hide comment
@ApertureSecurity

ApertureSecurity Aug 30, 2017

I suppose , I am looking for the best , and most secure practice and I find that this isn't always easy to find with JavaScript.

What practice is this ? Is webpack not recommended for prod?

ApertureSecurity commented Aug 30, 2017

I suppose , I am looking for the best , and most secure practice and I find that this isn't always easy to find with JavaScript.

What practice is this ? Is webpack not recommended for prod?

@theohogberg

This comment has been minimized.

Show comment
Hide comment
@theohogberg

theohogberg Aug 30, 2017

@edmorley perhaps I can be more specific.
What I'm trying to do is to access the host webpack-dev-server on a virtualbox instance (local machine).

However, when trying to access the host machine (which is 10.0.2.2 by default in NAT settings) this breaks since the address is being rebound and that doesn't seem to be supported.

This can probably be fixed (somehow, bridged connections, etc?) but accessing the host from a virtual instance shouldn't be this hard IMO 😞

theohogberg commented Aug 30, 2017

@edmorley perhaps I can be more specific.
What I'm trying to do is to access the host webpack-dev-server on a virtualbox instance (local machine).

However, when trying to access the host machine (which is 10.0.2.2 by default in NAT settings) this breaks since the address is being rebound and that doesn't seem to be supported.

This can probably be fixed (somehow, bridged connections, etc?) but accessing the host from a virtual instance shouldn't be this hard IMO 😞

@shellscape

This comment has been minimized.

Show comment
Hide comment
@shellscape

shellscape Aug 30, 2017

Contributor

Is it too much to ask that the webpack devs stop breaking api and CLI commands?

I'd highly recommend taking a less aggressive stance with regard to open source projects that are fueled solely by time donated by maintainers and enthusiasts. Those working on this are doing their best to appease an insanely diverse set of requirements and use cases over an insanely diverse user base, all the while trying to keep security and stability in mind. I get that you're frustrated, but take a step back and have a breath before taking to the comments.

Security concerns are still paramount, as was demonstrated by the rebinding flaw attack vectors and the ssl attack vector issues that arose this year.

https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a
https://medium.com/@mikenorth/webpack-preact-cli-vulnerability-961572624c54

Those were/are very real threats to people, even if they couldn't personally affect [you], they're still very real and have the possibility to do real damage. For this reason we clearly disagree that user/dev convenience trumps secrity - quite the contrary. We'll always do our best to try to keep security fixes from interfering with users' dev experience, but now and then an uncomfortable change is necessary.

Also bear in mind that everyone has the ability to fork and bypass features/code that are there to enforce security. Especially considering that webpack-dev-server is intended to be used in a dev environment, it's therefore not an anti-pattern nor bad practice to link your devDep for webpack-dev-server to a github repo (your stripped fork).

Contributor

shellscape commented Aug 30, 2017

Is it too much to ask that the webpack devs stop breaking api and CLI commands?

I'd highly recommend taking a less aggressive stance with regard to open source projects that are fueled solely by time donated by maintainers and enthusiasts. Those working on this are doing their best to appease an insanely diverse set of requirements and use cases over an insanely diverse user base, all the while trying to keep security and stability in mind. I get that you're frustrated, but take a step back and have a breath before taking to the comments.

Security concerns are still paramount, as was demonstrated by the rebinding flaw attack vectors and the ssl attack vector issues that arose this year.

https://medium.com/webpack/webpack-dev-server-middleware-security-issues-1489d950874a
https://medium.com/@mikenorth/webpack-preact-cli-vulnerability-961572624c54

Those were/are very real threats to people, even if they couldn't personally affect [you], they're still very real and have the possibility to do real damage. For this reason we clearly disagree that user/dev convenience trumps secrity - quite the contrary. We'll always do our best to try to keep security fixes from interfering with users' dev experience, but now and then an uncomfortable change is necessary.

Also bear in mind that everyone has the ability to fork and bypass features/code that are there to enforce security. Especially considering that webpack-dev-server is intended to be used in a dev environment, it's therefore not an anti-pattern nor bad practice to link your devDep for webpack-dev-server to a github repo (your stripped fork).

@theohogberg

This comment has been minimized.

Show comment
Hide comment
@theohogberg

theohogberg Aug 30, 2017

@shellscape Ok, didn't know I was being aggressive I was simply asking for a flag/configuration so it can be up to you as a dev

just saw disableHostCheck: true

that's exactly what I was looking for (hopefully) 👍

theohogberg commented Aug 30, 2017

@shellscape Ok, didn't know I was being aggressive I was simply asking for a flag/configuration so it can be up to you as a dev

just saw disableHostCheck: true

that's exactly what I was looking for (hopefully) 👍

@shellscape

This comment has been minimized.

Show comment
Hide comment
@shellscape

shellscape Aug 30, 2017

Contributor

@theohogberg everything is up to you as a dev. you're always free to fork and link to a fork and/or contribute a PR that makes things easier for you and potentially other devs. the language you chose was aggressive; no one has hurt feelings, but please be mindful of that.

Contributor

shellscape commented Aug 30, 2017

@theohogberg everything is up to you as a dev. you're always free to fork and link to a fork and/or contribute a PR that makes things easier for you and potentially other devs. the language you chose was aggressive; no one has hurt feelings, but please be mindful of that.

@theohogberg

This comment has been minimized.

Show comment
Hide comment
@theohogberg

theohogberg Aug 30, 2017

@shellscape In that case I'm Sorry. Did not mean to offend anyone, no matter how sensitive they are.

I guess I have just become a little fed up configuring huge projects. Also, considering webpack has 13,952 (current count) questions on Stackoverflow it might be reasonable to consider making certain things easier.

theohogberg commented Aug 30, 2017

@shellscape In that case I'm Sorry. Did not mean to offend anyone, no matter how sensitive they are.

I guess I have just become a little fed up configuring huge projects. Also, considering webpack has 13,952 (current count) questions on Stackoverflow it might be reasonable to consider making certain things easier.

@shellscape

This comment has been minimized.

Show comment
Hide comment
@shellscape

shellscape Aug 30, 2017

Contributor

We actively welcome contributions from everyone. If you feel there's something that can be made easier, please do considering forking and contributing.

Contributor

shellscape commented Aug 30, 2017

We actively welcome contributions from everyone. If you feel there's something that can be made easier, please do considering forking and contributing.

pdubroy added a commit to harc/ohm-editor that referenced this issue Oct 4, 2017

sensiblegame added a commit to sensiblegame/webpack that referenced this issue Oct 23, 2017

To use custom dev_server.host configured in webpacker.yml (#593)
we need to explicitly configure webpack-dev-server with hostname port
ref webpack/webpack-dev-server#882 (comment)

jankeromnes added a commit to jankeromnes/PeerTube that referenced this issue Jan 25, 2018

stevekrouse added a commit to stevekrouse/create-cycle-app that referenced this issue Mar 2, 2018

Invalid Host header when using proxy
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment