Subject: [hybi] Why redirects are a bad for the security of WebSockets (was Re: Clarify wheter HTTP responses other than 101 are valid)

From: Adam Barth <[email-masked]>
Date: Mon, 28 Mar 2011 13:34:14 -0700

On Mon, Mar 28, 2011 at 6:32 AM, Patrick McManus <[email-masked]> wrote:
> On 3/28/11 1:29 AM, Greg Wilkins wrote:
>> Firstly, I actually don't think we can prohibit non-101 responses.  We
>> have consensus that  before the 101 the handshake must be HTTP
>> compliant, and sending 400, 401, 301, 500, 503 are all HTTP compliant
>> responses that will very likely be seen no matter what we say here.
>
> I basically agree with this - I would put it even stronger. Before the 101
> this is HTTP and therefore the ietf websockets draft really doesn't have
> much to say other than what is already covered by HTTP. HTTP says if the
> response is 101 then start doing the upgraded protocol, otherwise this is
> still HTTP. The draft could use some clarification here.

The WebSocket protocol is a profile of HTTP.  WebSockets is free to
define as small a profile as we choose.  In particular, we're free to
close the connection on non-101 status codes.

> Personally I think to be successful UA's are going to need to implement
> 401s, redirects to pages that set cookies based on closed algorithms (and
> then probably redirect again), etc... Whether or not a UA chooses to chase a
> redirect (or prompt for auth, or whatever) is, as always, up to them.

I'm skeptical of this claim.  I believe we can implement quite
successful user agents permitting only the 101 status.

> Adam, I'm interested in specific classes vulnerabilities you see there. Even
> in generalities. They might be arpopos for the security considerations
> section.

Let's focus on redirects for a bit because those are some of the most
problematic.  Redirects introduce significant complexity in HTTP.  For
example, redirects have been responsible for a large number of
security vulnerabilities in Firefox (and every other browser).  By
introducing redirects into the WebSockets protocol, we're forcing
developers using WebSockets to deal with their complexities, and
they're going to screw it up.

Consider the following code:

var url = <obtain URL from somewhere, e.g. postMessage>

if (!url.startsWith("wss://example.com/"))
  return;

var socket = new WebSocket(url);
socket.onopen = function () {
  [... interact with socket ...]
};

Reading this code, it's quite natural to assume that sending and
receiving information on socket will actually communicate with
example.com.  For example, I might send confidential information to
example.com or rely upon the integrity of information received from
example.com.  However, if example.com has has an open redirector (as
is extremely common on the Internet), this assumption is incorrect and
leads to vulnerabilities.

Now, we can wring our hands and claim that this sort of issue isn't
our problem, but it is.  Simply warning folks about these traps in
Security Considerations is just passing the buck.  Instead, we
shouldn't add this complexity to WebSockets at this time.  We can
always change out minds and add support for redirects in the future,
but we can never remove support once added.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 29 Mar 2011 08:06:08 +1100

> but we can never remove support once added.

Adam,

I don't think it is "our problem".     I think it is a "W3C/WHATWG
HTML-5 WG problem".

This is essentially an API issue for the browser websocket object.
There are plenty of ways around this (adding optional follow
redirects, exposing redirect responses etc. etc.),   but I think it is
the W3C and WHATWG HTML-5 working groups that should be where such
matters are decided.

As a web developer I really rather not have to go without redirection
and other common auth methods - and I take responsibility for my
servers not being open redirectors..... but would understand if the
W3C/WHATWG decided not to support these features - at least initially.

However, we should make the protocol such that if/when the API does
support these features, then it will only be an in browser change and
not an update of the protocol.

cheers

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 Mar 2011 00:38:40 +0200

Hi Adam, I really appreciate you spelling this out - it helps the WG.

> leads to vulnerabilities.
I know you won't agree, but for the wg list I don't see how this expands 
the threat model when compared to all the other bugs and vulnerabilities 
that might be present (or not) on example.com when we interact with it. 
I'm not saying its not our problem, I'm just saying it is more or less 
par for level of vulnerability we already have by connecting to that host.

There are auth patterns using redirect that I think would be useful to 
support. The websockets API wont be able to pass the redir info to the 
JS on failure so we can't just bump the issue out. Plus I think having a 
full fledged http bootstrap without caveat and exception is a good thing 
from a modeling point of view for a lot of the same reasons I think 
masking the whole client->server request stream is a better model.

---

From: Adam Barth <[email-masked]>
Date: Mon, 28 Mar 2011 15:47:21 -0700

On Mon, Mar 28, 2011 at 3:38 PM, Patrick McManus <[email-masked]> wrote:
> I know you won't agree, but for the wg list I don't see how this expands the
> threat model when compared to all the other bugs and vulnerabilities that
> might be present (or not) on example.com when we interact with it. I'm not
> saying its not our problem, I'm just saying it is more or less par for level
> of vulnerability we already have by connecting to that host.

Yeah, I don't agree.  People like to complain about open redirectors,
but the reality is that the vast majority of non-trivial web sites
contain them and don't feel a need to close them.  The situation is
quite unlike XSS, which sites actively worry about and repair.

> support. The websockets API wont be able to pass the redir info to the JS on
> failure so we can't just bump the issue out. Plus I think having a full
> fledged http bootstrap without caveat and exception is a good thing from a
> modeling point of view for a lot of the same reasons I think masking the
> whole client->server request stream is a better model.

That's all fine and good, but we don't need to address those use cases
in the first iteration of the protocol.  If these turn out to be
pressing issues that can't be addressed satisfactory at the
application layer, then we can revisit this question.  Anything else
is premature.

I also don't buy your argument about simplifying the model by
increasing complexity.  Adding complexity does not improve security.

Adam

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2011 01:22:34 +0200

> leads to vulnerabilities.

Let me a question: if you would trust the connection with example.com,
why shouldn't you trust it in case it redirects you to other place?

> but we can never remove support once added.

Which is the main advantage/feature HTTP redirections provide? is it
load-balancing? If so, forget the ugly 3XX responses and just add DNS
SRV support to WebSocket protocol.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Barth <[email-masked]>
Date: Mon, 28 Mar 2011 16:34:34 -0700

> why shouldn't you trust it in case it redirects you to other place?

As stated above, we're assuming example.com has an open redirector.

Adam

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 Mar 2011 09:01:39 +0200

> increasing complexity.  Adding complexity does not improve security.
Neither of us is arguing for increased complexity - we just have 
different views on what creates complexity.

My argument is that adding restrictions and caveats is what adds the 
complexity. Vanilla HTTP is well understood and reusing that (Redirects, 
401's, and all) as it is normally understood reduces the complexity of 
the definition.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Mar 2011 09:14:03 +0200

On 28.03.2011 23:06, Greg Wilkins wrote:
> ...
> ...

Absolutely. The problem is automatically following the redirect without 
notifying the caller.

BR, Julian