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

[Greg Wilkins <[e-mail]>]

On 30 September 2010 11:52, Maciej Stachowiak <[e-mail]> wrote:

> The injection we are talking about is client side, not server side. All browser-hosted HTTP and WebSocket APIs let you provide a URL, but will not send a request line that contains whitespace.


So you are concerned about the ultra simple WS server that "parses"
the HTTP header with regex's like

  Sec-WebSocket-Key1:([A-Fa-f0-9]*)
  Sec-WebSocket-Key2:([A-Fa-f0-9]*)


Well such a simple server is not going to care if those fake fields
are in the request line or not, and will equally be fooled by XHR
headers like:

   Evil-Genius-1:  Sec-WebSocket-Key1:a34 89j 9a 9fjadsa91df
   Evil-Genius-2:  Sec-WebSocket-Key2:a423s 4  89j 5559aadsa91df
   Evil-Genius-3:  Connection:Upgrade

that will match regexes like

  Sec-WebSocket-Key1:([ A-Aa-z0-9]*)

While HTTP requests can be sent without XHR, these are of no value as
you will see in the analysis below that the method name must be
vulnerable and that will need XHR rather than a src element.

Note also that we are now requiring HTTP compliance before the 101, so
we can test for servers that do not do basic HTTP format checking (
eg by trying requests without any CRLF).

But even if such a server did escape into the wild, I think our
defence in depth will still deal adequately with this threat.

If the request sent had a URL like:

  /some/path/Sec-WebSocket-Key1:0123456789ABCDEF:Sec-WebSocket-Key2:0123456789ABCDEF:Upgrade:WebSocket:

or the headers above, then the regex's could indeed extract the
"injected" keys instead of the ones included in the header, and see
and upgrade header.

Let's also assume that this server has also ignored the URL, because
otherwise the injected URL would be gibberish to it and it would not
initiate a websocket.

Let's further assume that the rest of the request has been read and discarded.

The WS server will now send a 101 response followed by a ping message
with the the hash of the wrong keys in it, and a server-nonce.

The client will receive the 101 - and I'm not entirely sure what a
browser will do with it.   I would not be surprised if it treated it
as an error, but let's assume that the browser doesn't and continues
to use that connection.

The ping message is now sitting in the connection waiting for the
browser to read and process it.  Some browsers will error at this
stage because of the unsolicited input on the connection.  But let's
assume that they don't and they just leave the ping unread for now.

The server is waiting for a pong message before it concludes the
connection is OK.

The client must now somehow send that pong message on the wire.  I do
not believe that a valid pong message can be formed by a HTTP browser,
as the method would need to be formed from control characters.   But
let's assume that it is a broken browser as well and that some how it
allows a correctly formed pong message to be sent.   However, it
cannot form the pong message, because it does not know what the server
nonce is - thus it is not able to complete the handshake and without
the pong, the server will never process any messages that the client
might send.

But let us assume that the poor WS server has a bad RNG and the server
nonce was predictable (or even fixed), then maybe this broken client
could be tricked to send a pong with the right contents.

So with all these assumptions, we have now managed to establish a WS
connection from a HTTP client.  But this is what we want to enable
anyway - for browsers to be able to do this with the websocket API.
However the HTTP client might be able to send a very contrived packet
with the RSV bits and opcode set, but with the content of the frame
being made up of HTTP headers.   So the WS server must have to take
some undesirable action based on the RSV bits and op codes - but this
is a simple WS server, so that is highly unlikely.

Meanwhile, the server might have been sending data packets in
anticipation of the pong.  So let's say the browser sends a request
anyway, even though it is not a pong and will break the connection.
The browser will now look to the connection to read the response and
will see the waiting ping.   This does not look like a HTTP response,
so the browser will throw and error.  It will never process the server
messages after the ping and will certainly not make them available to
the javascript application in any way.

So to recap, this threat is based on:
 + WS server that ignores the URL
 + WS server that does not parse the HTTP and specifically does not
look for any CRLF
 + The browser does not error on the 101 response
 + The browser does not error on the unsolicited ping data
 + The browser allows a method name to be made with control characters
so that a PONG packet can be sent.
 + WS server has a predictable RNG
 + The WS server will take some undesirable action based on the
op-codes and RSV bits
 + The WS server will need to ignore the HTTP headers sent as the
content of any such forged frame.

Adding the space encoded keys does not help because XHR headers can be
used as indicated above.

I think this analysis just proves how insisting on HTTP compliance is
actually good for security as we can test to make sure that WS servers
are parsing CRLF.   It also shows that the space injection gives no
protection real protection and is only perceived to be more secure.
It also indicates that a server nonce is useful in increasing the
depth of defence.


regards