Closed
Bug 1036840
Opened 10 years ago
Closed 10 years ago
requests during onunload are mis-attributed, leading to incorrect mixed content warnings
Categories
(Firefox :: Security, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 947079
People
(Reporter: kklex, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
132 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243
Steps to reproduce:
First of all, I'm not a developer, I do my best to explain very accurate. This issue might have been detected before, but with my non-frontend-specifics words I couldn't find anything like this.
What did you do?
I make an example:
* Visit www.firmenwissen.de (its a german side for research company data). There is a lot advertisment loaded.
* Open up a tool like firebug
* Look out for some pictures (jpg), e.g. below "News aus der FirmenWissen-Redaktion". Rightclick and let you show the picture in another tab.
Actual results:
When you just have the picture in the browser you see in Firebug in the network box, that there is more content loaded (pagead2.googlesyndication.com; dc98.s400.meetrics.net etc.).
This content doesn't exisit on the picture URL.
When you refresh the page, you just see in the Network box the picture.
Expected results:
The URL of the picture just contains the picture itself and not some content from the previous page.
e.g. http://www.firmenwissen.de/cms/cache/dc6b8d187268d65c17b59aa17b358738.jpg
You can try this with all other links from the main page. This content always appears on the next pages whereas the content is acctually not there.
Bytheway: this is only happing in Firefox, I tested it in IE10 and Chrome, its correct there.
As there is content on a page where it doesn't belong, I think this might be a security issue.
URL: www.firmenwissen.de
Please feel free to contact me if you have more questions regarding it.
Comment 2•10 years ago
|
||
Hey kklex, thank you for reporting this issue.
I could reproduce what you are seeing and it is indeed something unexpected. But I would rather call it a usability issue with Firebug.
It seems that the page's scripts (meetrics, google analytics etc.) want to track every click and interaction on the page. So the requests to these URLs are not for loading additional content, but for reporting about your interaction with the web page. This reporting happens after you click and is visible in the original tab's network console for the Chromium and the Firefox devtools (and not in the new tab!). Firebug shows these requests in the new tab instead, which is a bit confusing.
This bug can safely be unhidden (I am doing this) and forwarded to the Firebug people.
Group: core-security
Hi Frederik,
Its definitly not an Firebug issue. I just used the tool to detect this. The effect for the bug, I show you below.
I explain it with another example:
1) Open up www.google.de -> the page is secure SSL-Zertificate
2) Open up www.firmenwissen.de -> wait until the page is fully loaded
3) Open up www.google.de again -> the page is not secure anymore -> have a look into Firebug (or any other tool)
4) Refresh the page -> the page is secure again -> and in Firebug there is some content vanished (which belonged to www.firmenwissen.de)
www.firmenwissen.de is influencing the security of www.google.de!!! There might be more examples, I didn't searched for it.
Test the same steps with any other browser and you'll see that www.google.de is always displayed as secure
Hope that helps
Its not an firmenwissen.de-issue. Another example: replace www.firmenwissen.de with www.bild.de
All pages with ads
Comment 5•10 years ago
|
||
I now understand what you mean. This appears to be a display bug in Firefox.
The security of your browsing is not in danger. In fact, we just think the tracking data that websites like firmenwissen.de send just when you leave the page (triggered through the "on unload" event) are attributed to your next page (e.g. google.de), which makes it seem that google.de does some insecure requests when they are in fact still from the previous page.
I have written a minimal test cases that helped me reproducing the issue.
Here's the more technical explanation for the engineers:
- On a non-HTTPS page, bind a function to the "unload" event that creates a Image() object in JS.
- navigate from this HTTP page to a HTTPS only page (e.g. google.de)
- the image request is attributed to the HTTPS page, it is shown as if this page had mixed passive content.
I sometimes see the Image request in the devtools, but not always and reliably. It somehow works better with the trackers installed on the page this was reported for (firmenwissen.de, tracking scripts from meetrics.cnet and t4ft.de)
Tanvi, can you take a look at this?
Blocks: MixedContentBlocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Security issue? Page content on next page (content doesn't exist there) → requests during onunload are mis-attributed, leading to incorrect mixed content warnings
Updated•10 years ago
|
Component: Untriaged → Security
Comment 6•10 years ago
|
||
I am having trouble reproducing. When I try to go to https://www.firmenwissen.de it is redirecting me to http://www.firmenwissen.de. Also, is this an issue specific to image unloads? Or could it be a duplicate of bug 947079.
Comment 7•10 years ago
|
||
Yeah, don't use http_S_ firmenwissen, but http://www.firmenwissen.de (clear-text site).
Then go on to any other HTTPS-only website (i.e. google)
Oh I forgot to attach my test file... *attaching*.
Comment 9•10 years ago
|
||
(In reply to kklex from comment #8)
> Is there any update for this ticket?
Just browsed through the comments, it sounds like this is a duplicate of Bug 947079 [1], which is marked as WONTFIX at the moment. Once we revamped the security UI, this problem will disappear.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=947079
Comment 10•10 years ago
|
||
Marking as duplicate of bug 947079, which is in review.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•