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

[Greg Wilkins <[e-mail]>]

On 30 September 2010 02:47, Maciej Stachowiak <[e-mail]> wrote:
>> Why is hex encoding simpler to inject than the space/char injected
>> decimal encoding?
>
> Because you can't inject whitespace into the resource name in the request line.

It is very hard to imagine a server that is so broken that it will
allow injection of fully formed HTTP requests, responses into a URL,
complete with CRLF etc. but that will not allow spaces to be injected.

Also, the attacks described do not need to inject the space encoded
fields.  They are part of the request and the attacker is happy for
the server to just ignore them.  The attacker is trying to inject a
valid 101 response.

Unless you are concerned that somehow the WS server will see the URL
in the upgrade request as a second upgrade request??
but simple WS servers are not going to process multiple HTTP requests
and complex ones are going to have real HTTP parsers that should not
be vulnerable to such an attack - if they were, then they are so
broken that spaces are not going to make a difference, because you
must also be able to inject CRLF.




>> The white space fields originate from the client and do not need to be
>> injected into
>> the server response.
>>
>> Can you explain any scenario where a HTTP client could somehow send Sec- fields
>> without spaces, but could not send ones with spaces?
>
> Sticking something that looks like a Sec- header into the request line is possible (that is under the attacker's control with both WebSocket and HTTP APIs) but you can't include whitespace - it will get stripped or percent-escaped.

Injecting such things into request lines is normally part of an attack
to cause the server to echo that content back as part of a response.
There is no benefit of putting Sec- headers into the response.

Having Sec-header content in the request line is not going to make the
server see that as another HTTP request or as part of the current HTTP
request - unless it is so broken that CRLF can be inject, in which
case I don't think spaces are much protection.



> For the record, I don't think the unframed random bytes in the request add any security value.

Then why are you fighting so hard against my reasonable proposals?

Couldn't you just have said +1 to framing those bytes, but I'm a
little worried about taking the spaces out???
Did you really need to start this whole thread questioning my
capabilities to understand a cross protocol attack?



> Personally, I would prefer if failure-detection mechanisms were kept separate from security mechanisms if possible.

I have long argued for that.   In fact I believe that it would be
sufficient to put the hash into a response header.
However, some appear to have concerns with that - so I was proposing
minimal changes to try to fix the broken handshake.
If you think we should go further, then that is no reason to argue
against the modest proposals that I have made:

  + frame the random bytes as websocket frames
  + don't send ws frames until after 101.
  + use a simple hex encoding for the nonce