W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2009

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 23 Feb 2009 11:34:17 -0800
Message-ID: <7789133a0902231134r42c56fddk76bbc6dd94e49ed7@mail.gmail.com>
To: Breno de Medeiros <breno@google.com>
Cc: Ben Laurie <benl@google.com>, Mark Nottingham <mnot@mnot.net>, Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
On Mon, Feb 23, 2009 at 10:13 AM, Breno de Medeiros <breno@google.com> wrote:
> Every application _will_ need to use different processing rules, because,
> well, they are interested in different things.

Applications will be interested in different facts in the host-meta
store, but why should they use different procedures for obtaining the
host-meta store?  They might as well use different stores entirely.

> What is the attack model here? I assume is the following: The attacker
> compromises the server to serve a re-direct when there should be a file
> served (or a 404). Well, the attacker can't upload a host-meta with what it
> wants in it? Why?

Often users can add redirects to a server without the ability to
upload content to that serve.  For example, tinyurl.com/host-meta now
redirects to a URL I control even though I have no ability to upload
content to tinyurl.com.  Why should I be able to set host-meta
properties for tinyurl.com?

> Perhaps that argument would be more convincing when you provide an example
> of an attack made possibly by introduction of a redirect that would not be
> possible by, say, adding a line to the host-meta file.

Ok.  I own tinyurl.com's host-meta store because of redirects.
Without redirects, I don't know how to own their host-meta store.

Adam
Received on Monday, 23 February 2009 19:35:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:30 GMT