Re: [hybi] Concerns about Origin

"Simon Pieters" <simonp@opera.com> Mon, 22 November 2010 16:37 UTC

Return-Path: <simonp@opera.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3443B3A6AD2 for <hybi@core3.amsl.com>; Mon, 22 Nov 2010 08:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.092
X-Spam-Level:
X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hb0qt9sEJsr for <hybi@core3.amsl.com>; Mon, 22 Nov 2010 08:37:25 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 1CD6B3A6A9B for <hybi@ietf.org>; Mon, 22 Nov 2010 08:37:24 -0800 (PST)
Received: from dhcp-190.linkoping.osa (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oAMGcGnA008149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Nov 2010 16:38:17 GMT
Content-Type: text/plain; charset="utf-8"; format="flowed"; delsp="yes"
To: Zhong Yu <zhong.j.yu@gmail.com>
References: <op.vmkpgllmidj3kv@simon-pieterss-macbook.local> <AANLkTi=hVXa1yFbLr-pRS25gA2F__X3bM9w08O99my6s@mail.gmail.com>
Date: Mon, 22 Nov 2010 17:38:52 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Simon Pieters <simonp@opera.com>
Message-ID: <op.vmky62ixidj3kv@dhcp-190.linkoping.osa>
In-Reply-To: <AANLkTi=hVXa1yFbLr-pRS25gA2F__X3bM9w08O99my6s@mail.gmail.com>
User-Agent: Opera Mail/11.00 (MacIntel)
X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Concerns about Origin
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2010 16:37:26 -0000

On Mon, 22 Nov 2010 17:07:46 +0100, Zhong Yu <zhong.j.yu@gmail.com> 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.  
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...


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


> 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