Host header is specified and is not an IP address or localhost

[Andrea Cardaci]

So starting from version 66 Chrome stops accepting HTTP connections to the debugging protocol server if the "host header is specified and is not an IP address or localhost". (This doesn't apply for the WebSocket.) The change has been introduced here, probably (the related issue is private) to rule out the possibility of DNS rebinding attacks originating from web pages or something like that.

This broke the setup of several users, see: here, here, and here. And no explicit workaround has been provided.

IMHO the most obvious solution is to use an IP address to refer the node where Chrome is listening, this requires no modification in the clients but requires the user to pre-resolve the domain by hand. Of course clients could resolve the domain themselves and use the IP address transparently, but still looks kind of dirty.

Alternatively, clients could just drop the host header, but apart from being an HTTP 1.1 spec violation (and Chrome RDP does not accept version 1.0) it breaks the `webSocketDebuggerUrl` field for the `/json/list` and `/json/new` endpoints, as I pointed out in the Puppeteer issue. While this could be a bug, what Chrome should put there if no host header is specified when started with `--remote-debugging-address=0.0.0.0`?

So what should be the proper solution in your opinion?

Andrea

[Pavel Feldman]

On Thu, May 3, 2018, 03:51 Andrea Cardaci <cyru...@gmail.com> wrote:

So starting from version 66 Chrome stops accepting HTTP connections to the debugging protocol server if the "host header is specified and is not an IP address or localhost". (This doesn't apply for the WebSocket.) The change has been introduced here, probably (the related issue is private) to rule out the possibility of DNS rebinding attacks originating from web pages or something like that.

This broke the setup of several users, see: here, here, and here. And no explicit workaround has been provided.

IMHO the most obvious solution is to use an IP address to refer the node where Chrome is listening, this requires no modification in the clients but requires the user to pre-resolve the domain by hand. Of course clients could resolve the domain themselves and use the IP address transparently, but still looks kind of dirty.

Could you elaborate on this solution? What is done and where and what does it solve?

Alternatively, clients could just drop the host header, but apart from being an HTTP 1.1 spec violation (and Chrome RDP does not accept version 1.0) it breaks the `webSocketDebuggerUrl` field for the `/json/list` and `/json/new` endpoints, as I pointed out in the Puppeteer issue. While this could be a bug, what Chrome should put there if no host header is specified when started with `--remote-debugging-address=0.0.0.0`?

So what should be the proper solution in your opinion?

- One would be Using the resolved IP address and not relying upon browser's DNS

- The other would be ssh tunnel and the use of Host: localhost

I think docker is the only issue where users actually struggle with the new limitation. I need to learn more about it to help resolving it.

Andrea

--
You received this message because you are subscribed to the Google Groups "chrome-debugging-protocol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-debugging-p...@googlegroups.com.
To post to this group, send email to chrome-debug...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chrome-debugging-protocol/92dd7006-2b9e-44cd-abc5-6080d1346673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrea Cardaci]

On Thursday, 3 May 2018 16:33:34 UTC+2, Pavel Feldman wrote:

On Thu, May 3, 2018, 03:51 Andrea Cardaci <cyru...@gmail.com> wrote:

So starting from version 66 Chrome stops accepting HTTP connections to the debugging protocol server if the "host header is specified and is not an IP address or localhost". (This doesn't apply for the WebSocket.) The change has been introduced here, probably (the related issue is private) to rule out the possibility of DNS rebinding attacks originating from web pages or something like that.

This broke the setup of several users, see: here, here, and here. And no explicit workaround has been provided.

IMHO the most obvious solution is to use an IP address to refer the node where Chrome is listening, this requires no modification in the clients but requires the user to pre-resolve the domain by hand. Of course clients could resolve the domain themselves and use the IP address transparently, but still looks kind of dirty.

Could you elaborate on this solution? What is done and where and what does it solve?

The first part simply requires that users provide the IP address directly instead of the domain to the clients, for example with chrome-remote-interface:

    const client = await CDP({host: 1.2.3.4});

The second part is performing the DNS resolution Node.js-side (in this case, inside chrome-remote-interface) and using that to connect to the endpoint so that the host header is set to the IP.

Alternatively, clients could just drop the host header, but apart from being an HTTP 1.1 spec violation (and Chrome RDP does not accept version 1.0) it breaks the `webSocketDebuggerUrl` field for the `/json/list` and `/json/new` endpoints, as I pointed out in the Puppeteer issue. While this could be a bug, what Chrome should put there if no host header is specified when started with `--remote-debugging-address=0.0.0.0`?

So what should be the proper solution in your opinion?

- One would be Using the resolved IP address and not relying upon browser's DNS

- The other would be ssh tunnel and the use of Host: localhost

I think docker is the only issue where users actually struggle with the new limitation. I need to learn more about it to help resolving it.

Andrea

--
You received this message because you are subscribed to the Google Groups "chrome-debugging-protocol" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chrome-debugging-protocol+unsub...@googlegroups.com.

[Andrea Cardaci]

FYI here's the candidate solution for chrome-remote-interface.