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

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

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
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)