Re: [hybi] Extensibility mechanisms?

[Maciej Stachowiak <[e-mail]>]

On Jul 22, 2010, at 7:07 AM, Willy Tarreau wrote:

> Hi Maciej,
> 
> On Thu, Jul 22, 2010 at 12:18:19AM -0700, Maciej Stachowiak wrote:
>> There's at least three kinds of concerns about cross-protocol attacks and the WebSocket protocol, in the case where the client is the browser:
>> 
>> 1) Hostile JS code running in the browser may use the browser's WebSocket client code to try to attack existing HTTP resources, if it can make a request that looks sufficiently like HTTP.
> 
> Maybe I'm mistaken, but why couldn't such JS code simply make use of the
> browser's HTTP client to do so ? Posting a form, reloading an image from
> a given URL or making an XMLHttpRequest seems perfectly possible right now,
> so trying to do that via the WebSocket code would bring nothing at all.

All of the mechanisms you listed have significant restrictions:

1) Reloading an image from a given URL, the in-browser attacker cannot use any method other than GET or set any custom headers beyond what the UA sends normally. And the attacker definitely cannot read back the reply.
2) Posting a form, the in-browser attacker cannot use any method other than GET or POST, set any custom headers beyond what the UA sends normally, or send content in anything but a short list of existing formats. And the attacker definitely cannot read back the reply.
3) Using cross-site XMLHttpRequest, the attacker cannot use any method other than GET or POST, set any custom headers, or include a message body in anything but a small set of formats, unless the target site explicitly opts in via an OPTIONS request (cross-site XHR is specifically designed to only be able to do things you can do with form submission).

Even given all that, many sites do in fact have vulnerabilities to cross-site form posting. This class of attacks is called Cross-Site Request Forgery, or CSRF. Typically, these are attacks on integrity, not confidentiality, since the attacker cannot read the reply. WebSocket creates the possibility of extending the attack surface for these kinds of attacks, and for the possibility of attacks on confidentiality as well as integrity.


> 
>> 3) Hostile JS code running in the browser may use the browser's HTTP client code (e.g. via XMLHttpRequest) to try to attack newly created WebSocket servers, if it can make a request that looks sufficiently like WebSocket.
> 
> The same is true here : why would the JS code try to use the normal HTTP
> client if the browser supports WebSocket, with which the code would be
> able to have finer control over its attack ?

Because WebSocket would require a successful handshake before sending any actual messages, while an HTTP POST with XHR would blindly send the post body without validating the handshake. If the server doesn't thoroughly verify the client part of the handshake, then it may be tricked into processing  a POST body that looks like a series of WebSocket messages. If it authenticates with a cookie, then this could be used to inject control messages with a side effect, depending on the nature of the WebSocket service.

> 
>>> If this is indeed the issue you're talking about, then I don't see why
>>> the HTTP-based handshake could be a problem there. It's not more than
>>> any other common HTTP request, it's even better in that no data should
>>> flow until the server has correctly replied indicating proper support
>>> for the protocol.
>> 
>> What's "the HTTP-based handshake"?
> 
> I mean the HTTP Upgrade mechanism.

Do you mean the specific mechanism currently in <http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76> or something else?

> 
>> We have had several proposals for handshakes that start out looking like HTTP. They are not all equally effective in protecting against cross-protocol attacks, though some of them do have some protection..
> 
> Possibly, but what ended up in the spec was finally less secure than the normal
> HTTP handshake since it allows the client to send bytes to the server through
> reverse proxies without that later being aware of it.
> 
>> Although I am not an expert on cross-protocol attacks, one thing I have learned is that the issues can be *extremely* subtle. This leads me to conclude that it's better to err on the side of caution, and design the protocol to be even more robust against such threats than we think is strictly necessary. 
> 
> I agree with the *extremely subtle* point. But that's also why I'd rather
> not try to reinvent within a small group things that are already efficient
> and not proven wrong. We must accept that a small group is never smarter
> than those outside the group and that a few hours designs have little
> chance of being more robust than those which have survived exposure to the
> world for 10 years or so.
> 
> It's just like when you see developers implement their own crypto algorithm
> because "the public ones have not been broken yet but they're attacked, so
> let's be safe and write a new one". The ones I have talked about on this
> subject were really convinced their work was better than everything else,
> while it was a disaster. That's what I'd prefer we avoid here.
> 
> However, enforcing a strict mode of operations based on something which
> already works, or as Sal suggested, enforcing a stricter standard is the
> right way to go.

I don't think anyone has previously invented a solution to this problem, so we don't have the option of using a well-vetted 10-year-old design. I also do not think passing off responsibility to another group increases our odds of creating a secure protocol.


> 
>> I believe the TLS-based handshake (as proposed by Adam) is more robust than solutions involving nonces and challenge/response built into an HTTP-like handshake. The reason for this is that it's hard for the attacker to control the bytes sent, other than to cause the initiation of a TLS handshake, which is something that all network services are already exposed to by browsers. The attacker cannot get to the next-level protocol running over TLS unless the server explicitly opts in. With HTTP-based schemes, it takes much more care to avoid sending information as the "wrong" protocol.
> 
> I agree with those points, but as suggested, there are many cases where
> being limited to TLS can be a showstopper, either due to overhead, or
> more simply because it will leave many users away (mostly those inside
> enterprises who can only access a limited set of SSL sites).
> 
> We should spend some time trying to enumerate what aspect(s) of the HTTP-based
> handshake we believe may be a problem regardless of the protocol deployed on
> the target server.

I think it would be worth enumerating the pros and cons of the TLS-based approach and recording them somewhere (such as on a wiki page).

Regards,
Maciej