New issue
Advanced search Search tips

Issue 860782 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 7
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security

Sign in to add a comment

Security: Javascript executed on cross origin request in embed tag

Reported by, Jul 6

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different

Please READ THIS FAQ before filing a bug:

Please see the following link for instructions on filing security bugs:

NOTE: Security bugs are normally made public once a fix has been widely


If a website uses an <embed> tag for a resource on a different origin (e.g. a webm video), and that origin is hijacked/squatted by someone else, they can return some html with javascript in it, which in turn is executed by Chrome, e.g.

 <embed type="video/webm" src="" width="300" height="200" />

While this is poor coding practise on behalf of the website, is this desired behaviour? 

I've seen this out in the wild, when I suddenly got redirected away from a page to the squatters website, because the origin had this javascript code in it:

<script type="text/javascript" language="JavaScript">
if (top.location!=location){
  top.location.href=location.protocol + "//" + + location.pathname + ( ? + "&" : "?") + "_xafvr=ODk4YmRjYzQ5MTgzYmFiMjg2NzA5ZDljMTA2ZmVkZWI3Nzc2ODY5Yiw1YjNlODNlMzczNmM1";

I can see this was discussed in - so is this a spec issue? It looks like the squatters are already 'exploiting' it as such by taking advantage of websites with poor code quality, I'd imagine it wouldn't be too difficult to put in a crypto miner or something, or try and execute a javascript exploit (e.g. rohammer, meltdown, spectre etc) 

I'm not experienced in this side of things, but if the browser is expecting a webm video, is it appropriate for it to execute whatever is returned?


Chrome Version: 67.0.3396.99 (Official Build) (64-bit)
Operating System: OSX 10.13.5


Proof of concept instructions:

1) Unzip ``
2) Run main.go `go run main.go` (this will run on port 8080)
3) Run differentorigin.go `go run differentorigin.go` (this will run on port 8082)
4) Open Chrome and navigate to http://localhost:8080

Outcome: javascript is executed, you should see an alert box and a message in console.log
987 bytes Download
Status: WontFix (was: Unconfirmed)
Thank you for the report.

Yes this is working as intended. The problem is mitigated by the fact that JavaScript running in the cross-origin <embed> is isolated from the embedding page, restricted by same-origin policy and, in Chrome, it is also loaded in a separate process.

You are correct that there can be a vector for crypto-miners, or possibly deceptive messaging to a user, but that is a larger problem on the web. When content is loaded there are signals as to what type of content it is, but we don't constrain it based the the extension of the resource file (i.e. '.webm').
Labels: -Restrict-View-SecurityTeam allpublic
blog about this - and corresponding mozilla bug -
> we don't constrain it based the the extension of the resource file (i.e. '.webm')

That's understandable, but assuming I'm understanding this issue correctly, isn't the problem that Chrome is ignoring the explicitly specified `type="video/webm"` attribute on the embed tag? That's more than just a file extension.
Yes, there is a case for that. A discussion was started on the HTML standard and it looks like the spec will be patched. I expect we will implement that change.

Sign in to add a comment