removed tab still sending HTTP request if it is a popup and contains a redirect
Reported by
e.soll...@googlemail.com,
Apr 16 2016
|
|||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Example URL:
Steps to reproduce the problem:
1. create a server on port 12345 (nc -l 12345)
2. create an extension like below
3. open a webpage *as a popup* that redirects to that server, i.e. location.href = 'localhost:12345' or go to this data url data:text/html;base64,PGh0bWw+PGJvZHk+PHNjcmlwdD53aW5kb3cubG9jYXRpb249J2h0dHA6Ly9sb2NhbGhvc3Q6MTIzNDUnOzwvc2NyaXB0PjwvYm9keT48L2h0bWw+
The server will get a request even though the extension closed the tab before.
What is the expected behavior?
the tab should close immediately, cancelling the loading of the page, or at least not execute the redirect
What went wrong?
I created a small extension that listenes to onUpdated:
block.js:
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab) {
console.log(changeInfo);
if (changeInfo.status !== "loading" || !changeInfo.url) return;
if (!changeInfo.url.startsWith("data:text/html;")) return;
console.log("closing malicious tab for url:", changeInfo.url);
chrome.tabs.remove(tab.id);
});
manifest.json:
{
"manifest_version": 2,
"name": "Sample extension",
"version": "1.0",
"permissions": [ "tabs", "activeTab" ],
"background": {
"scripts": [ "block.js" ]
}
}
This should close any tab that loads a data:text/html url. This seems to be a new way of creating ad popups - by creating a popup to about:blank and then replacing it's location with a data: url that redirects to the actual ad content.
The extension get's this changeInfo:
Object {status: "loading", url: "data:text/html;base64,PGh0bW(...)"}
Then it calls tabs.remove() which closes the tab. Then it receives another update:
Object {status: "complete"}
Result: the server gets a HTTP request.
This does NOT happen, when the first load is not a popup to about:blank, but is navigated to directly.
Again, to be precise:
-----------------------
1. Open a popup to about:blank:
w = window.open("about:blank");
-> the extension will get two updates: loading/about:blank and complete
2. Replace with data:
w.location.replace("data:...")
-> the extension will get an update loading/data:... and remove the tab
-> the extension will then get another update complete
-> the server (netcat in my case) will get an HTTP request.
Doing this without popup or location.replace did not result in an HTTP request. I'm unaware of any other possible way to stop this request from happening, since content scripts are not allowed in data: urls.
Did this work before? N/A
Chrome version: 48.0.2564.116 Channel: stable
OS Version: Linux Mint 17.1
Flash Version:
,
Apr 18 2016
Have you tried using the webRequest API in blocking mode to block those data: URL loads?
,
Apr 18 2016
Yeah, the webRequest API might be better. I seem to recall the tab api is asynchronous, which could explain the non-blocking behavior.
,
Apr 19 2016
But how? As far as I can see, the webRequest API does not fire onBeforeRequest for data: urls.
,
Apr 22 2016
,
Apr 22 2016
webRequest doesn't get data: URLs, as there is no network request being made. webNavigation however, does give you events for navigations and does deliver those for data: URLs.
webNav[onBeforeNavigate][10,33]: Object { frameId: 0, parentFrameId: -1, processId: -1, tabId: 10, timeStamp: 1461346473468.979, url: "data:,Hello%2C%20World!!", __proto__: Object }
The webNavigation API will *not* allow you to block the request, but you could issue the tab close at onBeforeNavigate. You probably want to check the parent frame id is -1, so you know it is a tab and not an iframe that is navigating there, if you mainly care about window.open() cases.
Keep in mind that since all of these are asynchronous APIs, there is no guarantee that the server request won't be made.
,
Apr 22 2016
So, yet another API that won't do the job? Maybe there should be some changes made so that it's possible to interfere with data: requests or at least block them, like a filter on data:text/html;* Or make it possible to block js on data URLs, which cannot be done as well (allthough if you try, you will get a non-deletable, empty entry in your blocked JS pages list, but that's another bug)
,
Apr 24 2017
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 by csharrison@chromium.org
, Apr 18 2016Components: -Internals>Network Platform>Extensions UI>Browser>Navigation