I think that the links contained in the source code of a page with data: protocol, should appear in plain text as it happens in Firefox

Can you reproduce this without using the DATA protocol (e.g. by hosting the repro on HTTP)?

DATA isn't supposed to allow view-source at all; that's Issue 700610.

View-Source probably shouldn't allow JavaScript execution; that's  Issue 705206 .

Interestingly, I get the View Source version of the injected abc.xyz page, on Chrome OS (60). See screenshot.

Is there any attack scenario in which an attacker can read or write any cross-origin assets? If not, I'm not sure this is a distinct bug on its own, different from the existing bugs.

Deleted: Screenshot 2017-09-20 at 11.39.54.png 487 KB

	Screenshot 2017-09-20 at 11.39.54.png 487 KB View Download

Comment 1: the result is the same using the http protocol.

We can replace the example:

data:text/html,<embed src='javascript:alert(1);document.body.innerHTML+="<h1>test</h1><h2>test</h2><h3>test</h3><iframe src=https://abc.xyz/investor style=width:50%;height:50%></embed>";location="view-source:https://www.google.com"'></embed>

by: 

data:text/html,<embed src='javascript:alert(1);document.body.innerHTML+="<h1>test</h1><h2>test</h2><h3>test</h3><iframe src=https://abc.xyz/investor style=width:50%;height:50%></embed>";x'></embed>

(look the variable x in the final part of the code)

* If we force a execution error (x or location="view-source:..."): html elements rendered.

* If we remove the x (without execution error): html entities are displayed.

Example: data:text/html,<embed src='javascript:alert(1);document.body.innerHTML+="<h1>test</h1><h2>test</h2><h3>test</h3><iframe src=https://abc.xyz/investor style=width:50%;height:50%></embed>"'></embed>


Comment 4: it is difficult to imagine a real attack scenario without the intervention of the user. So, I also think it's not a security bug.

Thank you for providing more feedback. Adding requester "palmer@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#6: Even if the attack requires the person using the browser to click on something or otherwise 'participate' in the attack, we might still consider that a security vulnerability. But we would consider the interaction requirement to mitigate the severity.

But in this case, all I can see is perhaps a marginal path to phishing or social engineering. I definitely think it's at least a functional bug, of course. I'm going to consider this bug essentially a duplicate of  Issue 705206 , since fixing that would fix this.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot