Closed Bug 257307 Opened 20 years ago Closed 2 years 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: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.