Re: [hybi] Concerns about Origin

["Simon Pieters" <[e-mail]>]

On Mon, 22 Nov 2010 19:46:53 +0100, Zhong Yu <[e-mail]> wrote:

> 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?

I don't know, I assumed it is allowed because it would be simpler to  
implement in some situations (you don't need to check the origin the  
client sent)... Does it cause a problem in practice?


>> 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.

Yeah, I agree that it is better than allowing connections from anywhere by  
default (could default protocol to 'http:' and maybe port to 80). I  
haven't given it much thought about whether it's always 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?

http://www.webappsec.org/lists/websecurity/archive/2006-03/msg00000.html

(via  
http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html  
)

>>
>>> 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.

-- 
Simon Pieters
Opera Software