W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2010

Re: [minutes] 20101020 Web Performance

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Thu, 21 Oct 2010 12:07:11 +0200
To: public-web-perf@w3.org
Message-ID: <op.vkw7p9e341y844@id-c0735.oslo.opera.com>
On Wed, 20 Oct 2010 20:32:52 +0200, Anderson Quach <aquach@microsoft.com>  

> Sigborn: Should make the same domain be the same as the cookie domain, I  
> will write it up.

To explain my thoughts here in more detail. We are saying that any  
information should be same origin only, but "same origin" is different in  
different contexts, so we don't have to chose the most restricted  

I think the nomenclature is somewhat missing, let me explain what I mean  
by cookie domain, also called public suffix + 1 (pubsuff+1). Cookies can  
be set for www.yahoo.co.uk, yahoo.co.uk, but not co.uk or uk. Likewise (in  
most browsers), JavaScript's document domain have the exact same  
restrictions. mail.yahoo.co.uk can set a cookie for yahoo.co.uk, as well  
as set document.domain to that domain, and the cookie will be sent to  
www.yahoo.co.uk, and if www.yahoo.co.uk also sets the document.domain to  
yahoo.co.uk, then the mail and www domains can interact in JavaScript. Let  
us call the least restrictive, but allowed, domain for the "cookie  
domain", yahoo.co.uk in this case.

JavaScript is normally tied down to the maximum restriction, which can be  
loosened by Webmasters through document.domain. For indirect information  
such as Timing information, we can consider going for the least  
restrictive by default. Timing information is information only, so not a  
security issue, only privacy issues. I *think* we can live with privacy  
issues between subdomains underneath the same cookie domain.

There are a couple of potential issues, e.g. dyndns[1] uses separate  
subdomains for separate clients, so do some web hosting companies, e.g.  
Netfirms[2]. This means there is the potential for information leakage  
between separate web sites, though I think this is not critical. Most  
large websites operate on their own domain, and most of such subdomain  
websites are information only, rarely important logins with sensitive  
data, and are likely not worthwhile attack targets for black hats either.  
Such sites already need to take special care to avoid subtle cookie  
security issues[3]. Opera's "Webserver in a browser" solution would have  
been vulnerable (users get subdomains called <username>.operaunite.com),  
if we hadn't already added operaunite.com to the public suffix list[5],  
which is being used by multiple browsers to determine the cookie domains.

So I propose we consider using the cookie domain (the least restrictive  
setting possible with JavaScript's same origin policy) for all instances  
in Timing when we evaluate something to be same origin. This allows  
mail.yahoo.com to get the redirectCount from auth.yahoo.com, and image  
loading data from img.yahoo.com. This needs to be explicitly approved by  
the various security teams.

[1] http://www.dyndns.com/

[2] http://www.netfirms.com/

[3] Remember that another site underneath the same cookie domain can set a  
cookie for the cookie domain, which will then be sent to the attacked site  
when the user later visits the attacked site. Current cookie  
specifications do not send the domain with the cookie, so there is no way  
for the attacked site to see if the cookie it receives is such a master  
cookie. This can lead to various issues, for instance cookie injection and  
a user later logging on with a unique token given by the attacker - and  
the attacker can then also log on as the user. Nothing the site cannot  
protect itself against (by altering the cookie token whenever logging a  
user on), but it needs special care against threats which do not exist on  
a separate domain.

[4] http://unite.opera.com/overview/

[5] http://publicsuffix.org/, see /learn/ for some examples of how it is  

Sigbjørn Vik
Quality Assurance
Opera Software
Received on Thursday, 21 October 2010 10:07:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:29 UTC