Closed Bug 266932 (CVE-2005-4809) Opened 16 years ago Closed 15 years ago

Invalid HTML (e.g. nested links) causes firefox to open different url than statusbar on new tab

Categories

(Firefox :: General, defect)

2.0 Branch
defect
Not set
major

Tracking

()

RESOLVED FIXED
Firefox 2 alpha1

People

(Reporter: loconet, Assigned: mconnor)

References

(Blocks 1 open bug)

Details

(Keywords: fixed1.8.1, Whiteboard: [sg:low] link spoofing in mail / webmail)

Attachments

(2 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

As reported by Netcraft
(http://news.netcraft.com/archives/2004/10/29/new_url_spoofing_flaw_found_in_internet_explorer.html),
this bug which affects IE, also affects Firefox.

The following 2 code samples cause firefox to display http://www.mozilla.org on
the statusbar but when you open the link in a new tab, it goes to google.com.

1)
<a href="http://www.mozilla.org"><table><tr><td><a
href="http://www.google.com/">http://www.mozilla.org</a></td></tr></table></a>

2)

<a href="http://www.mozilla.org"><div><a
href="http://www.google.com/">http://www.mozilla.org</a></div></a>



Reproducible: Always
Steps to Reproduce:
1. Right click on sample url, then choose open in new tab.
2.
3.

Actual Results:  
Instead of going to mozilla.org as reported by the status bar, it goes to google.com

Expected Results:  
Firefox should go to mozilla.org or report google.com on the status bar
Attached file Testcase (obsolete) —
*** Bug 266943 has been marked as a duplicate of this bug. ***
Note that this does not affect seamonkey.
Flags: blocking-aviary1.0?
*** Bug 266921 has been marked as a duplicate of this bug. ***
(In reply to comment #3)
> Note that this does not affect seamonkey.

Sorry, I wasn't reproducing it correctly.  It does affect Seamonkey.  Filed bug
266958.
-> NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041029
Firefox/0.9.1+

happens on latest trunk of Firefox. 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041031
Firefox/0.9.1+

The Netcraft link quoted showed http://www.google.com/ in the status bar and 
took me to that URL.

The testcase had the faulty behaviour.
http://slashdot.org/comments.pl?sid=127762&cid=10673350
Note you must add the extra </a> inside the table tag from the original exploit
shown at netcraft, in order to get the different tab-opening behaviour vs normal
opening behaviour.

Also, unless there is some way to fix <a href="http://www.mozilla.org/"
onclick="location.href='http://www.google.com/';
return false"> (separate bug of course) then this 'exploit' hardly matters.
As Ryan's code demonstrates, this bug is only relevant if you have JavaScript
enabled.  This bug should be fixed anyway, because JavaScript is usually
disabled in mail and because and a small percentage of users disable JavaScript
in the browser to be more secure.
Bug reproducable in Mozilla 1.7 Linux (JS enabled and disabled), too.
-> Parser
Component: General → Layout
OS: Windows 2000 → All
Product: Firefox → Browser
Hardware: PC → All
Version: unspecified → Trunk
Assignee: firefox → nobody
QA Contact: firefox.general → core.layout
Making this a Seamonkey bug just dupes it to bug 266958.
(In reply to comment #12)
> Making this a Seamonkey bug just dupes it to bug 266958.

I filed the separate Seamonkey bug based on discussion in #developers (we
initially thought it was frontend code that would be different between the two
browsers).  If it is the same code, it would probably make more sense to dupe
that bug to this one.
(In reply to comment #12)
> Making this a Seamonkey bug just dupes it to bug 266958.

I filed the separate Seamonkey bug based on discussion in #developers (we
initially thought it was frontend code that would be different between the two
browsers).  If it is the same code, it would probably make more sense to dupe
that bug to this one.
This bug is due to an interaction of front-end and back-end code.  In the end,
both may need fixing.  And since the frong-end code in Firefox is separate from
the SeaMonkey front-end code in this case, back to Firefox, marking dependent.
Assignee: nobody → firefox
Component: Layout → General
Depends on: 266958
Product: Browser → Firefox
QA Contact: core.layout → firefox.general
*** Bug 267766 has been marked as a duplicate of this bug. ***
we ship with statusbar open to javascript manipulation by default. it's not to
be trusted. not going to block on this. 
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Is it a good idea to allow this through to 1.0? The strongest selling point of
FF for most people is security improvements over IE. This particular issue
received the usual hype in the media regarding Internet Explorer. Regardless of
the "critical/non-critical" importance of this bug, it is a security issue that
wouldn't ring well with the public: it would be bad publicity to let this sort
of thing through. I suggest it should be marked blocking again.
I could have sworn that "Hide the status bar" and "Change status bar text" came
disabled by default in the advanced javascript options now.
Excuse my ignorance, I'm not seeing how having javascript on/off, or statusbar
javascript settings matter here. This bug affects the browser even if javascript
is turned off and/or even if statusbar javascript manipulation is disallowed.
The testcase code doesn't even have any javascript, does it some how trigger
some javascript issue?
I think Asa was basically saying this bug is a moot point if javascript is
allowed to alter the status bar.  Although I thought the status bar altering
javascript was disabled by default, there are still other ways than this bug to
make the status bar misleading anyways, so I would agree with not blocking 1.0
for this.
Oh now I understand. Makes sense to me. Thank you.
*** Bug 274864 has been marked as a duplicate of this bug. ***
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050730
Firefox/1.0+
Attached file testcase
HTML testcase, since bug 90664 fixed the simplest case, so triggering it requires either XHTML or DOM manipulation now.
Attachment #164020 - Attachment is obsolete: true
Assignee: firefox → nobody
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051224 Firefox/1.5

With the newest testcase, I see "http://www.mozilla.org/" in the status bar before I click and "http://www.google.com/" in the status bar while the mouse button is down.  Left-clicking takes me to http://www.mozilla.org/, but Cmd+clicking takes me to http://www.google.com/ in a new tab.
Flags: blocking1.8.0.1?
Whiteboard: [sg:low] link spoofing in mail / webmail
A fix would be nice, but is this really a 1.5.0.1 blocker?
Assignee: nobody → mconnor
I doubt there's a sane way to fix this for 1.5.0.1 anyway.
I think this is an acceptable workaround, which near as I can tell matches the behaviour on left-click across the board in opening/displaying www.mozilla.org.  This patch would need to be undone if and when the core bug is addressed.
Attachment #207470 - Flags: review?(vladimir)
(In reply to comment #28)
>I doubt there's a sane way to fix this for 1.5.0.1 anyway.
It probably depends on the event handling rewrite, but it might be possible to tweak the HandleDOMEventForAnchors process for 1.5.x
I've tried two or three times.  Each time the net effect was links not working at all.  If someone else manages to do it, fine, but getting a branch-safe patch will be exciting.
Please get this reviewed and checked into the trunk ASAP if it's going to make any 1.8.0.1 train.
Flags: blocking1.8.1?
Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

r=vladimir
Attachment #207470 - Flags: review?(vladimir) → review+
Attached patch HTML anchor processing fix (obsolete) — Splinter Review
This seems to work for me, but I haven't found where XLinks are handled yet.
Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

landed on trunk, given bz's comments I think we want to take this for 1.5.0.1 instead of the better fix.
Attachment #207470 - Attachment description: workaround to match left-click behaviour and prevent spoofing → workaround to match left-click behaviour and prevent spoofing (checked in on trunk)
Attachment #207470 - Flags: approval1.8.0.1?
XLinks are handled in nsXMLElement.cpp
Comment on attachment 207507 [details] [diff] [review]
HTML anchor processing fix

This isn't quite right, some (but not all) of the events need to be handled in the system event group so that normal JS bubbling listeners will fire first!
Attachment #207507 - Attachment is obsolete: true
Flags: blocking1.8.0.1? → blocking1.8.0.1-
Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

not enough baking for 1.8.0.1, very minor spoofing issue
Attachment #207470 - Flags: approval1.8.0.1? → approval1.8.0.1-
Since it's fixed now, will the bug be closed?  WFM in 20060116(04).
If this bug is closed, please file a new bug to fix the UI once bug 234455 (or bug 127903, or bug 62151, etc) is fixed.
Summary: Invalid HTML causes firefox to open different url than statusbar on new tab → Invalid HTML (e.g. nested links) causes firefox to open different url than statusbar on new tab
Blocks: 307087
Blocks: 325274
filed bug 325652 on undoing this change
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 207470 [details] [diff] [review]
workaround to match left-click behaviour and prevent spoofing (checked in on trunk)

requesting 1.8 branch approval for this (with bug 324946's patch)
Attachment #207470 - Flags: approval-branch-1.8.1?(mconnor)
Attachment #207470 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
mozilla/browser/base/content/browser.js; new revision: 1.479.2.70;
Keywords: fixed1.8.1
Target Milestone: --- → Firefox 2 alpha1
Version: Trunk → 2.0 Branch
Alias: CVE-2005-4809
Duplicate of this bug: 390630
You need to log in before you can comment on or make changes to this bug.