Issue metadata
Sign in to add a comment
|
Security: Javascript executed on cross origin request in embed tag
Reported by
djharpe...@gmail.com,
Jul 6
|
||||||||||||||||||||
Issue descriptionThis 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 template. Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com /chromium/src/+/master/docs/security/faq.md Please see the following link for instructions on filing security bugs: https://www.chromium.org/Home/chromium-security/reporting-security-bugs NOTE: Security bugs are normally made public once a fix has been widely deployed. VULNERABILITY DETAILS 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="http://foo.com/movie.webm" 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.host + location.pathname + (location.search ? location.search + "&" : "?") + "_xafvr=ODk4YmRjYzQ5MTgzYmFiMjg2NzA5ZDljMTA2ZmVkZWI3Nzc2ODY5Yiw1YjNlODNlMzczNmM1"; } </script> I can see this was discussed in https://github.com/whatwg/html/issues/513 - 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? VERSION Chrome Version: 67.0.3396.99 (Official Build) (64-bit) Operating System: OSX 10.13.5 REPRODUCTION CASE Proof of concept instructions: 1) Unzip `proof-of-concept.zip` 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
,
Aug 13
blog about this - https://djhworld.github.io/post/2018/08/12/i-thought-i-found-a-browser-security-bug/ and corresponding mozilla bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1473833
,
Aug 14
> 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.
,
Aug 14
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 |
|||||||||||||||||||||
Comment 1 by kenrb@chromium.org
, Jul 7Status: WontFix (was: Unconfirmed)