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: Wed, 11 Feb 2009 15:32:12 -0800
Message-ID: <29fb00360902111532pfc5ca7clc2caf517232b8d86@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
On Wed, Feb 11, 2009 at 3:22 PM, Adam Barth <w3c@adambarth.com> wrote:

> On Wed, Feb 11, 2009 at 2:46 PM, Breno de Medeiros <breno@google.com>
> wrote:
> > However, such applications could handle
> > specifying content-type as a requirement, as Eran rightly pointed out.
> Why force everyone interested in use case (1) to add this requirement?
>  This will have two results:
> 1) Some application will forget to add this requirement and be
> vulnerable to attack.
> 2) A service that requires the well-known Content-Type will not be
> able to inter-operate with a server that takes advantage of the laxity
> of this spec.
> >> What is different about your
> >> policy file system that will prevent you from falling into the same
> >> trap?
> >
> > The difference being that cross-domain.xml is intended primarily for
> browser
> > use and therefore optimization for that case sounds legitimate. This is
> not
> > the case here.
> We're discussing security-critical server-to-server discovery, which
> is the first use-case you listed.

In that case, content-type is a mild defense. Can you give me an example
where a web-site administrator will allow files to be hosted at '/'? I can
find some fairly interesting names to host at '/'

E.g.: favicon.ico, .htaccess, robots.txt, ...

Trying to secure such environments seems to me a waste of time, quite

The most interesting threat of files uploaded to root is via defacement.
This solution does nothing against that threat.

> > Again, again, there is an application layer where browsers can implement
> > such policies.
> Sure, you can punt all security problems to the application layer
> because I can't construct attacks without a complete system.
> It sounds like there are three resolutions to this issues:
> 1) Require host-meta to be served with a particular, novel Content-Type.

Not feasible, because of limitations on developers that implement these
server-to-server techniques.

> 2) Add a section to Security Considerations that explains that
> applications using host-meta should consider adding requirement (1).

No. I would suggest adding a Security Considerations that say that host-meta
SHOULD NOT be relied upon for ANY security-sensitive purposes _of_its_own_,
and that applications that require levels of integrity against defacement
attacks, etc., should implement real security techniques. Frankly, I think
content-type does very little for security of such applications.

> 3) Ignore these attacks.
> My opinion is that (3) will cause users of this spec a great deal of
> pain.  I also think that (2) will cause users of this spec pain
> because they'll ignore the warning and construct insecure systems.
> By the way, there is a fourth solution, which I suspect you'll find
> unappealing for the same reason you find (1) unappealing: use a method
> other than GET to retrieve host-meta.  For example, CORS uses OPTIONS
> for a similar purpose.
> 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 Wednesday, 11 February 2009 23:32:54 UTC

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