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