Add some security checks when handling a HTTP connection.

[jgraham]

Check the Host and Origin headers for the incoming connection to
verify the connection is allowed.

The language is intended to allow the specific behaviour to be largely
implementation defined, whilst recommending a default
behaviour that prevents CSRF-type attacks (reject host headers that
aren't an IP address or the server hostname, reject any requests with
an origin header).

Hopefully adding this text will ensure that implementations consider
the security issues accepting a connection, even though it's not
possible to give precise requirements that apply to all
implementations.

---

Preview | Diff

---

Preview | Diff

[jgraham]

The BiDi version of this is w3c/webdriver-bidi#155

[whimboo]

CC @sadym-chromium, @bwalderman

[sadym-chromium]

When WebDriver server is run in a Docker container, the Host header is always different from the host of the HTTP server. Current spec includes this specific to "or to another host the implementation has been configured to allow.", but maybe it would make sense to extract it into the specific step, so that the need of such a configuration will be more explicit?

Suggested change

	<li><p>Let <var>implementation allowed hosts rule</var> be the configured by the implementation rule determines if the given host allowed or not. Otherwise let <var>implementation allowed hosts rule</var> be the rule matching nothing.</p></li>

[jgraham]

I think it's hard to be very specific here because the details of what's required depend a lot on the setup you want to support. For example it's possible to support the docker setup by making the host of the HTTP server the same as the host of the container. But it's also possible to support it by e.g. binding to an IP address, in which case the server just has to know it should accept requests with the specific host header that the conatiner will have. So I've tried to write some general guidance in the security section which suggests you probably want to provide some configuration options to support this kind of scenario, but without saying too much about exactly what they need to be.

[sadym-chromium]

Suggested change

	<a>host</a> of the HTTP server or to another <a>host</a> the
	implementation has been configured to allow.</p></li>
	<a>host</a> of the HTTP server or
	does not match the <var>implementation allowed hosts rule</var>.</p></li>

[sadym-chromium]

Or maybe add note about Docker and some other edge cases here?

[whimboo]

@jgraham I assume the summary of this issue should say WebDriver and not WebSocket right?

Beside that please also have a look at issues #1578 and #1643. Both are related and I hope that we could fix them with your PR. Thanks.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Host/Origin checks.

The full IRC log of that discussion

<jgraham> Topic: Host/Origin checks
<jgraham> github: https://github.com//pull/1634
<sadym> q+
<jgraham> jgraham: Allowing HTTP/WebSocket connections comes with some security concerns eg. if you don't check origin header then websites might be able to start a session. The spec didn't cover this before, but the PR adds some checks in when establishing a connection.
<jgraham> ack sadym
<jgraham> sadym: There is a use case with docker, because the host header for the container is different to the actual host. We need to account for this in the spec.
<jgraham> jgraham: Agreed, we should allow implementations to allow an implemtation-defined list of hosts to handle these cases.
<jgraham> jgraham: Also need to perform the checks on the WebSocker upgrade request for BiDi.

[jgraham]

I've updated this a bit; I think it now covers all the points in the linked issues apart from:

• I didn't mention AF_LOCAL sockets. It definitely seems reasonable to support local-only communication as well as AF_INET* sockets, but I'm not sure in practice if they're usable in current clients ("local ends").
• I didn't mention HTTP Auth, although I did mention some kind of authorization being encouraged in cases where the "remote end" is really a publically accessible service. In practice I don't know what we could suggest which would add meaingful additional security and be compatible with common use cases like running tests in a CI system where the loal and remote ends are both on the same machine.

In any case I think if there's more to do for those points we should consider them in their own issues / PRs and limit this one to just the header validation requirements for accepting incomping requests.

[whimboo]

@sadym-chromium in case you have some available time soon maybe you could have a look at this PR again and if your comments have been addressed or clarified? Thanks.

[randomstuff]

I don't believe verifying the port of the Host header adds any significant security (especially with respect to DNS rebinding attacks) (?). It is probably not necessary to require this verification.