Bugzilla

This is conflating "what the cross-origin page knows" (governed by the same-origin policy) and "what the user's agent (the browser) tells the user".

The document knows the original URL of the image it put in it's source. The same-origin policy says that's all that document should ever know about that URL -- any redirects on the network could be information from another context and should not be leaked back to that original page. This is not a perfect policy and some information is leaked such as whether the image loaded or was an error and that can sometimes be used to infer things about whether a redirect happened or not, but won't leak the full path back to the original document. Information can also be gleaned from applying CSP policies and what errors are returned, though you shouldn't be able to recover secrets that way.

"Copy Image URL" is information the browser knows (the real URL of the image) and shares with the user. Firefox believes that what the user most wants is the real source of that image after redirects since the redirects might be different in other contexts and result in a different image. Chrome, for one example, has chosen the original URL as the more useful value. But that is a feature of the browser and separate from the same-origin policy. This value is not leaked (by the browser) back to the containing page.

In this POC you're asking the user to share their information back with you, by interacting with the browser and then pasting the result back into a browser field. It is the user, via a "social engineering" attack, that has leaked the data to the page. To me, that part is not a Firefox "bug", and the Firefox "Copy Image URL" feature is more useful than Chrome's.

**The above is not a security bug**

A completely different problem, in my mind, is why we have a "Copy Image URL" menu item at all on an image that did not load! What the user is seeing is the background image, but if that's what's triggering the context menu item why aren't we giving the user the background image URL? Do we normally give the URL of broken images so the user can play with it in another context? Probably -- maybe a site prevents "deep-linking" but the image can be viewed directly?

I can accept that as useful, but then in this case we're stopping one URL short of where we know we redirected. Is that because the redirect was "successful" but the CSP block made it an error? But we're already letting the user in on the erroring image URL. Not sure if that's a bug or not, or if it is whether it's worth fixing. Not a security bug though, just a question of what's useful to the user.

This is conflating "what the cross-origin page knows" (governed by the same-origin policy) and "what the user's agent (the browser) tells the user".

The document knows the original URL of the image it put in it's source. The same-origin policy says that's all that document should ever know about that URL -- any redirects on the network could be information from another context and should not be leaked back to that original page. This is not a perfect policy and some information is leaked such as whether the image loaded or was an error and that can sometimes be used to infer things about whether a redirect happened or not, but won't leak the full path back to the original document. Information can also be gleaned from applying CSP policies and what errors are returned, though you shouldn't be able to recover secrets that way.

"Copy Image URL" is information the browser knows (the real URL of the image) and shares with the user. Firefox believes that what the user most wants is the real source of that image after redirects since the redirects might be different in other contexts and result in a different image. Chrome, for one example, has chosen the original URL as the more useful value. But that is a feature of the browser and separate from the same-origin policy. This value is not leaked (by the browser) back to the containing page.

In this POC you're asking the user to share their information back with you, by interacting with the browser and then pasting the result back into a browser field. It is the user, via a "social engineering" attack, that has leaked the data to the page. To me, that part is not a Firefox "bug", and the Firefox "Copy Image URL" feature is more useful than Chrome's.

**The above is not a security bug**

A completely different problem, in my mind, is why we have a "Copy Image URL" menu item at all on an image that did not load! What the user is seeing is the background image, but if that's what's triggering the context menu item why aren't we giving the user the background image URL? Do we normally give the URL of broken images so the user can play with it in another context? Probably -- maybe a site prevents "deep-linking" but the image can be viewed directly?

I can accept that as useful, but then in this case we're stopping one URL short of where we know we redirected. Is that because the penultimate redirect was "successful" but the CSP block made the next one an error? But we're already letting the user in on the erroring image URL. Not sure if that's a bug or not, or if it is whether it's worth fixing. Not a security bug though, just a question of what's useful to the user.