Closed Bug 598478 Opened 14 years ago Closed 1 month ago

Wrong URL displayed on redirect when trying to leave Spam site by typing in new URL

Categories

(Camino Graveyard :: Security, defect)

Product:
Camino Graveyard
Component:
Security
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: juneappal, Unassigned)

References

(
URL
)

Details

(Keywords: sec-moderate, Whiteboard: [sg:moderate spoof]) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.19) Gecko/2010081818 Camino/2.0.4 (like Firefox/3.0.19)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.0.19) Gecko/2010081818 Camino/2.0.4 (like Firefox/3.0.19)

A specific get-rich-quick site (http://channelsixreports.tk/) hijacks attempts to leave by typing in a new URL - but Camino shows the URL I try to type in, not the one to Camino has been hijacked.  In combination with a decent spoofed login screen and phishing email, this could be used to harvest logins from people who think they are logging in to a safe site

Reproducible: Always

Steps to Reproduce:
1. Open a site such as http://channelsixreports.tk/ (Warning - it is a Spam site)
2. Regret opening it and type in a different URL in the URL bar.  Hit enter.

Actual Results:  
After step 2, camino briefly flashes a "do you want to leave this page" dialogue.  It then loads a second spam page.  I don't know the URL because the URL Shown in the URL field is NOT the URL for the spam page - instead the URL bar shows the URL I typed in.  

Expected Results:  
I expected that either: 
1.  The browser would open the page corresponding to the URL I typed in.
or 
2.  The browser would display the URL of the page to which I was redirected.

I hate to send anyone to a spam site, but you may have to open the link to understand what I am talking about.  I was sent there because a friend's Facebook account was hacked.  If the second spam website had been a fake FB login page, I would likely have "logged-in" thus giving away my password.

I have always told myself (and others) to look at the URL before logging in anywhere - that if the URL looks like it should, the login is safe.  This website/script combination defeats that safety check.

Here is a screenshot showing camino's URL bar not matching up with the page it loaded.  It is not on the web page I typed in, even though I typed it in, hit enter, and waited while it loaded up a (totally different) page:

http://www.flickr.com/photos/logchain/5013187922/


And here is the source of the page that displays: <html>


  <head>
    <title>channelsixreports.tk</title>
    <meta name="description" content="channelsixreports.tk">
    <meta name="keywords" content="channelsixreports.tk">
  </head>
  <frameset rows="*" framespacing="0" border="0" frameborder="NO">
    <frame src="http://allbigdeals.co.cc/ra/" name="dot_tk_frame_content" scrolling="auto" noresize>

  </frameset>
  <noframes>
    <body>
    </body>
  </noframes>

</html>
What looks like it's happening here is that the onbeforeunload sheet is getting cancelled somehow, so the user-input location in the location bar doesn't get acted upon, and then the page redirects, and the URL in the location bar doesn't get reset after page navigation?

I can reproduce this in builds on both branches (I see it in my debug 2.1a1pre, but not the nightly; not sure why).

A, can you reproduce this in Firefox 3.0.19 or 3.6.10?
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: camino2.1a1?
Flags: camino2.0.5?
Hmmm.....I'll check.....downloading Firefox......

Behavior is different in Firefox.  The dialogue asking if I want to leave doesn't instantly disappear.  While it is open, the redirect site loads up behind it, but the dialogue stays.  If I click "OK" (I do want to leave) then Firefox actually loads up the URL I type in.  If I click "cancel" then Firefox stays with the redirect page and leaves my URL in the navigation toolbar - but does not add the http:// in front like camino does.

Not great behavior on the part of FF, but not as bad as Camino.....

-Adam
Whiteboard: [sg:moderate spoof]
Flags: camino2.0.5? → camino2.0.5-
Hardware: x86_64 → All
Flags: camino2.0.6? → camino2.0.6-
Chris*, I don't know if this is something within your abilities to poke into or not, but I wanted to cc you in case it might be.  I suspect this is more of the  appshell hating real Cocoa apps, but I'm not sure.

The thing that bothers me the most is the onbeforeunload sheet is getting cancelled somehow, because that triggers us failing to leave editing mode in the location bar (and not acting on the user's input URL), which then opens up the spoof.

* why not have all 3 Camino Chris(topher)s cc'd :P
It sounds like this bug describes two problems:

1. onbeforeunload sheet is automatically dismissed without user clicking Cancel or OK button.

2. If the user clicks Cancel (or the onbeforeunload sheet is automatically dismissed?), then the location bar still displays the URL the user entered instead of the actual (spam site) URL.

I can reproduce problem #2 (the same behavior as Firefox) with Camino 2.0.x and 2.1a1pre nightlies, but I cannot reproduce problem #1. Is perhaps the dismissal of the onbeforeunload sheet timing-related
I'm working from memory here, because unfortunately the content of the frame (http://allbigdeals.co.cc/ra/) no longer displays any content or has an onbeforeunload, and I didn't save a local copy :(

Problem 1 causes problem 3 (the user is automatically redirected to a site not of his choosing, but the URL in the location bar is the URL to a different site that the user did attempt to visit); problem 3 is the security issue, but it's problem 1 that triggers it, and problem 1 that (I think) is where the fix needs to be.

Problem 2 is not a "problem" at all; it's normal for user-typed location-bar-content to remain in the location bar until after editing ends and tabs are switched (although if we can catch this specific case, an onbeforeunload Cancel that cancels navigation, we might want to consider resetting the location bar; dunno).
Oh, I forgot to comment on this:

(In reply to comment #4)
> but I cannot reproduce problem #1. Is perhaps the dismissal
> of the onbeforeunload sheet timing-related

I think it's dependent on the appshell being mad at you :P  FWIW, per comment 1, I couldn't trigger it in 2.1 with a nightly, only in my debug build, but apparently I saw it in 2.0 in both a nightly and my debug build.
Per the meeting, we're not blocking 2.1a1 on this, especially given the testcase is gone and it was hard to reproduce even with the testcase.  However, we'll take a patch whenever one appears ;)
Flags: camino2.1a1? → camino2.1a1-
Group: core-security
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.