Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add some security checks when handling a HTTP connection. #1634

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Add some security checks when handling a HTTP connection. #1634

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
887be0d
Add some security checks when handling a HTTP connection.
jgraham Dec 3, 2021
5e8999a
Use undefined rather than null as the defaut header value.
jgraham Mar 18, 2022
e07e6ec
Disallow CORS-safelisted Content-Type headers.
jgraham Mar 18, 2022
a26a826
Add some extra detail about allowing external network connections.
jgraham Mar 18, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
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.
  • Loading branch information
@jgraham
jgraham committed Mar 18, 2022
commit a26a82676bf3b7e745a2859fa2cd87185a2bd618
37 changes: 20 additions & 17 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -465,11 +465,14 @@ <h3>Processing model</h3>
<p>Then <a>send an error</a> with <a>error code</a> <a>unknown
error</a>, and jump to step 1.</p>

<p class=note>Rejecting connections with unexpected values in the
<a>Host header</a> prevents DNS rebinding attacks. Implementations can opt
to provide more stringent controls where appropriate, for example
only accepting connections when the <var>host</var> value
corresponds to a loopback interface [[RFC5735]].</p></li>
<p class="note">Rejecting connections with unexpected values in the
<a>Host header</a> prevents DNS rebinding attacks. Implementations
can opt to provide more stringent controls where appropriate, for
example only accepting connections when the <var>host</var> value
corresponds to a loopback interface [[RFC5735]]. Further guidance
for implementors is given in the <a href="#security">security</a>
section.</p>
</li>

<li><p>If <var>origin</var> is not undefined and is not identical to
an <a>Origin header</a> value that the implementation has been
Expand Down Expand Up @@ -10494,18 +10497,18 @@ <h2>Security</h2>
and that WebDriver remains disabled
in publicly consumed versions of the user agent.

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

<p>The <a>remote end</a> 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 <code>127.0.0.0/8</code>
and the IPv6 localhost address <code>::1</code>. [[RFC4632]]
<p>To prevent arbitrary machines on the network from connecting and
creating <a>sessions</a>, it is suggested that only connections from
loopback devices are allowed by default. However, testing setups
commonly put the <a>remote end</a> and <a>local end</a> 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 <a>intermediary node</a> that provides authorization and
authentication. <a>Remote end</a> implementors are encouraged to
provide minimal, opt-in, configuration to support these scenarios.

<p>It is also suggested that user agents
make an effort to visually distinguish
Expand Down