Loading…
SRI: Add section Security Considerations: Behavior of chameleon resources #302
6 participants
I'd like to think I choose my terms carefully, but here I'm using "resource" "content" and "document" to mean essentially the same thing. What's the preferred term?
Consider that the integrity attribute is tied to it's use case, i.e. the HTML tag. We do not have the common issue of images containing scripts, because why the would a web developer (or some sort of software) ever compute a hash and then include an image resource by using a script tag?
I am not opposed to your pull request, just a bit curious: How likely do you think is it that a web developer will hash something that is more than one file? For scripts I would expect this to be rather obvious.
Right, I'm not sure I can come up with any workable example that would actually be outright malicious at this time. But the functionality of "integrity" is liable to expand in the future, and therefore create more cases where people think "integrity" makes it safe to store documents on an untrusted server. The current draft specifically proposes adding integrity to CSS url() references.
This is mostly inspired by https://bugzilla.mozilla.org/show_bug.cgi?id=470041. Although caused by the embedding page changing the media type of the target script (in violation of its advertised Content-Type), it was a result of parsing JSON as JavaScript.
The primary point is that "integrity" isn't an excuse to relax security standards, it supplements existing ones.
Hey, could some other editor chime in? cc @metromoxie @devd @fmarier
This is an interesting contribution, given that there's a duplicate issue now ;)
I think this can be phrased more simply: something about how interpretation of a resource has other things not covered by the hash and SRI is intended only to prevent malicious modification of benign files and not for pinning behavior of malicious files.
That's pretty much what I'm saying in this PR, but with slightly more words.
(This is just a PR, so if multiple people are concerned about it, maybe keep an issue open too? I figure maybe someone has a better wording than mine with which to make a PR.)
|
I've never heard the phrase "chameleon resources" before; is that a new or established term? I have a preference for "MIME type confusion," which is what I've always heard and used.
Acubed
added a note
I think I got the term from "Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves", Adam Barth et. el.: http://www.adambarth.com/papers/2009/barth-caballero-song.pdf I think that paper was focused on sniffing and this section is more about a bunch of bytes having a completely different meaning based on mime confusion. Although, I think a simpler title like "Impact of out-of-bound data" is much clearer and connects to the broader point we are making in the section. I've also heard the term 'Polyglots' in Polyglots: Crossing Origins by Crossing Formats by Jonas Magazinius et al., but I am not sure which is more common
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
|
|
Maybe simply these paragraphs to something like: "It is possible to generate documents that exhibit different but valid behaviors when presented with a different MIME type. An attacker can use this MIME type confusion to allow a document to pass an integrity check, but still have unexpected behavior. For this reason, servers SHOULD NOT rely on the integrity attribute to ensure safe behavior of user-generated content stored on untrusted servers." Also, it might be worth mentioning that we may consider MIME types as an option to the integrity attribute in a future version of the spec, as we mention earlier.
Acubed
added a note
It's not just mime/media types, but maybe also things like CSP headers (in future editions) that enable/disable functionality (which should properly be in the media type, but whatever). An attack by changing the media type is the only one in the wild I'm aware of, though. I feel like Joel's text is saying exactly that. Would it help if he changed "Particularly" to "For example"?
Acubed
added a note
Change the word in my patch? There'd end up be two "For example"s in the paragraph, that sounds redundant said aloud. "Particularly" seems strange, though. Change the word in Joel's suggestion. whoops .. my mistake. I think I was referring to changing the word in your patch. WDYT?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
|
I like this, but like @devd, I think it can be simplified slightly. See my comments above.
me and @metromoxie both agreed on a simplification. If you are not opposed to the simplification, that would be the simplest.
Since we have moved to a new repository, please re-submit your updated PR on https://github.com/w3c/webappsec-subresource-integrity
-
…rces
| @@ -748,6 +748,21 @@ will likely be difficult to avoid (image's `naturalHeight` and | ||
| `naturalWidth` for instance). | ||
| </section><!-- /Security::cross-origin --> | ||
| +<section> | ||
| +### Behavior of chameleon resources | ||
|
I've never heard the phrase "chameleon resources" before; is that a new or established term? I have a preference for "MIME type confusion," which is what I've always heard and used.
Acubed
added a note
I think I got the term from "Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves", Adam Barth et. el.: http://www.adambarth.com/papers/2009/barth-caballero-song.pdf I think that paper was focused on sniffing and this section is more about a bunch of bytes having a completely different meaning based on mime confusion. Although, I think a simpler title like "Impact of out-of-bound data" is much clearer and connects to the broader point we are making in the section. I've also heard the term 'Polyglots' in Polyglots: Crossing Origins by Crossing Formats by Jonas Magazinius et al., but I am not sure which is more common
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
|
||
| + | ||
| +Resources may still exhibit differing behavior due to out-of-bound data | ||
| +like its media type, HTTP headers, or origin. Particularly, a "chameleon" | ||
| +resource is one that is valid under multiple media types. For example, a | ||
| +CSS document, validated as such to the server's satisfaction, might still be | ||
| +crafted with malicious effects that are triggered if interperted as | ||
| +application/javascript. | ||
| + | ||
| +Servers SHOULD NOT rely on "integrity" to ensure the safe behavior of | ||
| +user-generated content stored on untrusted/third party servers, even if | ||
| +the document is sanity/validity checked. | ||
|
Maybe simply these paragraphs to something like: "It is possible to generate documents that exhibit different but valid behaviors when presented with a different MIME type. An attacker can use this MIME type confusion to allow a document to pass an integrity check, but still have unexpected behavior. For this reason, servers SHOULD NOT rely on the integrity attribute to ensure safe behavior of user-generated content stored on untrusted servers." Also, it might be worth mentioning that we may consider MIME types as an option to the integrity attribute in a future version of the spec, as we mention earlier.
Acubed
added a note
It's not just mime/media types, but maybe also things like CSP headers (in future editions) that enable/disable functionality (which should properly be in the media type, but whatever). An attack by changing the media type is the only one in the wild I'm aware of, though. I feel like Joel's text is saying exactly that. Would it help if he changed "Particularly" to "For example"?
Acubed
added a note
Change the word in my patch? There'd end up be two "For example"s in the paragraph, that sounds redundant said aloud. "Particularly" seems strange, though. Change the word in Joel's suggestion. whoops .. my mistake. I think I was referring to changing the word in your patch. WDYT?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
|
||
| +</section><!-- /Security::behavior --> | ||
| + | ||
| </section><!-- /Security --> | ||
| <section> | ||
Remind people that a document, even with a successfully asserted hash, is still subject to multiple interpretations, including possibly malicious interpertations.