[whatwg] AppCache Content-Type Security Considerations
Hi! In the following bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14701the Content-Type requirement for AppCache manifest files was dropped, and the security implications of such change probably weren't fully understood at that time, and we want to start a discussion on this topic to ensure we aren't doing something that might put some websites in danger. First of all, to provide some background and establish a common ground. The only security mechanism effectively provided by the browser is the web origin[1], and those protections are commonly used across the industry to isolate and protect user-provided content[2]. This allows, for example, users to have blogs and websites well isolated from each other. We can easily justify creating an isolated origin for active content like HTML files and so on, and every web author should do just that. However, some files can be created in a safe format (such as a CSV file, or a JSON response, or even an HTML file), and the Content-Type can be set correctly (instructing the browser how it intends the data to be rendered) and give the impression the file hosting is safe, when it actually isn't. We used to see this problem before for Content-Type sniffing[3], in which the browser would disregard the Content-Type of an HTTP request, but new mechanisms such as X-Content-Type-Options: nosniff would come and save the day. Today, for instance, TDC files[4], or PDF files[5], and before we had JAR files[6], and we've seen similar problems arise from SWF files[7] and crossdomain.xml files[8] resulting in a similar consequence. Historically these are all have been browser plugins and extensions that create these problems. We worked with the plugin maintainers to respect Content-Type, or provide mechanisms to allow web authors to opt-out of the default insecure behavior[9] (which is arguably very bad and wrong, as anyone that doesn't know about this will be easily vulnerable =/, but I digress). There are also "arbitrary" rules that make development somewhat safer against future problems (thou shall not let the user control the first byte of an HTTP response, thou shall not let the user inject NULL bytes or malformed UTF-8 sequences, thou shall not let the user control the content-type of an HTTP response). Now, with appcache manifest files, we are introducing a security-sensitive change based on a file with special powers (more on this later), and while before they were guarded by a Content-Type check, this isn't the case anymore. We understand a lot of author feedback came into play when making this decision of ignoring Content-Type, and we are not asking to revert it. But rather, we want to ensure the risk is clearly understood, and the solution codified in the standard balances the security risk with the usability of the feature by web authors. To clearly explain the risk, I'll lay down two use cases where this is going to worsen things somewhat: 1. When there is an XSS in your favorite website, and you are infected with it. Thanks to FALLBACK the attacker can make it so that you can never recover from the XSS (and be "infected" for ever). The way to do this is by finding an endpoint in the vulnerable web application that lets you generate a file that looks like a manifest file (this isn't hard - really), and then force the browser to use it via your XSS. The way you make sure FALLBACK triggers every time (and not just when the user is offline) is by means of Cookie Bombing [10]. While similar attacks were already possible before via other mechanisms [11] such as localStorage and the FileSystem API and such, they were always kept at bay, and this makes things worse. 2. CDNs and similar sites can be completely taken over for all the HTML hosted in them. They will effectively break and reach an irrecoverable state. While this isn't the case for resources like JS files, HTML files enough are already a concern. This attacks are particularly scary because they allow attackers to do things that before wasn't possible. In specific persist access to their victim's web application. We can clearly mitigate the risk in many ways. One idea is with a special CSP policy that forbids manifest files from working without the right CT, or by means of per-page suborigins[12] (which reaches a similar deal-with-the-devil as crossdomain.xml files and Adobe), but in an ideal world, we wouldn't have this problem in the first place. Another alternative is to enforce and codify the semantics of X-Content-Type-Options: nosniff for AppCache manifest files. If we do nothing, it will significantly change the way we all have been treating secure web content hosting, so let's to make sure all the security implications are understood now, rather than later. Thanks!! [1] http://tools.ietf.org/html/rfc6454 [2] https://plus.sandbox.google.com/+EduardoVelaNava/posts/4riSfqjx2bj [3] http://msdn.microsoft.com/en-us/library/ms775147.aspx [4] http://msdn.microsoft.com/en-us/library/ms531356%28v=VS
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, 12 May 2014, Eduardo' Vela\" wrote: > > Now, with appcache manifest files, we are introducing a > security-sensitive change based on a file with special powers (more on > this later), and while before they were guarded by a Content-Type check, > this isn't the case anymore. 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.) > 1. When there is an XSS in your favorite website, and you are infected > with it. Thanks to FALLBACK the attacker can make it so that you can > never recover from the XSS (and be "infected" for ever). The way to do > this is by finding an endpoint in the vulnerable web application that > lets you generate a file that looks like a manifest file (this isn't > hard - really), and then force the browser to use it via your XSS. I don't really see a way to really fix this short of dropping FALLBACK support entirely. (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 way you make sure FALLBACK triggers every time (and not just when > the user is offline) is by means of Cookie Bombing. While similar > attacks were already possible before via other mechanisms such as > localStorage and the FileSystem API and such, they were always kept at > bay, and this makes things worse. "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. > 2. CDNs and similar sites can be completely taken over for all the HTML > hosted in them. They will effectively break and reach an irrecoverable > state. While this isn't the case for resources like JS files, HTML files > enough are already a concern. When you're online, only resources that actually specify the given manifest can be taken over. > 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. > or by means of per-page suborigins I don't know that we need to go to that length. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson wrote: > On Mon, 12 May 2014, Eduardo' Vela\" wrote: > > > > Now, with appcache manifest files, we are introducing a > > security-sensitive change based on a file with special powers (more on > > this later), and while before they were guarded by a Content-Type check, > > this isn't the case anymore. > > 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? I mean, it's clearly possible to have a file that is both, valid CSS and valid JS. I think what you actually mean is that the browser (with the context it has, such as, being included in a
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, May 12, 2014 at 4:17 PM, Ian Hickson wrote: > On Mon, 12 May 2014, Eduardo' Vela\" wrote: >> Now, with appcache manifest files, we are introducing a >> security-sensitive change based on a file with special powers (more on >> this later), and while before they were guarded by a Content-Type check, >> this isn't the case anymore. > > 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.) There's a big difference between the first few bytes of a file and the Content-Type HTTP header. In many scenarios, the former is under the control of an attacker when the latter is not. Adam
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, 12 May 2014, Eduardo' Vela\" wrote: > On Mon, May 12, 2014 at 4:17 PM, Ian Hickson 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. 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. 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. > > "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? > > On Mon, 12 May 2014, Eduardo' Vela\" 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. > > 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? Are the lessons learnt here being reported to the Service Worker team? 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
>> 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. We probably can't support a well-defined algorithm for detecting documents that have distinctive signatures while safely supporting formats that don't have them (because there is always a possibility that the non-structured format with user-controlled data could be used to forge a signature).
Re: [whatwg] AppCache Content-Type Security Considerations
> We probably can't support a well-defined algorithm for detecting > documents that have distinctive signatures while safely supporting > formats that don't have them (because there is always a possibility > that the non-structured format with user-controlled data could be used > to forge a signature). It can be argued that the burden of detecting this should be placed on the server before sending out the response, but this would be a fairly major shift in what is currently assumed to be the web security model (with detrimental effect on tens of thousands of existing web apps); on top of that, it would cripple some legitimate uses of the non-structured formats: for example, there may be perfectly legitimate reasons why a text/plain or text/csv document also matches a signature for HTML. In general, in the past, in pretty much every single instance where browsers tried to second-guess Content-Type or Content-Disposition headers - be it through sketchy proprietary content-sniffing heuristics or through well-defined algorithms - this ended up creating tons of hard-to-fix security problems and introduced new burdens for web developers. It looks elegant, but it's almost always a huge liability. I think that most or all browsers are moving pretty firmly in the other direction, enforcing C-T checking even in situations that historically were off-limits (
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Michal Zalewski wrote: > > We probably can't support a well-defined algorithm for detecting > documents that have distinctive signatures while safely supporting > formats that don't have them (because there is always a possibility that > the non-structured format with user-controlled data could be used to > forge a signature). Right. You'd have to check the Content-Type header first. On Tue, 13 May 2014, Michal Zalewski wrote: > > In general, in the past, in pretty much every single instance where > browsers tried to second-guess Content-Type or Content-Disposition > headers - be it through sketchy proprietary content-sniffing heuristics > or through well-defined algorithms - this ended up creating tons of > hard-to-fix security problems and introduced new burdens for web > developers. It looks elegant, but it's almost always a huge liability. I disagree. Much of the Web actually relies on this today, and for the most part it works. For example, when you do: ...the Content-Type is ignored except for SVG. > I think that most or all browsers are moving pretty firmly in the other > direction, enforcing C-T checking even in situations that historically > were off-limits (
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, May 13, 2014 at 9:38 AM, Ian Hickson wrote: > On Mon, 12 May 2014, Eduardo' Vela\" wrote: > > On Mon, May 12, 2014 at 4:17 PM, Ian Hickson 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\" 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? Shou
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Eduardo' Vela\" 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
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 wrote: > On Tue, 13 May 2014, Eduardo' Vela\" 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. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] AppCache Content-Type Security Considerations
(for context [tests] http://philip.html5.org/tests/ie8/cases/content-type-nosniff.html)
Re: [whatwg] AppCache Content-Type Security Considerations
On 13 May 2014 17:38, Ian Hickson wrote: > Are the lessons learnt here being reported to the Service Worker team? > Yes, I've been discussing this with them in https://github.com/slightlyoff/ServiceWorker/issues/224 and https://github.com/slightlyoff/ServiceWorker/issues/253, which is what led me to spot and report this vulnerability in AppCache to Eduardo et al in the first place. I'll make sure the Service Worker folks stay in sync with this thread.
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Eduardo' Vela\" wrote: > > 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? Do you mean for manifests specifically, or more generally? For manifests specifically, it seems like a very odd feature. "Manifests don't have a MIME type normally, but if served with this header, then you should also change how you determine if a manifest is a manifest"? If we just want a way to prevent pages that aren't supposed to be manifests from being treated as manifests, I think it'd be better to have a CSP directive that disables manifests. Then you would apply it to any resource you know you don't want cached, don't want to be treated as being able to declare a manifests, and don't want treated as a manifest. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, May 13, 2014 at 1:06 PM, Ian Hickson wrote: > On Tue, 13 May 2014, Eduardo' Vela\" wrote: > > > > 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? > > 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). 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). For manifests specifically, it seems like a very odd feature. "Manifests > don't have a MIME type normally, but if served with this header, then you > should also change how you determine if a manifest is a manifest"? > > If we just want a way to prevent pages that aren't supposed to be > manifests from being treated as manifests, I think it'd be better to have > a CSP directive that disables manifests. Then you would apply it to any > resource you know you don't want cached, don't want to be treated as being > able to declare a manifests, and don't want treated as a manifest. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] AppCache Content-Type Security Considerations
(for the sake of completeness) On Tue, May 13, 2014 at 12:06 PM, Ian Hickson wrote: > On Tue, 13 May 2014, Eduardo' Vela\" 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. Yes, not in all situations, but in some of them it does: https://github.com/wireghoul/htshells/tree/master/shell
Re: [whatwg] AppCache Content-Type Security Considerations
> I disagree. Much of the Web actually relies on this today, and for the > most part it works. For example, when you do: > > > > ...the Content-Type is ignored except for SVG. Well, 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
Re: [whatwg] AppCache Content-Type Security Considerations
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? 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. 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? On Tue, May 13, 2014 at 8:00 PM, 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: > > > > > > > > ...the Content-Type is ignored except for SVG. > > Well, 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
Re: [whatwg] AppCache Content-Type Security Considerations
> 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. 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. /mz
Re: [whatwg] AppCache Content-Type Security Considerations
So today, we need CT for JSONP and CSV. Those are the ones we *need* CT. The idea is to train the browser to recognize the CTs of formats that are ambiguous. On Tue, May 13, 2014 at 8:26 PM, Michal Zalewski wrote: > > 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. > > 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. > > /mz >
Re: [whatwg] AppCache Content-Type Security Considerations
@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? On Tue, May 13, 2014 at 8:32 PM, Eduardo' Vela" wrote: > So today, we need CT for JSONP and CSV. Those are the ones we *need* CT. > > The idea is to train the browser to recognize the CTs of formats that are > ambiguous. > > > > On Tue, May 13, 2014 at 8:26 PM, Michal Zalewski wrote: > >> > 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. >> >> 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. >> >> /mz >> > >
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Eduardo Vela wrote: > > On Tue, 13 May 2014, Eduardo' Vela\" 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: > > > > > > > > ...the Content-Type is ignored except for SVG. > > Well, 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
