W3C home > Mailing lists > Public > public-web-security@w3.org > May 2012

Re: same-origin assertions in the DNS (Fwd: [apps-discuss] draft-sullivan-domain-origin-assert-00)

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 09 May 2012 22:10:34 -0700
Cc: Thomas Roessler <tlr@w3.org>, public-web-security <public-web-security@w3.org>, Andrew Sullivan <ajs@anvilwalrusden.com>
Message-id: <CED6DC0F-C124-444B-8719-9BE8B72A7A99@apple.com>
To: Peter Saint-Andre <stpeter@stpeter.im>

On May 6, 2012, at 6:17 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> On 5/5/12 4:17 AM, Thomas Roessler wrote:
>> For your information:
>> 	http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-00
>> This seems targeted at situations where different domain names want to assert that they're something like same-origin, and for use by security policies implemented in browsers.
> Hi Thomas,
> Having talked with Andrew and other folks quite a bit about this topic
> (most recently at IETF 83), I'd say that ultimately it is directed at
> finding a way to build a scalable approach to solving the same problem
> that is solved right now with the public suffix list.

The Internet-Draft is pretty vague about what browsers should do with this info, but it states:

"Examples include decisions about acceptance of cookies and about cross-document information sharing in ECMAScript DOM."

So it seems that it's meant to affect both same-origin calculations and cookie suffix validity calculations.

Treating separate domains as same-origin based on DNS records seems extremely dangerous, with little counter-balancing benefit (it would not actually be usable until implemented in a large majority of browsers, and there's safer ways to communicate between different origins). In addition to the obvious XSS dangers, consider also how this feature might combine with DNS rebinding attacks.

As for using this information to replace the public suffix list, I think the detailed processing rules would have to be spelled out to see if this is better than the central list, and whether it is practically deployable while the public suffix list still exists.

Additionally, using the same DNS record to affect both same-origin calculations and cookie suffix validity seems needlessly risky, since these two notions of sameness have very different security implications. You may well want to control them separately.

And finally, this draft does not account for the scheme and port, which are also part of the origin tuple.

Received on Thursday, 10 May 2012 05:11:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:20 UTC