Re: [whatwg] AppCache Content-Type Security Considerations

On Tue, May 13, 2014 at 9:38 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 12 May 2014, Eduardo' Vela\" <Nava> wrote:
> > On Mon, May 12, 2014 at 4:17 PM, Ian Hickson <ian@hixie.ch> wrote:
> > >
> > > Note that there _is_ still a content type check with appcache, it's
> > > just done on the first few bytes of the file instead of on the
> > > metadata. (This is IMHO how all file typing should work.)
> >
> > This seems to imply MIME types should always be ignored, is that
> > actually the case?
>
> Only for Appcache and other formats that have unambiguous signatures, like
> PNG, GIF, etc.
>
>
> > I mean, it's clearly possible to have a file that is both, valid CSS and
> > valid JS.
>
> CSS, JS, HTML, etc, are IMHO poorly designed text formats, since they
> don't have a defined fixed signature. So for those, we need Content-Type.
>
>
> > > (The Content-Type is a bit of a red herring here. If you can prevent
> > > the attacker from overriding the Content-Type, you can prevent them
> > > from sending the appcache signature also.)
> >
> > The author feedback that made the CT check to be dropped is that it was
> > too hard for authors to set CT, but it was easy to set the appcache
> > signature.
> >
> > The "attacker" will usually have the same (and more) constrains than
> > what the author has (although, attackers might be more tech savy than
> > their victim site owners in some cases).
> >
> > In usual (and complex) web applications, it's not as common to be able
> > to set the Content Type as it is to be able to control the first few
> > bytes (think JSONP endpoints for example - but exporting data in text
> > format is another example).
>
> I agree that you're less likely to be able to control the headers. But I
> don't think that's enough. A big part of the reason that authors find it
> hard to set HTTP headers is that doing so is technically complicated, not
> that it's impossible. If an attacker is putting files on an Apache server
> because there's some upload vulnerability, it becomes trivial to set the
> HTTP headers: just upload a .htaccess file.
>

Uploading a .htaccess file is a significantly greater vulnerability than
XSS, as it allows RCE, and we are concerned here about vulnerabilities that
don't just allow the user to upload files, but rather to serve files from a
web service. The later are more common than the former.


> My point, though, was from the other angle. If you can _prevent_ someone
> from setting HTTP headers somehow, you can equally prevent them from
> uploading files that match a signature.
>
It's not that simple, it's not just about uploading files, it's about
serving content that "looks like" manifest files, but actually aren't.
Similar to XSS (note the docs attached to my OP like
http://www.cse.chalmers.se/~andrei/ccs13.pdf for examples).

In any case, requiring HTTP headers for appcache was very poorly received.
> I don't think we should return to requiring them. Aside from the fact that
> it would break a lot of sites, it would also mean ignoring pretty clear
> author feedback.
>
I totally agree, I apologize if the email seemed to imply I was asking for
the decision to be revoked (I tried to ensure it didn't, but it did).

 > > "Cookie Bombing" (causing the user agent to send an HTTP request
> > > that's bigger than the server accepts) should IMHO be resolved by
> > > setting an upper limit on what clients can send in cookies, and having
> > > user agent enforce this limit. Server would then know that they need
> > > to support that much and no more for cookies.
> >
> > Yes, I agree. This was an example of a simple client DoS attack.
>
> Is fixing Cookie Bombing being tracked by anyone?

This would be in IETF I assume? I don't know how that process works, we can
follow up offline.


>  > > On Mon, 12 May 2014, Eduardo' Vela\" <Nava> wrote:
> > > >
> > > > One idea is with a special CSP policy that forbids manifest files
> > > > from working without the right CT
> > >
> > > I don't think limiting it to Content-Types is a real fix, but we could
> > > mark, with CSP, that the domain doesn't support appcache at all.
> >
> > The problem I see with the CSP approach is that only pages that have CSP
> > will be protected.
>
> Well, that's true of anything involving CSP.
>
Yes, but we need to protect all of Google services (in an origin =/).

 > > We could, though, say that a manifest can only do fallbacks for URLs
> > > that are within the subpath that the manifest finds itself in. That
> > > would be an interesting way of scoping manifests on shared domains.
> >
> > This is how crossdomain.xml works, so it might make sense. But I'm not
> > sure if that would be sufficient.
>
> Well, all of this is defense in depth, essentially. So strictly speaking
> none of it is necessary. Obviously the deeper the defense, the better; but
> we shouldn't go so deep as to make the feature unusable. (I mean, we could
> have really _good_ defense by just dropping the feature entirely.)
>
>
> So, moving forward, what do we want to do? Should I add the path
> restriction to fallback? (Is that compatible enough? Do we have data on
> that?) Should we add CSP directives for this? Something else?
>
Before we add changes, let's figure out what's the best path forward. I
think that's a reasonable proposal, but I am hoping we can come up with a
better one, as I don't feel it's yet sufficient.

Are the lessons learnt here being reported to the Service Worker team?

Yup, who is that?


>
> On Mon, 12 May 2014, Michal Zalewski wrote:
> >
> > Yup, from the perspective of a significant proportion of modern
> > websites, MIME sniffing would be almost certainly a disaster.
>
> I'm not suggesting sniffing, I'm suggesting having a single well-defined
> algorithm with well-defined fixed signatures.
>
> For formats that don't have signatures, this doesn't work, obviously.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Tuesday, 13 May 2014 18:36:42 UTC