W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] AppCache Content-Type Security Considerations

From: Eduardo' Vela\ <evn@google.com>
Date: Tue, 13 May 2014 12:29:08 -0700
Message-ID: <CAFswPa8GKD4twftYogYbu6UEUBFhTykcT5-q5LA4RVMTXdxMsQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@lists.whatwg.org>, Adam Barth <w3c@adambarth.com>, Michal Zalewski <lcamtuf@coredump.cx>
Thanks!

Just to ensure this wasn't lost in the thread.

What about X-Content-Type-Options: nosniff?

Could we formalize it and remove the X and disable sniffing all together?


On Tue, May 13, 2014 at 12:06 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 13 May 2014, Eduardo' Vela\" <Nava> wrote:
> > >
> > > 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.
>
> It doesn't necessarily allow RCE, but sure.
>
>
> > > 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).
>
> Well, you have to "upload" two files for this vulnerability, right: an
> HTML file with a manifest="" that points to the manifest, and the manifest
> itself. Both are things that could be detected. Of course, the assumption
> is that there's a vulnerability in the first place, so we can just assume
> that any mitigations to detect these uploads are also broken...
>
> The reason I was initially talking about detecting these files is that I
> was imagining a situation where there was a site used for shared static
> hosting, where one of the people legitimately uploading files was
> (intentionally or not) causing the whole domain to get caught in their
> manifest's fallback rule. In that situation, one can just block all
> manifests by scanning for them (or for HTML files with manifest=""
> attributes). Also, in those situations, MIME type checks are less likely
> to be helpful since you'd need to give these users the ability to set MIME
> types. For this kind of situation, path restrictions would work well, I
> think, assuming you isolate each user to a different path.
>
> But in the case of arbitrary upload vulnerabilities, I agree that these
> mitigations are moot.
>
> In the case of arbitrary upload vulnerabilities, I don't really think any
> solution is going to be convincing short of dropping the FALLBACK feature,
> because fundamentally being able to capture the entire domain to persist
> the existence of content into the future when it's no longer being served
> is the entire point of the feature.
>
>
> > > > > "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.
>
> We should make sure this is indeed followed up upon.
>
>
> > 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.
>
> Ok. Let me know when you want me to change the spec. :-)
>
>
> > > Are the lessons learnt here being reported to the Service Worker team?
> >
> > Yup, who is that?
>
> I believe Alex Russel is the point person on that technology.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Tuesday, 13 May 2014 19:29:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC