Re: [hybi] Extensibility mechanisms?

[Jamie Lokier <[e-mail]>]

Scott Ferguson wrote:
> Adam Barth wrote:
> >On Thu, Jul 22, 2010 at 1:50 PM, Scott Ferguson <[e-mail]> wrote:
> >  
> >>Adam Barth wrote:
> >>    
> >>>We need to know the server understands web sockets before spamming
> >>>them with attacker-controlled bytes.  If we don't, we'll repeat the
> >>>long and tragic history of cross-protocol vulnerabilities caused by
> >>>HTTP POST.
> >>>
> >>>This is a hard requirement.
> >>>      
> >>Then I think it should be added to the requirements document, because 
> >>that's
> >>a fundamental design decision.
> >>    
> >
> >   REQ. 19:  WebSocket should be designed to be robust against cross-
> >      protocol attacks.  The protocol design should consider and
> >      mitigate the risk presented by WebSocket clients to existing
> >      servers (including HTTP servers).  It should also consider and
> >      mitigate the risk to WebSocket servers presented by clients for
> >      other protocols (including HTTP).
> >  
> Yes, but that's not specific enough for your requirement because 
> "consider and mitigate" doesn't necessarily imply "client must validate 
> server before sending content."
> 
> As long as everyone's clear and agrees on the "client must validate 
> server before sending content" requirement, then we're fine.

It seems a strange leap of logic, as it isn't the only way to mitigate
the attack risk and it has perceptible negative consequences.

Anyway I can't see how "client must validate server before sending
content" can be satisfied.  Clients are free to encode their content
in the subprotocol field, and JavaScript apps might actually resort to
that if it's the only way to hack around that side of the RT delay.
I'm not sure if the API gives any way for JS apps to retrieve anything
interesting sent on the other side of the handshake.

Note I have no problem with "client must validate server before
sending WebSocket encoded frames / dangerous frames / non-HTTP frames
(take your pick)" .

-- Jamie