Closed Bug 257307 Opened 20 years ago Closed 1 year ago

phishing, link manipulated with javascript

Categories

(Core :: DOM: Core & HTML, defect, P5)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mrclone, Unassigned)

References

Details

(Keywords: csectype-spoof) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

Hi, this is my first bug report ...

I manipulated a link with javascript, when you hover in, the status bar will
display http://www.mozilla.org, but when you click, the browser will open
http://www.google.com (even when disallowing "change status bar text"), tested
on mozilla/firefox, internet explorer an opera. The script edit the value of
href on Click, I think that is a bug, because this could be used for phishing:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    <title>bug?</title>
    <script language="JavaScript">
      function test(obj) {
        obj.href = "http://www.google.com";
      }
    </script>
  </head>
  <body>
    <a href="http://www.mozilla.org/" onClick="javascript:test(this)"
title="http://www.mozilla.org/" alt="http://www.mozilla.org/"
target="_self">mozilla.org</a>
  </body>
</html>


sorry for my bad english ;)

Reproducible: Always
Steps to Reproduce:
This is well known, I don't think there's anything that can be done (short of
turning off javascript) to prevent all kinds of tricks.  This effect can be
accomplished more simply using onClick="location='http://www.google.com'". That
won't do quite the same thing if people attempt to open the link in a new tab
using ctrl-click and the like, but good enough to catch the sort of people who
might fall for a phishing attempt in the first place.

wontfix?
Assignee: dveditz → general
Group: security
Component: Security: General → DOM
QA Contact: ian
Whiteboard: [sg:nse]
*** Bug 285667 has been marked as a duplicate of this bug. ***
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Hump! I see this bug is about to get dropped and I don't know whether it is
being worked on, so will add my two cents worth... Just because there has been
no activity on it does not mean it is an invalid bug report. Please analyize it
first and THINK about it! This is a serious security flaw and needs to be addressed.

As for Daniel Veditz's conclusion that nothing can be done about this, speaking
now as a software engineer myself (over 30 years of experience) boy do I have to
strongly disagree with you!  I also reported another simpler version of this
problem which certainly can be handled very easily, see bug 285667. It requires
a simple fix and doing a straight forward check/fix on it would catch a lot of
philsing attempts.

There are two possible scenerios that a user may face when he/she is about to
click on a link. This first scenerio is when the user is presented, up front,
with information about what the purported target URL will be, that when he/she
clicks on the link, the brower will transition to and display. This commonly
occurs when html code such as <a
href="http://www.somebogusdomain.com/index.html"> http://www.somedomain.com</a>
is used, or as was shown in the example for this bug report. 

The second scenerio occurs when the user is NOT presented up front with
information about what the target URL will be, or the browser/email client app
does not have enough info to make an automagic verification, as in <a
href="http://www.somebogusdomain.com/index.htm">Click here to go to our
website.</a> or even worse <p><a
href="http://www.somebogusdomain.com/index.htm">Click here </a> to go to
http://www.somedomain.com.</p> While, yes the target link will show up in the
status bar of the browser, before the transition occurs, it is still
questionable, especially when this type of link occurs in an email, and I will
address it also. .

Philshing detection for the first scenerio described above is simple to do as
this is a simple verifiable state change transition in all its variations. Here
the user was presented, in a secondary fashion, what the purported target URL
will be within a structured context and in a valid URL format. In other words,
the client app - Firefox, Mozilla, or Thunderbird - simply has to check if the
user was presented with a valid URL (requires some clever parsing but not all
that difficult to do), record what the purported target URL will be, for state
transition the user believes will happen when he clicks on a link. In other
words, the URL the user believes the browser will be transitioning to, based on
the information that was presented to him in the link. The client app then
compares that against the actual URL reached, brought on by the state transition
that occurred (i.e. the URL actually reached). Upon comparison of the two,
before the client app actually has the new page displayed, it presents the user
with a warning dialog, if the two are different, and presents him/her with
choices of A) accept the transition, B) Reject the transition, C) Mark the
transition as OK for all future occurances of it, D) Mark the transition as
Unaccepted for all future occurances.. 

Since it is possible for server side redirections to occur, I would limit the
comparisons of the URL's, before and after the transition, to just the base
portion and verify that the domains at least remain consistant. That will still
cause some false dialog boxes to be presented to the user, if an when a server
redirects a page to a new domain, but I should think that won't happen all that
often, and the client app can be trained to accept these. This cost to the user
is far better than having him be lead to a philsher unknowningly.

As for the second scenerio I describe, where the user was not presented up front
with the target URL, within a structured context, may I propose handling this in
a more passive way. (I am sure there are other possible answers and this could
be the subject of some good brainstorming)  Present the user with an icon in the
toolbar of the browser indicating that the page was transitioned to from a
questionable link. In other words, this icon is presented when the browser was
unable to automagically confirm that the transition was truely a valid and/or
expected one. If the user clicks on this icon, then present him/her with the
aforemention dialog box to allow him/her to train the browser to accept or
reject all future attempts to reach that particular webpage. At least the
browser is now attempting to bring it to the users attention that the target URL
reached, should be verified, but because it is passive the user is not required
to do so. The dialog box should also make some simple suggestions as to how to
verify a URL, such as looking closely at the domain name and see if it makes
reasonable sense.

Personally, I feel this problem is far more serious when it occurs in emails
with html, than on webpages directly, and the Thunderbird team should be paying
very close attention to this. In this case, the checking/verification has to
occur between the link the user is clicking on in an email, and the URL that is
being used when the web browser is about to be launched. If the
checking/verification cannot be done, as described in scenerio two, then one
possible solution is the interface between Thunderbird and Firefox may have to
be extended a bit so that Thunderbird can inform Firefox that the link is
questionable. Another might be to have the user confirm, via a dialog box, that
he/she truely wants to bring up the browser on a website that came from a
questionable link.

If you have ever programmed relational databases, this kind of transition
checking is done all the time.. No rocket computer science here! I won't argue
that this will cover all philshing attempts, but it will eleminate or help
eleminate some of the most obvious ones and it will not require any difficult
programming. Especially if the teams have been and are using good object
oriented programming techniques and code reuse. ;-)
Whiteboard: [sg:nse]
Assignee: general → nobody
QA Contact: ian → general
Blocks: 325274
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: csec-spoof
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3
Duplicate of this bug: 1805585

Issues in DOM tree https://dom.spec.whatwg.org & HTML https://html.spec.whatwg.org that do not fit into any other DOM or HTML component or which span multiple DOM or HTML components.

This bug shows a violation in the WHATWG HTML specification 15.7.1 (https://html.spec.whatwg.org/multipage/rendering.html#links,-forms,-and-navigation) and so while it is 'just the way the web works' it is a necessary change to the browser in order to maintain compliance with the standards. (See bug 1805585)

This can be fixed by not allowing JavaScript to arbitrarily change navigation links as they are clicked.

  • Create a cached copy of the clicked link destination and navigate there (so that JavaScript cannot change the destination)
  • Clicking a link causes the browser to navigate to the page before any JavaScript can run

(In reply to cc.bugreporting from comment #12)

Issues in DOM tree https://dom.spec.whatwg.org & HTML https://html.spec.whatwg.org that do not fit into any other DOM or HTML component or which span multiple DOM or HTML components.

This bug shows a violation in the WHATWG HTML specification 15.7.1 (https://html.spec.whatwg.org/multipage/rendering.html#links,-forms,-and-navigation)

How? That section is not normative, to begin with. The spec sections that specify this is this and this and this and this, and more in particular this, which works as defined in the spec afaict.

This can be fixed by not allowing JavaScript to arbitrarily change navigation links as they are clicked.

  • Create a cached copy of the clicked link destination and navigate there (so that JavaScript cannot change the destination)
  • Clicking a link causes the browser to navigate to the page before any JavaScript can run

What does "as they are clicked" mean? After mousedown? After mouseup? What if js does link.click()? Even if you did that somehow in a well defined way that didn't break the web, JS could still preventDefault() the navigation and run window.open() instead, bypassing all this mechanism altogether.

This just doesn't seem particularly fixable, as described. The only potential "fix" I can think of is some kind of prompt that did something like, if the link was modified in the last 100ms (or so?), confirm that the user wants to go to the target URI? Still rather annoying for the end user, tho, and again won't fix the window.open() case.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.