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.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to