Closed Bug 408164 Opened 17 years ago Closed 17 years ago

Web forgery warning not shown until tab switch

Categories

(Toolkit :: Safe Browsing, defect)

2.0 Branch
x86
All
defect
Not set
major

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)

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)
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.
Found minimal proof of concept HTML+CSS-code, but don't know how to hide bug. Please mail me!
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.
Group: security
Component: Security → Phishing Protection
QA Contact: firefox → phishing.protection
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">&nbsp;</div> </body></html> Regards Emil Ljungdahl Lars-Olof Moilanen
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">&nbsp;</div> </body></html>
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]
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?
The FF3 implementation is final, so it sounds like this only applies to FF2.
not planning on changing it, so not an fx3 blocker
Flags: blocking-firefox3?
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
Ok, I'll try to look at this over the weekend. Things might be a bit slow because of the holiday.
Status: NEW → ASSIGNED
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)
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.
Attachment #294458 - Flags: review?(dcamp) → review+
Attachment #294458 - Flags: approval1.8.1.12?
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+
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
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8.1.12
Resolution: --- → FIXED
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.
Group: security
Flags: in-testsuite?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: