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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Content-Type Security Considerations
On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote: On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch 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\ Nava 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 (script, style, object, etc), based on strong evidence of previous mishaps; to the extent that the spec diverges from this, I suspect that it will be only a source of confusion and incompatibility. /mz
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: img src=foo ... ...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 (script, style, object, etc), based on strong evidence of previous mishaps; to the extent that the spec diverges from this, I suspect that it will be only a source of confusion and incompatibility. Actually as far as I can tell we're converging on a hybrid model, more or less the one specified here: http://mimesniff.spec.whatwg.org/ -- 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 9:38 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 12 May 2014, Eduardo' Vela\ Nava wrote: On Mon, May 12, 2014 at 4:17 PM, Ian Hickson i...@hixie.ch 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\ Nava 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? Should I add the path restriction to fallback? (Is that compatible enough? Do we have data on that?) Should we add CSP directives for
Re: [whatwg] AppCache Content-Type Security Considerations
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. `._.-(,_..'--(,_..'`-.;.'
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 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. `._.-(,_..'--(,_..'`-.;.'
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 i...@hixie.ch 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\ Nava 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 i...@hixie.ch wrote: On Tue, 13 May 2014, Eduardo' Vela\ Nava 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 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. 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: 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. /mz
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 lcam...@coredump.cxwrote: 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. /mz
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 lcam...@coredump.cxwrote: 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 Nava e...@google.comwrote: 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 lcam...@coredump.cxwrote: 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 Mon, 12 May 2014, Eduardo' Vela\ Nava 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 i...@hixie.ch wrote: On Mon, 12 May 2014, Eduardo' Vela\ Nava 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 script or a @import) should be able to make decisions re the way to parse the data it receives. 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. I agree it's a tough problem, and I was hoping we could find another solution :) (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). 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. Yes, I agree. This was an example of a simple client DoS attack. 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. The problem I see with the CSP approach is that only pages that have CSP will be protected. 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. This is how crossdomain.xml works, so it might make sense. But I'm not sure if that would be sufficient. -- 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 i...@hixie.ch wrote: On Mon, 12 May 2014, Eduardo' Vela\ Nava 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
