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: Wed, 11 Feb 2009 14:36:50 -0800
Message-ID: <7789133a0902111436w72024636p23da5c4db746c2cb@mail.gmail.com>
To: Breno de Medeiros <breno@google.com>
Cc: Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>

On Wed, Feb 11, 2009 at 2:15 PM, Breno de Medeiros <breno@google.com> wrote:
> 1. The mechanism is not sufficient strong to prevent against defacing
> attacks.

We're not worried about defacement attacks.  We're worried about Web
servers that explicitly allow their users to upload content.  For
example:

1) Webmail providers (e.g., Gmail) let users upload attachments.
2) Forums let users upload avatar images.
3) Wikipedia lets users upload various types of content.

> An attacker that can upload a file and choose how to set the
> content-type would be able to implement the attack. If servers are willing
> to let users upload files willy-nilly, and do not worry about magical paths,
> will they worry about magical content types?

In fact, none of these servers let users specify arbitrary content
types.  They restrict the content type of resources to protect
themselves from XSS attacks to an to ensure that they function
properly.

> 2. This technique may prevent legitimate uses of the spec by developers who
> do not have the ability to set the appropriate header.

Many developers can control Content-Type headers using .htaccess files
(and their ilk).

> Is this more likely to prevent legitimate developers from getting things
> done than to prevent attacks from spoofing said magical paths? I would say
> yes.

What is your evidence for this claim?  My evidence for this being a
serious security issue is the experience of Adobe with their
crossdomain.xml file.  They started out with the same design you
currently use and were forced to add strict Content-Type handling to
protect Web sites from this very attack.  What is different about your
policy file system that will prevent you from falling into the same
trap?

> Defacing attacks are a threat to applications relying on this spec,

We're not talking about defacement attacks.

> and they
> should be explicitly aware of it rather than have a false sense of security
> based on ad-hoc mitigation techniques.

This mechanism does not provide a false sense of security.  In fact,
it provides real security today for Adobe's crossdomain.xml policy
file and for a similar Gears feature.  (Gears also started with your
design and was forced to patch their users.)

Adam
Received on Wednesday, 11 February 2009 22:37:30 GMT

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