Repository navigation
[css-images] image-orientation:none violates same-origin policy #5165
Description
As I realized in whatwg/html#5603, this leaks an additional bit of information for opaque responses.
cc @heycam
As I realized in whatwg/html#5603, this leaks an additional bit of information for opaque responses.
cc @heycam
Activity
annevk commentedon Jun 4, 2020
An alternative to consider is to act as if images generated from opaque responses never have EXIF data (or any kind of metadata other than width/height/ratio). Requiring each feature that can disable or override some EXIF data to take such images into account feels very brittle to me.
noamr commentedon Jun 4, 2020
I think that that would create a requirement that would make people enable CORS when they didn't otherwise have to - just to have their images display correctly.
I think there's no reason why this requirement should be on the usage of EXIF, instead on the feature that overrides (and thus exposes)
EXIF, such asimage-orientationandimage-resolutionCSS properties.Otherwise, it feels like we're trying to prevent a threat of a hypothetical future API. Is that a necessary thing to do?
annevk commentedon Jun 4, 2020
They're not hypothetical, this API (
image-orientation) already exists, whatwg/html#5603 adds another. Making the APIs enforce the policy violates the principle of least privilege and will likely lead to numerous bugs.heycam commentedon Jun 5, 2020
cc @stephenmcgruer
heycam commentedon Jun 5, 2020
If we do have to prevent
image-orientationfrom working on images that came from opaque responses, it would be nice if we could unconditionally apply the orientation (and I guess pretend from the whatwg/html#5603 APIs that there was no orientation metadata), so that we can try to treat orientation as an implementation detail of the image file representation. But that would make it tricky for authors wanting to useimage-orientation: noneto turn off the new re-orientation effects for their pages that rely on it not being applied.noamr commentedon Jun 5, 2020
I think that's a better approach... the threat comes from the "overriding" feature, not from the implementation detail of using EXIF. An image format may similarly have an internal representation of orientation/resolution supported internally in the decoder - would that also be limited to same-origin/CORS images?
EXIF is not the issue here - it's the mixing of image-originated data and markup-originated data, which is something that currently occurs only for naturalWidth/naturalHeight.
If we want to take a more generic approach - I think it should tackle those blurred boundaries between content and markup.
annevk commentedon Jun 5, 2020
@noamr again, it's not just overriding, it's also reading as linked above. There's various different ways this will end up being exposed.
@heycam how do we model it in such a way that we don't need security checks all over?
I guess what we could do is that we take the orientation into account for decoding purposes, but don't store it as a field on the resulting image if it was generated from an opaque response. So it appears rotated, but if you query its metadata it'll return the default orientation values.
The tricky aspect is when metadata can be overridden, as it can be here. If the internal representation still has non-default metadata you would need to take that into account somehow. I.e., if an image was rotated 90 degrees and an API asked for it not to be rotated, it would have to remain rotated at 90 degrees. Model-wise that follows from the preceding paragraph, but in implementations that might be a bit trickier.
noamr commentedon Jun 5, 2020
Sure, I meant reading/overriding - anything that enables reading directly or indirectly.
I think that the overriding features in this case should be disabled for the opaque resource. E.g. CSS image-orientation would simply not apply, maybe even regarded as invalid style. I think that would be reasonable implementation-wise.
annevk commentedon Jun 5, 2020
I think the model we end up with shouldn't require each new feature to check whether the image was generated from an opaque response. So if some theoretical feature allowed setting EXIF rotation to 90 and the opaque image already had it 90 (exposed as 0 per the above model), it should be as if it was 180 and be exposed to the world as 90.
noamr commentedon Jun 5, 2020
I like that. Makes metadata "embedded" into the image for opaque images, but still working as expected if there's nothing that tries to override/read it.
heycam commentedon Jun 6, 2020
I think this would be the right approach. The intrinsic orientation spec concept for opaque images would be "zero degrees, no flip", and the image dimensions (whether the image is opaque or not) would have the orientation taken into account.
image-orientation's behavior would then be written in terms of the image's intrinsic orientation.noamr commentedon Jun 15, 2020
cc @chrishtr @smfr
noamr commentedon Jun 21, 2020
I don't see a lot of movement on this ticket... does any implementer have an opinion about this?
It's currently blocking whatwg/html#5574, and these same-origin policy violations are already in the wild... would be good to figure out if we see EXIF orientation/(resolution) data as a cross-origin information leak, and if it is, how to mitigate it.
55 remaining items
mzur commentedon May 28, 2021
I am the maintainer of an image annotation web application and in a similar position than @philcunliffe (only that I wasn't aware of this before it was implemented). Now I'm caught cold with the implementation in Chromium which totally breaks our application without any way to implement backwards compatibility. We already went to great lengths to ensure backwards compatibility with the previous breaking change of always respecting the EXIF orientation (I also commented on that here but nobody seems to be interested there anymore).
I realize that it's probably too late and the discussion is already over but I wanted to leave a note that the previous decision to apply EXIF rotation by default and now this decision are huge breaking changes for some of us. Sorry for the rant, I'm just a little frustrated.
dlrobertson commentedon Apr 13, 2023
Just a note: When fixing this in Gecko with bug 1655598, it was not clear to me that this should use cors-same-origin. This was later found and fixed in bug 1822116, but it might be nice if it was explicitly stated that cors-same-origin should be used.
annevk commentedon Apr 28, 2023
@dlrobertson FWIW, the discussion above talks about "opaque responses". You don't get an opaque response when using CORS. You either get a non-opaque response or a network error.
dlrobertson commentedon May 1, 2023
@annevk makes sense. Thanks for the clarification!
DavidJCobb commentedon Feb 14, 2024
In the context of image dimensions already leaking across origins, making
image-orientationrequire CORS comes across as security theater, not as an actual mitigation of a real threat. Is there any informational aspect to orientation, any meaning that it could possibly ever have, besides the presence or absence of a swap operation on two pieces of information (width and height) that everyone is already allowed to read?In what world is this use case even remotely comparable to simply placing an image in a document with the expectation that you can ensure it displays properly for your use case? How are intermediate-to-advanced HTML5 canvas shenanigans and scripted interactivity regarded as being on the same level as a bog-standard
<img>tag?eeeps commentedon Feb 14, 2024
@DavidJCobb
Because exploits will take advantage of anything that's possible, and we should have ~zero-tolerance for creating new avenues for user harm. I sketched out an example to answer this question for myself, here:
— https://css-tricks.com/i-learned-to-love-the-same-origin-policy/
philcunliffe commentedon Feb 14, 2024
I've had a couple years to debrief on this now and while I still could argue that "embedding instructions" don't belong in the same bucket as other much more sensitive EXIF data I think the solution is mostly fine.
As someone who was hit hard by this change my one wish would be that the W3C and big browsers treat breaking changes with more respect. The decisions of this group directly affect the largest application platform in the world.
The fact that many developers were caught completely off guard by a breaking change (with no option for backwards compatibility) to the worlds largest application platform seems like a process failure somewhere. In the image annotation industry alone this decision cost a lot of real peoples jobs and changed the flow of tens of millions of dollars at a minimum.
I'm guessing people in this body will say that this is entirely the browsers responsibility during implementation but there's an inescapable human element to these decisions now given the scale. Maybe the W3C should give guidelines for a time delay and warning mechanisms when a breaking decision is made? Even a simple console message when the image-orientation rule was present for 6 months before the change was actually made would have made a big difference.
DavidJCobb commentedon Feb 15, 2024
If exposing the intrinsic size of an image is enough to compromise an app, then that app is already insecure. Your example has us suppose the existence of a website that discloses image dimensions in a context where doing so is insecure, yet only discloses them in the specific ways that this change to the spec would block, and not in the very closely related, far more common, far more likely, and far more obvious ways that are currently treated (and will for the foreseeable future always be treated) as exceptions to same-origin restrictions.
You can contrive exceptions and edge-cases like, "Oh, but it only exposes the size of an image under this incredibly specific scenario that I hand-crafted explicitly to justify this one niche change to the spec that damages backward-compatibility," but that's equivalent to saying, "The problem isn't web developers shooting themselves in the leg. It's that they can aim at their leg, miss, and have the bullet ricochet off the floor and directly into their leg. The problem is that spot on the floor, and we should urgently get rid of it by annihilating the floor tiles there with a sledgehammer."
Cross-origin restrictions are a valuable principle by default, but it's not an absolute principle that's always intrinsically correct for the web, and it can't be cited as if it is one: the web is already filled with functionality that demands exceptions to it -- like being able to embed images across origins without setting up CORS -- and EXIF orientation belongs with that existing functionality. Like, what I'm seeing here is that focusing purely on what's practical, it's very easy to offer a straightforward disagreement with this change ("EXIF orientation is the same kind of data as intrinsic sizing information, which is already exposed") and it's very hard to offer a straightforward agreement with this change ("What if a web developer makes a site that's insecure but only in the exact ways that this otherwise nonsensical and inconsistent-with-everything-around-it change would band-aid for them, and also, what if we pretended that plain image tags are the same kind of content as scripted and interactive HTML5 canvases?").
This is security theater.
eeeps commentedon Feb 15, 2024
I suppose I am more absolute, because it makes the security model of the web 1) stronger 2) easier to reason about. Web developers and users don't have to worry about this entire class of security problems if the platform can take care of it for them. My take is more like "unauthorized cross-origin reads of any kind should have never been allowed, and we certainly shouldn't open up new ones." Intrinsic sizing being exposed was, in hindsight, a mistake, and there are active efforts to fix it (although this is a very hard thing to do in a web compatible manner). In your foot-gunning metaphor, I wouldn't say I'm for "annihilating the floor", but I am for comprehensive gun control, and wish we'd had it thirty years ago.
noamr commentedon Feb 15, 2024
Coming back from this after a few yeats - one same-origin policy violation (image dimensions) cannot justify another (orientation).
Because the former has been around for decades, authors had years to protect against this and be aware that image dimensions are something that's exposed to browsers and that's life. We have to be rigorous about not allowing new leaks because there is lots of content out there that is not protected against them.
Really the focus should go towards reducing the usage of no-cors in the web and moving towards CORS, even in CSS.
I've recently updated the CSS spec (https://drafts.csswg.org/css-values-5/#request-url-modifiers) to allow CORS images, however that's not implemented in browsers. I think implementing that would be a step forwards to actually resolving this in a holistic manner.
yoavweiss commentedon Feb 15, 2024
I'd even vote for a Document Policy that forces all subresources to be loaded with e.g. implicit
crossoriginattributes. That would enable developers to always load their images CORS enabled and not worry about any of this.noamr commentedon Feb 15, 2024
Yea I think we would need both, because some pages reference existing images that might not be CORS-enabled.
philcunliffe commentedon Mar 4, 2024
@yoavweiss @noamr
Where would be the right spot to open an issue about breaking change guidelines? I believe it fits under the mission statement for W3C to develop a standard operating procedure.
noamr commentedon Mar 5, 2024
Perhaps @jyasskin can advise here.
jyasskin commentedon Mar 5, 2024
I don't have a good answer for you. Back in the day, there were documents like https://www.w3.org/TR/qaframe-spec/ that specified how to write specifications, but I don't think we have that sort of meta-WG right now in any of the standards bodies I follow. Instead, we have statements like https://whatwg.org/working-mode#removals that defer to implementer opinions, and https://www.chromium.org/blink/launching-features/#feature-deprecations that governs how Chrome in particular makes this sort of decision. The AB might be an appropriate body to think about this at the W3C-wide level, since they have an Incubation activity considering the other end of the pipeline. You can suggest they look at breaking changes by filing an issue in https://github.com/w3c/AB-public/issues. The CSSWG could also create an opinion for itself, but that wouldn't advise any other WGs.