Re: [hybi] Concerns about Origin

[Zhong Yu <[e-mail]>]

On Mon, Nov 22, 2010 at 10:38 AM, Simon Pieters <[e-mail]> wrote:
> On Mon, 22 Nov 2010 17:07:46 +0100, Zhong Yu <[e-mail]> wrote:
>
>> I agree. The spec should *require* servers to actively check Origin
>> and reject handshake immediately if Origin isn't accepted, instead of
>> allowing servers to defer that logic to clients.
>
> If the server has a hardcoded Sec-WebSocket-Origin value, I have no problem
> with relying on the client checking that it matches what it sent.

In that case, how hard is it to match the single hardcoded Origin with
the single Origin the client sent? Why do we even give the server a
choice here?

> My problem
> is with servers just echoing the Origin and the app writer has no idea that
> it allows connections from anywhere.
>
>> APIs for server apps should have a hook to the handshake event, so
>> that apps can participate in the handshake. Apps have an opportunity
>> here to check Origin, set cookies, etc. per connection.
>
> pywebsocket allows apps to do extra checks in the handshake, but I'd like to
> take a step further and make the origin choice a required step for the app
> writer.
>
>
>> "Same origin" policy probably would be the most popular/default
>> policy. A simple and safe way to implement that on server side is to
>> match "Origin" with "Host" header(or the host part of the ws resource
>> URI).
>
> Host only carries domain and port, not the protocol, and the port for the
> websocket connection can very well be different than the port of the page
> you expect a connection from...
>
Sure. But the policy of "Origin=Host" probably will work for most
deployments, therefore it's not a bad choice for default. Given that
it is safe.

>
>> That is safe if we assume that all pages on the Host can be trusted.
>> Cookies don't assume that, they have an additional "path" restriction.
>
> The "path" feature for cookies do not help anything with security, since the
> same-origin-policy allows you to open an iframe within the same origin and
> eat all the cookies.

That's interesting. Can you give me a link?

>
>> If a WS app is as paranoid, currently it doesn't have a way to know on
>> which page specifically the connection is made.
>
> That is by design, so that people don't fall into the cookie "path" trap and
> think they're safe when they're not.
>
>
>> The app can add its
>> own anti XSRF measure like what we have to do for HTTP but that's not
>> too easy.
>>
>> - Zhong Yu
>>
>
> Cheers,
> --
> Simon Pieters
> Opera Software
>