From 887be0dac139ca83ddf52497f4f94bafd172ee7d Mon Sep 17 00:00:00 2001 From: James Graham Date: Fri, 3 Dec 2021 16:16:58 +0000 Subject: [PATCH 1/4] Add some security checks when handling a HTTP connection. 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. --- index.html | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 61 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index d13fd3ee..8cf6c6e6 100644 --- a/index.html +++ b/index.html @@ -428,8 +428,52 @@

Processing model

received data, according to the requirements of [[RFC7230]]. If it is not possible to construct a complete HTTP request, the remote end must either close the connection, - return an HTTP response with status code 500, or return - an error with error code unknown error. + return an HTTP response with status code 500, or send an + error with error code unknown error, and then + jump to step 1. + +

  • If request has a Host header, + let host be the value of that header. Otherwise + let host be null.

    • + +

  • If request has an Origin header, + let origin be the value of that header. Otherwise + let origin be null.

    • + +

  • If any of the following conditions hold: +

    +

    Then send an error with error code unknown + error, and jump to step 1.

    + +

    Rejecting connections with unexpected values in the + Host header prevents DNS rebinding attacks. Implementations can opt + to provide more stringent controls where appropriate, for example + only accepting connections when the host value + corresponds to a loopback interface [[RFC5735]].

    • + +

  • If origin is not null, and is not identical to an + Origin header value that the implementation has been + configured to allow, then stop running these steps and act as if the + requested service is not available.

    + +

    Rejecting connections with unexpected values in + the Origin header is necessary to prevent untrusted websites + from establishing a WebDriver session.

  • Let request match be the result of the algorithm to match a request with request’s @@ -10958,6 +11002,21 @@

    Index

    it is supposed that the implementation supports the relevant subsets of [[RFC7230]], [[RFC7231]], [[RFC7232]], [[RFC7234]], and [[RFC7235]]. +

    The following terms are defined in the Web Origin Concept specification: [[RFC6454]] +

    + +

    The following terms are defined in the Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing specification: [[RFC7230]] +

    + +

    The following terms are defined in the Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content specification: [[RFC7231]] +

    +

    The following terms are defined in the Cookie specification: [[RFC6265]]

    • Compute cookie-string From 5e8999a2c2647e55efa69a438bfe9775ea2264bb Mon Sep 17 00:00:00 2001 From: James Graham Date: Fri, 18 Mar 2022 14:44:20 +0000 Subject: [PATCH 2/4] Use undefined rather than null as the defaut header value. This avoids confusion with null as a string value of the Origin header --- index.html | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/index.html b/index.html index 8cf6c6e6..a55789a0 100644 --- a/index.html +++ b/index.html @@ -434,14 +434,15 @@

      Processing model

    • If request has a Host header, let host be the value of that header. Otherwise - let host be null.

      • + let host be undefined.

    • If request has an Origin header, let origin be the value of that header. Otherwise - let origin be null.

      • + let origin be undefined.

    • If any of the following conditions hold:

        +

      • host is undefined.

      • host doesn't match the Host grammar [[RFC7230]]

      • The result of host parsing the uri-host @@ -466,8 +467,8 @@

        Processing model

        only accepting connections when the host value corresponds to a loopback interface [[RFC5735]].

        • -

      • If origin is not null, and is not identical to an - Origin header value that the implementation has been +

      • If origin is not undefined and is not identical to + an Origin header value that the implementation has been configured to allow, then stop running these steps and act as if the requested service is not available.

        From e07e6ecc2f77c56f72a2930202cc7c4fb358d842 Mon Sep 17 00:00:00 2001 From: James Graham Date: Fri, 18 Mar 2022 14:45:53 +0000 Subject: [PATCH 3/4] Disallow CORS-safelisted Content-Type headers. This prevents e.g. websites creating forms that can start a local WebDriver session in a browser, even if there's no Origin header --- index.html | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/index.html b/index.html index a55789a0..3797aa57 100644 --- a/index.html +++ b/index.html @@ -440,6 +440,10 @@

        Processing model

        let origin be the value of that header. Otherwise let origin be undefined.

        • +

      • If request has an Content-Type header, + let content-type be the value of that header. Otherwise + let content-type be undefined.

        • +

      • If any of the following conditions hold:

        • host is undefined.

          • @@ -476,6 +480,18 @@

          Processing model

          the Origin header is necessary to prevent untrusted websites from establishing a WebDriver session.

          +

        • If content-type is not undefined, and + ("content-type", content-type) is a + [=CORS-safelisted request-header=], or otherwise if the value + of content-type is not a Content-Type header the + implementation allows, then stop running these steps and act as if + the requested service is not available.

          + +

          This provides an additional layer of defence against + requests originating from untrusted websites. Implementations can + choose to implement this by only accepting requests with the + "application/json" Content-Type header.

          • +

        • Let request match be the result of the algorithm to match a request with request’s method and URL as arguments. From a26a82676bf3b7e745a2859fa2cd87185a2bd618 Mon Sep 17 00:00:00 2001 From: James Graham Date: Fri, 18 Mar 2022 14:47:32 +0000 Subject: [PATCH 4/4] Add some extra detail about allowing external network connections. This doesn't add normative requirements, but encourages implementors to ship with secure defaults, whilst mentioning that there are real-world use cases which require remote ends to accept connections coming from somewhere other than localhost. --- index.html | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/index.html b/index.html index 3797aa57..96849e0b 100644 --- a/index.html +++ b/index.html @@ -465,11 +465,14 @@

          Processing model

          Then send an error with error code unknown error, and jump to step 1.

          -

          Rejecting connections with unexpected values in the - Host header prevents DNS rebinding attacks. Implementations can opt - to provide more stringent controls where appropriate, for example - only accepting connections when the host value - corresponds to a loopback interface [[RFC5735]].

          • +

          Rejecting connections with unexpected values in the + Host header prevents DNS rebinding attacks. Implementations + can opt to provide more stringent controls where appropriate, for + example only accepting connections when the host value + corresponds to a loopback interface [[RFC5735]]. Further guidance + for implementors is given in the security + section.

          +

        • If origin is not undefined and is not identical to an Origin header value that the implementation has been @@ -10494,18 +10497,18 @@

          Security

          and that WebDriver remains disabled in publicly consumed versions of the user agent. -

          To prevent arbitrary machines on the network - from connecting and creating sessions, - it is suggested that only connections from - loopback devices are allowed by default. - -

          The remote end can include - a configuration option to limit - the accepted IP range allowed to connect and make requests. - The default setting for this might be - to limit connections to the IPv4 localhost - CIDR range 127.0.0.0/8 - and the IPv6 localhost address ::1. [[RFC4632]] +

          To prevent arbitrary machines on the network from connecting and + creating sessions, it is suggested that only connections from + loopback devices are allowed by default. However, testing setups + commonly put the remote end and local end on different + network hosts. Users deploying such a setup are encouraged to + restrict access to the remote end to the greatest extent possible, + either by restricting network connections to trusted hosts (e.g. in + the case of a lab setting, or the remote end running in a containers + on the same bridged network), or by routing all connections through + an intermediary node that provides authorization and + authentication. Remote end implementors are encouraged to + provide minimal, opt-in, configuration to support these scenarios.

          It is also suggested that user agents make an effort to visually distinguish