307087 - When viewing an HTML email message that contains a <AREA HREF="..."> inside of a <A HREF="..."> tag the statusbar incorectly displays the URL for the <A> rather than for the <AREA>.

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Dave Young]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

This is a very serious problem as the average user who receives a spoof/phish
email and notices the status bar message will in all likelihood assume that the
message is valid and click through.

If an email contains the following valid HTML:

<a href="https://www.looks-like-a-valid-site-url.com/login/">
  <map name="pphu">
    <area coords="0, 0, 646, 569" shape="rect"
     href="http://211.62.125.100/.../e3b/">
  </map>
  <img SRC="cid:part1.....">
</a>

The status bar displays https://www.looks-like-a-valid-site-url.com/login/
whenever the mouse is positioned over the <AREA> tag's clickable area.

In this case the user is deceived twice, once because of the incorrect URL in
the status bar, and once because they notice the HTTPS:// and probably assume
that they are okay because they have been given to believe that HTTPS
corresponds to a secure website connection.

This problem is easily dealt with, from an end-user standpoint, by paying closer
attention to email they receive and by taking the time to educate themselves of
the various ways phishing, spoofing, and spamming occur. Realistically this just
is not going to happen.





Reproducible: Always

Steps to Reproduce:
Please see the details section for a description of how to reproduce the behavior.

Actual Results:  
The statusbar displays a URL that is not the actual destination the user's
default web browser will navigate to if the user clicks within the <AREA> tags
coordinates.

Expected Results:  
The URL of the actual destination should be shown in the status bar, not for the
bounding <A> tag.

This represents an opportunity to add a strong layer of protection with very
little impact on the ability of Thunderbird to accurately render HTML content!

If nothing else is fixed and/or modified other then the status bar text then at
least the end-user will have something that may give pause to them before
clicking through.

However, why not go one step further. It would be a very simple matter for
Thunderbird to parse the HTML prior to rendering in order to determine if just
this sort of questionable code exists in the message. If so the program can flag
the message as spam so that the end user has a CLEAR indication of a possible
problem with the message, allowing them the opportunity to investigate.

I understand the use of <AREA> tags within <A> tags is valid HTML. However, of
the many HTML emails that I receive daily I have yet to encounter a valid
message that uses <AREA> tags within <A> tags.

The worst thing that will occur if my suggestion is implemented is that the
end-user will, hopefully after verifying the validity of the suspect message,
will need to add the message's sender to their collected addresses list.

Given the growing number of people affected by more and more sophisticated and
authentic looking spoofing/phishing attacks, it would seem to me that the
benefits will far outweigh the minor inconvenience the end-user may experience.

Comment 1

[Dave Young]

Thunderbird version 1.0.6 (20050716)
Occurs on systems running Windows XP SP1, SP1a, & SP2

Comment 2

[Daniel Veditz [:dveditz]]

*** Bug 316899 has been marked as a duplicate of this bug. ***

Comment 3

[Daniel Veditz [:dveditz]]

From the dupe: this happens on 1.5 also, and may require the mail being classed as spam or a scam to get this rendering.

Comment 4

[Jesse Ruderman]

This is a special case of bug 266932.

Comment 5

[Scott MacGregor]

Moving off bugs that didn't make the deadline for Thunderbird 2. 

Comment 6

[Daniel Veditz [:dveditz]]

Keeping this bug hidden obviously isn't helping get it fixed

Comment 7

[Phil Ringnalda (:philor)]

Attachment: Ineffective testcase

If I'm doing it right, this is now pretty well mitigated, probably by bug 234455 - even sending myself this email, so it's marked as scammy, I get the inner URL in the statusbar on mouseover, and that's the URL that's opened on click or copied, so the only remaining issue is that the outer URL is shown onclick. I'm having trouble picturing a successful scam that can be worked by showing a URL that won't be loaded, only while the mouse is down in a (left or right) click.