Closed Bug 263263 Opened 20 years ago Closed 20 years ago

Dialog box asks if I meant to load www.google.com. If I answer no, it loads anyway.

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: RussellPage, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: [sg:nse])

Attachments

(3 files)

Displays two links that labelled "www.microsoft.com", but which direct the browser to "www.google.com"
194 bytes, text/html
Details
v1 patch
1.36 KB, patch
bzbarsky
: review+
dveditz
: superreview+
asa
: approval-aviary+
dveditz
: approval1.7.5+
Details | Diff | Splinter Review
v1 patch - backported to 1.7 branch
1.23 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

The following HTML is cut from
"http://isc.sans.org/presentations/urlobfuscation.php":
----snip--------snip----
<html>
<p>
@: <A HREF="http://www.microsoft.com@www.google.com">www.microsoft.com</A><p>

%01%00@: <A
HREF="http://www.microsoft.com%01%00@www.google.com">www.microsoft.com</A><p>
</html>
"
Every time I click on one or other of the two links a dialog box pops up with
the following text:
"You are about to log into the site "www.google.com" with the username
__varies__, but the site does not require authentication. This may be an attempt
to trick you. Is "www.google.com" the site you want to visit?

There are a "Yes" and a "No" button in the client area of the dialog box, and a
Windoze Close (X) button on the title bar. No matter which button I click,
www.google.com loads.

Reproducible: Always
Steps to Reproduce:
1. Copy html into a file called "unsafe.html"
2. Double click on "unsafe.html" (assuming Firefox is your default browser)
3. Click on each link in turn. Click "No" or the Close button on the dialog box
that pops up.

Actual Results:  
The browser loads www.google.com

Expected Results:  
The browser should not have loaded the page! These are two examples of spoofed
URLs used to induce users to dangerous web pages.
A full page of malformed URLs can be found at
http://isc.sans.org/presentations/urlobfuscation.php

Firefox performs reasonably for all the other cases on that page.
WFM, both the exact firefox version you cite and Mozilla. If I use the "No"
button, the close button, or the ESC key, I remain on the sans page and do not
go to google.

Even if true this wouldn't be a security exploit that needs the confidential
flag: the user *is* warned about the phishy url. It would be just a bug.
Assignee: bugs → darin
Group: security
Component: Web Site → Networking: HTTP
Product: Firefox → Browser
Whiteboard: [sg:nse]
Version: unspecified → 1.7 Branch
Some see it, some don't. My $0.02 on why it is so:
Depending on your location, the google server might reply with a 302. If so, the
redirection is processed even if the user tries to cancel.
Confirming (I'm in Germany and get redirected to google.de, with Mozilla
1.7.something)
Status: UNCONFIRMED → NEW
Ever confirmed: true
It appears the behaviour I see occurs only when the "hidden" page has to be 
fetched through a proxy server.

When I switched to an authenticating proxy I was prompted for my proxy ID and 
password before the "Confirm" dialog pops up ...

Here is a new version of "unsafe.html"
----snip--------snip----
<html>
<p>
@: <A HREF="http://www.microsoft.com@banshee">www.microsoft.com</A><p>

%01%00@: <A HREF="http://www.microsoft.com%01%
00@www.google.com">www.microsoft.com</A><p>
</html>
----snip--------snip----

There is a web server running on the host banshee, which is on the same subnet 
as my workstation. Firefox is not accessing it through the proxy.

When I click on the first link, I get the confirm dialog. If I close the 
dialog or answer "No" then the "hidden" page is not loaded. When I click on 
the second link, I still get the behaviour I reported earlier.

It seems that the page is being loaded early if it is being accessed through a 
proxy ... perhaps an optimization to have it load more quickly if the user 
answers "Ye
I've been seeing this too, but not been able to reproduce.  But Andrei has the
right of it, I think.  The following URI shows the problem for me 100% of the time:

  http://spoofer@bugzilla.mozilla.org/

(Note that this does a redirect to the https version, which is why I think
Andrei is right).  Seeing this on trunk Linux.
OS: Windows XP → All
Hardware: PC → All
Version: 1.7 Branch → Trunk
Requesting blocking status; this looks really bad from an end-user perspective...
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Wait, it gets worse - Boris gave me the idea.
Load any page BUT one from bugzilla.mozilla.org (e.g. google), then try this:

   https://whatever@bugzilla.mozilla.org

(make sure it's https so no redirection occurs) then cancel when asked. The one
bug we were discussing so far does not manifest itself, but the address bar is
still https://whatever@bugzilla.mozilla.org AND the site you started from (e.g.
google) appears signed by Thawte Consulting cc.

I was tempted to submit it as a new bug, but upon some consideration decided not
to. I think the underlying reason is the same: some caching/processing going on
that is not aborted despite the user requesting so.

Mozilla/5.0 (Windows; U; Win98; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
darin, can you have a look?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
OK, this bug is caused by the fact that CheckForSuperfluousAuth() calls Cancel
on the nsHttpChannel if the user presses 'no' in the dialog.  If we are
processing a redirect, however, we will not check if the channel was canceled. 
As a result, we will continue to follow the redirect.  The solution is probably
to check for cancelation after the call to CheckForSuperfluousAuth() returns,
and bail if necessary.
Attached patch v1 patch — — Splinter Review 
simple patch ... might want to do something similar for the other callsite of
CheckForSuperfluousAuth (not sure yet).  it would also be nice to rework much
of this code so that errors could just be returned back to the caller of
ProcessResponse, causing the caller to set mStatus to the error code and invoke
OnStartRequest.
Attachment #161798 - Flags: review?(bzbarsky)
Comment on attachment 161798 [details] [diff] [review]
v1 patch

r=bzbarsky
Attachment #161798 - Flags: review?(bzbarsky) → review+
Comment on attachment 161798 [details] [diff] [review]
v1 patch

sr=dveditz, a=dveditz for 1.7 branch
Attachment #161798 - Flags: superreview+
Attachment #161798 - Flags: approval1.7.x+
Attachment #161798 - Flags: approval-aviary?
same code change as trunk patch, but this one applies cleanly on the 1.7 branch
(should also apply to the aviary 1.0 branch).
fixed-on-trunk, fixed1.7.x
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed1.7.x
Resolution: --- → FIXED
Comment on attachment 161798 [details] [diff] [review]
v1 patch

a=asa for aviary checkin.
Attachment #161798 - Flags: approval-aviary? → approval-aviary+
fixed-aviary1.0
Keywords: fixed-aviary1.0
Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:1.8a5) Gecko/20041014

Just built my own lizard. It seems that the problem I adressed in my last
comment (#8) is still present.

I will outline the steps to reproduce:
1. Load some neutral page (e.g. sluggy.com)
2. Type in the address bar something like
     https://user[:pass]@foo.bar.com, where foo.bar.com is a secure server that
     does not use basic auth.
     Example: https://evilme@www.paypal.com
3. The CheckForSuperfluousAuth() dialog pops up. Click on No.

Actual results:
The address bar does not revert to the initial state (e.g. sluggy.com) (spoof?).
The security icon signals an encrypted connection.
The security certificate of foo.bar.com is shown and can be inspected in the
page properties.

Expected results:
The address bar content should match the content of the displayed page.
No security tokens from foo.bar.com should persist.

I still think this is just another avatar of the same bug...
> I still think this is just another avatar of the same bug...

It's not, really...  That bug involves the interaction of UI code and the HTTP
impl, while this bug was a core HTTP impl bug.

Please file a separate bug on that issue?
Right, thanks for the input Boris.
Filed as bug 264486
*** Bug 264486 has been marked as a duplicate of this bug. ***
Flags: blocking1.7.5?
Blocks: 248511
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: