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

[Adam Barth <[e-mail]>]

On Mon, Mar 28, 2011 at 6:32 AM, Patrick McManus <[e-mail]> 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