Re: [hybi] Handshake was: The WebSocket protocol issues.

[Greg Wilkins <[e-mail]>]

On 27 September 2010 11:35, Adam Barth <[e-mail]> wrote:
> Browser also protect intranet servers which use connectivity as their
> sole means of authentication/authorization.

True.

So does the presence of WS capability in the browser and/or server
provide any additional capability to exploit such servers?

If so, do the measures in the current and proposed handshakes help in
any significant way?

If not, is there something that we need to do to explicitly protect
port ranges etc in the same way that browsers currently do for XHR?


> The existing HTTP mechanisms exposed to untrusted content in browser
> already respects these security invariants.  In adding new network
> APIs, browser wish to continue to maintain these invariants.

Excellent and both the requirements document and all recent versions
of the specification have included text to the effect that the
existing browser security model will be used.

Maybe that text needs clarification, but nobody has suggested watering
it down in any way.



>> I think that any server that "performs any side effects in response to
>> messages from the client" will have a security vulnerability if they
>> do not correctly check the authentication and authorization of the
>> client.
>
> This is not an accurate understanding of the security invariants
> browsers seek to maintain.

I was not attempting to describe the security invariants that a
browser seeks to maintain.

I was making the observation that a server that performs side effects
on the basis of unauthenticated requests will by definition have a
security issue.   The ability to trigger that issue from a cross
protocol attack is essentially irrelevant if we are proposing the wide
spread deployment of a same protocol mechanism that can trigger the
same side effects.


>> Eventually most browsers will have WS available to the
>> javascript, so a server that is so vulnerable will be able to be
>> exploited just with WS instead of trying to trick HTTP.
>
> Browser seek to protect servers that have never heard of WebSockets
> and have no interest in these newer technologies.  From that
> perspective, it's important to compare the security invariants of the
> browser before and after introducing WebSockets.  We need to study any
> change in these invariants to make sure they don't introduce security
> vulnerabilities in existing servers.  This is a prerequisite for
> exposing the WebSocket API to untrusted content in the browser.

Which is precisely why I have been advocating that we study the impact
of the current handshake and proposed changes.

We need to discuss what type of byte sequences can a compromised WS
capable browser generate that a HTTP capable browser cannot? Are any
of these types of sequences a threat to WS unaware servers?   Does the
space counting and unframed bytes help in any way?

I have suggested that the defence in depth of Sec-headers, nonce
generation, handshake sequence requirements and normal web
authentication/authorization should limit the byte sequence that can
be generated to nothing that is more harmful that what can already
been generated.

All I have asked is if you have done any study that indicates that
suggests that space counting and unframed data provide any additional
meaningful security?

regards