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

[Scott Ferguson <[e-mail]>]

Adam Barth wrote:
> Please read my later message.  That should give you a more concrete
> understanding of the issue.
>
> (minor points inline)
>
> On Fri, Oct 1, 2010 at 5:45 PM, Scott Ferguson <[e-mail]> wrote:
>   
>> Adam Barth wrote:
>>     
>>> On Thu, Sep 30, 2010 at 6:50 PM, Scott Ferguson <[e-mail]> wrote:
>>> As a side note, using an exotic HTTP method is not a good idea.  The
>>> first few bytes of the clients initial message are absolutely
>>> critical.  Picking an exotic HTTP method is just rolling the dice
>>> w.r.t. what protocols an attacker can exploit.  For example, some
>>> attacks from HTTP to DNS rely critically on the fact that the first
>>> byte of an HTTP POST message is an uppercase P.  The kinds of things
>>> you can do with an uppercase W as the first byte are largely
>>> unstudied.
>>>
>>>       
>> You misunderstand entirely.
>>
>> It's not an exotic HTTP method; it's identifying the protocol by the initial
>> sequence of bytes.
>>     
>
> Exotic => can't be sent by web sites to arbitrary hosts today in browsers.
>   

Understood, but that describes any new protocol added to the browser.

Without initial identifying bytes, no server (new protocol or old) can 
detect and reject a websocket request without scanning past a large 
number of hijackable bytes. I'd like to give servers the ability to 
identify and reject a websocket request before scanning hijackable 
bytes, even if not all servers can take advantage of that information.
>   
>> If every client for every protocol sent a non-hijackable unique protocol
>> identifier as its initial sequence, and every server for every protocol
>> verified the protocol identifier before accepting any further bytes, then
>> cross protocol attacks would be impossible.
>>     
>
> Sure, but there are plenty of protocols that don't do that.
>
>   

Which is why we still need server validation before sending the client 
payload. I'm not suggesting removing the nonce/hash check at all.

If this increases security for existing validating protocols and all new 
protocols, it increases security.  As you point out, it cannot be the 
only defense.

>> We can't fix the older protocols that don't identify themselves immediately
>> and don't validate, but we can ensure that new protocols do.
>>     
>
> Unfortunately, we don't have the luxury of ignoring attacks against
> these "older" protocols.
>   

It is true that you will need to re-analyze url/header attacks against 
non-validating legacy servers, but the added security of the identifying 
bytes for the benefit of validating servers and future protocols is 
worth the trouble.

-- Scott

> Adam
>
>
>
>