- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Thu, 21 Oct 2010 12:07:11 +0200
- To: public-web-perf@w3.org
On Wed, 20 Oct 2010 20:32:52 +0200, Anderson Quach <aquach@microsoft.com> wrote: > 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 interpretation. 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/ http://www.google.no/search?client=opera&rls=en&q=site:dyndns.org&sourceid=opera&ie=utf-8&oe=utf-8 [2] http://www.netfirms.com/ http://www.google.no/search?hl=no&client=opera&hs=qLs&rls=en&q=site%3Anetfirms.com&aq=f&aqi=&aql=&oq=&gs_rfai= [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 used. -- Sigbjørn Vik Quality Assurance Opera Software
Received on Thursday, 21 October 2010 10:07:29 UTC