Re: [whatwg] AppCache Content-Type Security Considerations

On Tue, 13 May 2014, Eduardo Vela wrote:
> > On Tue, 13 May 2014, Eduardo' Vela\" <Nava> wrote:
> > >
> > > What about X-Content-Type-Options: nosniff?
> > >
> > > Could we formalize it and remove the X and disable sniffing all 
> > > together?
> >
> > Do you mean for manifests specifically, or more generally?
>
> I agree it's wrong to do it as a one-off, so was hoping to make it more 
> generally (since there seems to be a move on moving out of the CT 
> model).

I don't think removing sniffing in general is ever going to happen, if for 
no other reason than for many types it's just trivial to sniff and very 
unlikely to go wrong (e.g. binary image types).


> If that's not OK, then CSP is probably a reasonable way forward (I'll 
> take a look at the Service Worker thread to ensure we have a similar 
> mitigation in place).

Yeah, CSP seems like the logical way to do this.


On Tue, 13 May 2014, Michal Zalewski wrote:
> >
> > I disagree. Much of the Web actually relies on this today, and for the 
> > most part it works. For example, when you do:
> >
> >    <img src="foo" ...>
> >
> > ...the Content-Type is ignored except for SVG.
> 
> Well, <img> is actually a fairly special case of content that is 
> difficult for attackers to spoof and that can't be easily read back 
> across domains without additional CORS headers. But I believe that in 
> Chrome and in Firefox, C-T checks or other mitigations have been 
> recently added at least <script>, <link rel=stylesheet>, and <object> / 
> <embed>, all of which lead to interesting security problems when they 
> are used to load other types of documents across origins. Similar 
> changes are being made also for a couple of other cases, such as <a 
> download>.

<script> is news to me. Per spec it has no sniffing or Content-Type 
checking, it just assumes text/javascript. <object>/<embed>, at least if 
it matches the spec's Content-Type requirements, still involves plenty of 
sniffing. <link rel=stylesheet> has required text/css for some time. CSS 
is a text format with no signature so there's no good way to sniff it.


On Tue, 13 May 2014, Eduardo' Vela\" <Nava> wrote:
>
> If CSS, JS and plugins had magic numbers at the beginning of the file, 
> then that would prevent the issues that you are discussing right?

Some of them.


> I think that's Ian's point, that for those file types, we need CT, but 
> for others, like manifest files, and image and plugins we shouldn't 
> need.

Right.


> PDFs, and JARs are a special case here, since they scan the content 
> (first N bytes, or last N bytes) for the signature, but if the content 
> match was done for the exact first byte, then this would help prevent 
> security issues I think?

Having a loose signature is problematic, indeed. Note that the MIME 
Sniffing spec, for PDF, doesn't allow scanning.


On Tue, 13 May 2014, Michal Zalewski wrote:
> 
> If we take this route, I think we'd be essentially making sure that many 
> web applications that are safe today will gradually acquire new security 
> bugs out of the blue as the UA "magic signature" detection logic is 
> extended in the future (as it inevitably will - to account for new 
> plugins, new formats with scripting capabilities or other interesting 
> side effects, etc).
>
> An out-of-band signalling mechanism has far superior security properties 
> compares to an in-band one, given how many if not most web apps are 
> designed today. It may be that they are designed the "wrong" way, but 
> the security rules were never particularly clear, and serving content 
> off-domain added a lot of complexity around topics such as auth, so I 
> think it's best to be forgiving and accommodate that. The examples of 
> CSV exports, text documents, and several more exotic things aside, most 
> JSONP APIs give the attacker broad control over the first few bytes of 
> the response.

I agree that out-of-band signalling has some security advantages, but I 
think they are far outweighed by the costs of configuring out-of-band 
signalling in practice.

Either way, the Web now is in this weird mix of both approaches, and 
we're unlikely to be able to do anything about that.


On Tue, 13 May 2014, Eduardo' Vela\" <Nava> wrote:
>
> @Ian, is there a way to find out what was the Content-Type that the 
> authors that complained were getting?
> 
> Hopefully we can figure out a list of Content-Types that are unlikely to 
> cause security problems?

I think the mitigation in the spec (scoping the fallbacks to the manifest 
URL path) is probably sufficient. It means you can only take over the part 
of the site that has the upload vulnerability. Supporting just the default 
types is unlikely to help, since those are the types most likely to be 
used to label an uploaded file in this scenario.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 26 September 2014 23:44:25 UTC