How is Object Tag data URI XSS actually XSS?

Question

I have been looking into XSS pertaining to base64 encoding a data URI into an <object> tag (which is typically considered only a feasible XSS payload in Firefox), but I am failing to understand how this is a XSS attack? For example (I didn't base64 encode it so that you guys can easily read it):

<object data="data:text/html,<script>alert(document.cookie)</script>"></object>

The above example will, indeed, trigger an alert(), but it will be placed in an area within the page that is considered a completely separate page (separate from the host's DOM), so that document.cookie will return nothing useful. Likewise, if I were to try and capture the parent window's cookies, it will (on Firefox) reject it because embedded data URIs are considered Cross Origin:

<object data="data:text/html,<script>alert(window.parent.document.cookie)</script>"></object>

The above example will result in: "Uncaught DOMException: Permission denied to access property "document" on cross-origin object". Furthermore, this also means that any payload an attacker were to put in an <object> via the Data URI will not have access to the parent window's DOM. So, with that in mind, the only thing I can think of that an attacker could utilize this for is to embed a malicious form of some sort to try to capture user credentials: but that can be achieved by embedding mere HTML into data object, thus requiring no JS. I keep seeing in XSS cheatsheets a reference to this kind of attack, but where's the XSS side of this? Sure, I could embed whatever HTML I want in the object tag, but the JS part of it would only be for mere animations (and not XSS), no? Wouldn't it just be a way for an attacker to embed their own HTML to capture credentials? Is that the whole point or am I missing something?

Answer 1

Historically, data: URLs (apparently they aren't called "URIs" any more, sigh) were loaded in the origin of the browsing context they come from (usually their enclosing browsing context). In other words, the new "browsing context" created in the object tag would inherit its origin from the parent page, and thus be able to act the same as if it were a same-origin iframe.

According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs:

Note: Data URLs are treated as unique opaque origins by modern browsers, rather than inheriting the origin of the settings object responsible for the navigation.

I'm not sure what the threshold for "modern" is here. Certainly this wasn't the case some years ago. The RFC (from 1998) doesn't say anything about what origin the document is considered to have, and while it does include a "security" section, there's nothing in there that applies to the situation. Nor do the errata for that RFC say anything about origins or sandboxing. You should not rely on the assumption that it will always be considered a new origin unless you can find some specification requiring this, with a list of browsers that implement it and would consider it a bug to do otherwise.

Also, an attacker could still try to trick the user in various ways, e.g. by presenting a login screen that - since it's "on" the authentic domain - the user might treat as legitimate and enter their credentials into. In general, allowing attacker-controlled arbitrary HTML on a page is dangerous even if it doesn't include scripts that run in the same origin.

Answer 2

XSS means cross-site script injection. In your example it is clearly a script-injection. And it is cross-site, i.e. injected from site A into site B. What you describe is only that the impact of this specific XSS attack is limited due to in which execution context it is placed. But even with limited impact it is still a XSS.