Popunder using chrome extension
Reported by
afzalsay...@gmail.com,
Oct 12
|
|||||
Issue description
Chrome Version : 69.0.3497.100 (Official Build) (64-bit)
User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
URLs (if applicable) :
Other browsers tested:
N/A
Chrome doesn't seem to block popups caused by extensions as it does with normal webpages. Thus it is possible to create a popunder exploiting this technique and shipping it as a malicious chrome extension. Is this normal?
In normal conditions a popup is blocked by chrome if it is caused without a user interaction or more than one windows are opened with single user interaction event such as click.
Both of these conditions aren't true in case of an injected script by a chrome extension.
What steps will reproduce the problem?
(1) Create a simple chrome extension with following `manifest.json`
```
{
"name": "PopUnder Example",
"version": "1.0",
"description": "PopUnder using extension!",
"content_scripts": [
{
"matches": [
"http://example.com/*",
"https://example.com/*"
],
"js": ["content.js"],
"run_at": "document_end"
}
],
"manifest_version":2
}
```
(2) Create and add `content.js` as follows:
```
windowObjectReference = window.open("http://g.co", "DescriptiveWindowName", "width=420,height=230,resizable,scrollbars=yes,status=1");
w2 = window.open();
w2.close()
```
(3) Install the extension in chrome; follow https://developer.chrome.com/extensions/getstarted
(4) Open http://example.com/ and we have a popunder
What is the expected result?
Popup blocker must block the popups caused by extension and apply same rules to extensions as webpages
What happens instead?
Popup blocker doesn't set off while running extension scripts
Please provide any additional information below. Attach a screenshot if
possible.
I've also verified this behaviour on canary latest version 71 as of writing this report. I'm not entirely sure if this is intended behaviour for some essential functionality of extensions to work or if this is a bug hiding in plain sight.
Also couldn't find a relevant discussion on google search. Hence, here I am to validate my findings.
Thanks in advance!
,
Oct 14
Charlie: Hmmm... Devlin: Can we distinguish between code running as extensions and as native to the page?
,
Oct 14
,
Oct 15
Hoping to answer for Devlin, when I asked a similar question a while back for a completely separate reason. This is what he said: "There's a bit of plumbing necessary, but each world has a unique world ID, and we can map that world ID to the extension (check out ScriptInjection::GetHostIdForIsolatedWorld). So we should be able to figure out if a world is for a content script, and if so, which extension it belongs to." This was for content scripts, but I believe non-content script execution should be easier to differentiate.
,
Oct 15
I was imagining a future where we would treat extensions even more aggressively re popups than we do. But if today we don't treat them differently, why would the popunder blocking not work for extensions? (Lemme finish some building stuff and I'll poke at this a bit.)
,
Oct 15
My guess is that this is similar to the pop-under that was caused by that bug that used postMessage to persist the user gesture. What happened is that "close()" on the second pop-up ends up triggering activation on the first pop-up. This usually isn't a problem because sites can't open two pop-ups.
,
Oct 15
> Devlin: Can we distinguish between code running as extensions and as native to the page?
What Charlie said in #4 :) (Thanks, Charlie!)
To expand a bit, extension code can basically fall into three categories:
- Code running in an extension frame. Easily distinguishable because the URL is the extension origin (chrome-extension://<id>).
- Code running in extension content scripts. See #4.
- Code injected into the main world of the page by a content script. e.g., a content script does something like
let s = document.createElement('script');
s.text = 'alert("hi");';
document.body.appendChild(s);
In this case, the code executes in the same context as the page, and it's much harder to trace it back to the extension. However, at this point it should also be treated identically to behavior from the page, so shouldn't have any extra privileges.
In general, I'm also supportive of having a higher bar for extensions code, so more aggressively blocking pop[ups|unders] sounds reasonable. But I'd want to know a bit more about it before committing one way or the other.
,
Oct 17
,
Nov 13
,
Jan 5
Blocking popups from extensions seems a bit silly, as they can always employ a background page to use chrome.tabs.create and friends for them and create a foolproof tabunder/popunder (or simply change the content settings). Taking away that power makes extensions much less powerful and defeats a lot of use cases. One easy thing that you can do is to add "Can freely open popup windows and tabs" to the permission warning of any extension. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by viswa.karala@chromium.org
, Oct 14