Closed Bug 578477 Opened 14 years ago Closed 13 years ago

Link can be manipulated to display a different link on hover than actual link

Categories

(Toolkit :: Safe Browsing, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED
Firefox 4.0b9

People

(Reporter: joen1369, Unassigned)

References

()

Details

(Whiteboard: [sg:low spoof] [fixed by bug 331959])

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729)

Example code shows how a link can be manipulated to show "http://www.firefox.com" on hover, but actually directly link you to "http://google.com.  This can be very dangerous for users who have been phished.


<a href="http://google.com">
     <span>
         <ul>
           <li><a href="http://www.firefox.com">Firefox</a> </li>
        </ul>                
     </span>
</a>

Reproducible: Always

Steps to Reproduce:
1. Go to the example site I set up: http://www.traininguru.com/firebox_bug
2. Hover mouse over link. I appears that I will be directed to "http://www.firefox.com"
3. Upon clicking the link, I you will actually be directed to "http://google.com"
Actual Results:  
User will be directed to Google.com instead of Firefox.com.  It happens every time in Firefox by following the steps above.

Expected Results:  
Same as above.

I believe this is a very dangerous bug that phishing sites could use to directly users to compromised sites. Most users trust that the link that is being displayed upon hovering over the link, is the actual site they will be directed to. This is not the case with this bug.

I believe this is a high-security threat.
Severity: critical → major
Update:
Expected Results: On click, link should take user to the site this is displayed when mouse hovers over link.
This is bug 266932 coming back to taunt us a second time.

In the bigger picture links are generally untrustworthy because onclick handlers can do anything they like, but in certain situations (like webmail) the user might know scripts are disabled or filtered out and be slightly more susceptible. The average user just clicks and trusts what the link itself says (not the hover) judging by the mass of phishing email I see.
Group: core-security
Whiteboard: [sg:low spoof] bug 266932 is back
Status: UNCONFIRMED → NEW
Ever confirmed: true
On mouse down, the status bar shows the true HREF. As such, the flaw is not as critical, but still a problem albeit.
Attached patch Bug 578477 PatchSplinter Review
Patch for bug 578477.
Attachment #509371 - Flags: review?
Patch [attachment 509371 [details] [diff] [review]] is for mozilla-1.9.2.   In mozilla-2.0 function parameter names of setOverLink are changed. Am I need to submit another patch for mozilla-2.0?
Attachment #509371 - Flags: review?(dao)
Yeah, you want to be working against tip.
I believe this isn't an issue on trunk anymore, fixed by bug 331959.
Depends on: 331959
I can't repo this with the above STR using the latest trunk m-c build based on
cset: http://hg.mozilla.org/mozilla-central/rev/274e546e9da9

Win7 x64
Yeah, Because in cset: http://hg.mozilla.org/mozilla-central/rev/274e546e9da9 
function parameter names in setOverLink() are changed. As I mentioned in comment 5.
Patch to adopt setOverLink function parameter name changed. It is for cvs: http://hg.mozilla.org/mozilla-central/rev/274e546e9da9
Attachment #509442 - Flags: review?
Attachment #509442 - Flags: review?(dao)
Attachment #509442 - Flags: review?
Attachment #509442 - Flags: approval1.9.2.15?
Attachment #509442 - Flags: approval1.9.2.14?
Comment on attachment 509442 [details] [diff] [review]
Patch for mozilla-2.0

See comment 7. It looks like this would actually regress this bug on trunk, showing google.com but going to www.firefox.com.
Attachment #509442 - Flags: review?(dao) → review-
Actually, it looks like it wouldn't make a difference at all, at least not for the given testcase, as the links don't end up being nested there.
Comment on attachment 509442 [details] [diff] [review]
Patch for mozilla-2.0

Please wait for r+ before requesting approval.
Attachment #509442 - Flags: approval1.9.2.15?
Attachment #509442 - Flags: approval1.9.2.14?
Attached file testcase
This reliably produces nested links on trunk. As opposed to Firefox 3.6, the bug doesn't occur.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [sg:low spoof] bug 266932 is back → [sg:low spoof] [fixed by bug 331959]
Target Milestone: --- → Firefox 4.0b9
Comment on attachment 509371 [details] [diff] [review]
Bug 578477 Patch

I don't think we need to worry about this on the 1.9.2 branch at this point.
Attachment #509371 - Flags: review?(dao)
Attachment #509371 - Flags: review?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: