Closed
Bug 408164
Opened 17 years ago
Closed 17 years ago
Web forgery warning not shown until tab switch
Categories
(Toolkit :: Safe Browsing, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: emil, Assigned: tony)
References
()
Details
(Keywords: verified1.8.1.12, Whiteboard: [sg:low spoof] found in the wild)
Attachments
(1 file)
3.68 KB,
patch
|
dcamp
:
review+
dveditz
:
approval1.8.1.12+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.11) Gecko/20071205 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.11) Gecko/20071205 Firefox/2.0.0.11
On URL provided the web forgery warning dialog doesn't show up unless I switch tab, and then switch back.
Reproducible: Always
Steps to Reproduce:
1. Open URL http://business-internet-banking.hsbc.com.hfye223.ph/bibauth/formStart/
2. Open new tab / switch tab
3. Switch back to first tab
Actual Results:
Web forgery warning appears after step 3.
Expected Results:
Web forgery warning should appear after step 1.
Tested on Firefox 2.0.0.11 in
Gentoo amd64
Ubuntu 7.10 amd64
Windows XP SP2
Mac OS X Leopard (10.5.1)
Reporter | ||
Comment 1•17 years ago
|
||
Seems that the CSS is causing the bug. When I block the referenced stylesheet (http://business-internet-banking.hsbc.com.hfye223.ph/bibauth/formStart/0.css) I recieved the warning right away.
Reporter | ||
Comment 2•17 years ago
|
||
Found minimal proof of concept HTML+CSS-code, but don't know how to hide bug. Please mail me!
Comment 3•17 years ago
|
||
Confirmed on Mac OS X Leopard (10.5.1) with Firefox 2.0.0.11 and Ubuntu 7.10 amd64 with Firefox 2.0.0.11.
Updated•17 years ago
|
Group: security
Component: Security → Phishing Protection
QA Contact: firefox → phishing.protection
Comment 4•17 years ago
|
||
The bug is now hidden, but the site in question seems to be gone :-(
Without the site actually there I get the forgery warning right away.
The bug is now hidden so I'm posting your mail to security@mozilla.org that contains additional details:
However, after some research we found out that the bug appears as soon
as all content in the body of a page is contained in a div with absolute
position.
Example follows:
<html><head><title>Test</title>
<style>
#idTag { position: absolute; top: 40; border: 1px solid red; }
#idTag2 { position: absolute; top: 90; border: 1px solid blue; }
</style>
</head><body>
<div id="idTag">Jajaja</div>
<div id="idTag2"> </div>
</body></html>
Regards
Emil Ljungdahl
Lars-Olof Moilanen
Reporter | ||
Comment 5•17 years ago
|
||
The easiest way to reproduce is maybe these steps:
1. Install local webserver
2. Put the HTML file below in $WEBROOT/firefox/its-a-trap.html
3. Add 127.0.0.1 www.mozilla.com to /etc/hosts
4. Browse to http://www.mozilla.com/firefox/its-a-trap.html
<html><head><title>Test</title>
<style>
#idTag { position: absolute; top: 40; border: 1px solid red; }
#idTag2 { position: absolute; top: 90; border: 1px solid blue; }
</style>
</head><body>
<div id="idTag">Jajaja</div>
<div id="idTag2"> </div>
</body></html>
Comment 6•17 years ago
|
||
even easier, perhaps, would be to hand-edit the array of test urls in components/nsSafebrowsingApplication.js (even in release versions) to contain whatever you need.
I can confirm this bug with that testcase on a local server. Losing focus to another window doesn't do it, but switching back from another tab (which can pre-exist) does.
note: once you've dismissed the webforgery warning you must reload the page to reset the testcase.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [sg:low spoof]
Comment 7•17 years ago
|
||
This doesn't currently apply to Firefox 3 where the current implementation is a complete block (shared with malware blocking). Is that intended to be the final implementation, or an interim step before going back to the FF2-style overlay? Whether this blocks FF3 or not would hinge on that question.
Flags: blocking1.8.1.12?
Flags: blocking-firefox3?
Assignee | ||
Comment 8•17 years ago
|
||
The FF3 implementation is final, so it sounds like this only applies to FF2.
Comment 9•17 years ago
|
||
not planning on changing it, so not an fx3 blocker
Flags: blocking-firefox3?
Comment 10•17 years ago
|
||
Since this trick was originally found in the wild we probably need to fix this for Firefox 2, the bad guys are known to share their tricks.
Assignee: nobody → tony
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12?
Flags: blocking1.8.1.12+
Whiteboard: [sg:low spoof] → [sg:low spoof] found in the wild
Version: unspecified → 2.0 Branch
Assignee | ||
Comment 11•17 years ago
|
||
Ok, I'll try to look at this over the weekend. Things might be a bit slow because of the holiday.
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•17 years ago
|
||
When a page is loading, there is a check to see if content exists before we draw the warning bubble. The content check only looks to see if the height of the body is > 0. In the example cases, body has a height of 0 so we never draw the warning bubble during page load.
This check was originally added because it took a snapshot of the page before drawing the gray over it. This would result it a grey page with no content if content wasn't loaded. This check isn't needed anymore because we re-snapshot the page periodically. So the fix is to just removed this check completely. If a page is loading, we may get the grey over a blank page, but as the page continues loading, the grey overlay will get updated to have the page content. It may look a bit funny if the page never loads (e.g. a hanging GET), but that doesn't seem to be a real problem.
Attachment #294458 -
Flags: review?(dcamp)
Comment 13•17 years ago
|
||
Thanks Tony! no need to kill your holidays on this, we've got a lot of fixes yet to land and code-freeze for Firefox 2.0.0.12 won't be until mid-January.
Updated•17 years ago
|
Attachment #294458 -
Flags: review?(dcamp) → review+
Assignee | ||
Updated•17 years ago
|
Attachment #294458 -
Flags: approval1.8.1.12?
Comment 15•17 years ago
|
||
Comment on attachment 294458 [details] [diff] [review]
remove height check code
approved for 1.8.1.12, a=dveditz for release-drivers
Attachment #294458 -
Flags: approval1.8.1.12? → approval1.8.1.12+
Assignee | ||
Comment 16•17 years ago
|
||
Checking in browser-view.js;
/cvsroot/mozilla/browser/components/safebrowsing/content/browser-view.js,v <-- browser-view.js
new revision: 1.1.2.3; previous revision: 1.1.2.2
done
Comment 17•17 years ago
|
||
Verified for 1.8 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/2008012822 Firefox/2.0.0.12 and my friendly local webserver.
Keywords: fixed1.8.1.12 → verified1.8.1.12
Updated•17 years ago
|
Group: security
Updated•17 years ago
|
Flags: in-testsuite?
Updated•10 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•