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 13:04:38 -0800
Message-ID: <29fb00360902231304qa4519fua2fffec247a161ec@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 12:16 PM, Adam Barth <w3c@adambarth.com> wrote:

> On Mon, Feb 23, 2009 at 11:47 AM, Breno de Medeiros <breno@google.com>
> wrote:
> > Or they may have to do it because host-meta does not allow redirects and
> > they need it. I wonder what is more likely.
> One solution is to add content to a host-meta file that says where to
> find the host-meta file:
> My-Host-Meta-Is-Located-At: http://www.example.com/my-favorite-host-meta
> This has the advantage of not introducing vulnerabilities into existing
> servers.
> > Because tinyurl.com allows you to do this.
> Yes.  Precisely.  Following redirects introduces a vulnerability into
> tinyurl.com.  That is why I recommend not following redirects.

No, it does not. It does introduce vulnerabilities to clients that visit
tinyurl.com with the expectation that they will interpret some metadata at
tinyurl.com to achieve specific aims. Simply substituting tinyurl.com's
host-meta affects no one until tinyurl.com starts exposing some type of
service or application that client apps might want to configure/discover
using host-meta.

As for your example of default charsets, where you are using a browser to
define a generic interpretation of how to use host-meta to discover default
charsets, it sounds like such API would need to be designed as:

getHostMetaValue(URL resource_url, String host_meta_key, boolean

which hardly sounds to me like a burden.

> I don't know how to make a more compelling case for security than
> supplying a working proof-of-concept exploit that required all of five
> seconds to create on one of the world's most popular sites.
> > I am more imaginative: I could do DNS spoofing,
> DNS spoofing requires a lot more work (i.e., a more powerful attacker)
> than abusing redirects.
> > or I could choose another
> > site to hack that is actually more interesting that tinyurl.
> So we shouldn't care about introducing vulnerabilities into tinyurl
> because we don't think they are important enough?
> 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 21:05:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:07 UTC