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: Breno de Medeiros <breno@google.com>
Date: Mon, 23 Feb 2009 11:47:51 -0800
Message-ID: <29fb00360902231147m1f6d1724r8232cd4f76c6fb81@mail.gmail.com>
To: Adam Barth <w3c@adambarth.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 11:34 AM, Adam Barth <w3c@adambarth.com> wrote:

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

Or they may have to do it because host-meta does not allow redirects and
they need it. I wonder what is more likely.

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

Because tinyurl.com allows you to do this.

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

I am more imaginative: I could do DNS spoofing, or I could choose another
site to hack that is actually more interesting that tinyurl. After all,
tinyurl is just a gigantic open redirector so it is already an enormous
security nightmare for many reasons like phishing attacks and malware
distribution. But maybe then I would have to come up with a less contrived

> Adam


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
Received on Monday, 23 February 2009 19:48:30 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:31 UTC