267333 - command clicking malformed url does wrong thing

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Jon Stevens]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041019 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041019 Camino/0.8+

When you *command click* on this HTML link...

<a
href="http://https://voteprotect.org/index.php?display=EIRMapNation">voteproject.org</a>

It attempts to connect to this url...

http://www.https.com//voteprotect.org/index.php?display=EIRMapNation

NOTE: You need to command click. A regular click on the link will display an
error as it should.

Seems like it could be a security hole if the person who owns www.https.com and
decides to put up a page asking for your credit card info or something...

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Pinkerton (not reading bugmail)]

worth fixing, doubt it's major.

Comment 2

[Uri Bernstein]

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

Comment 3

[Uri Bernstein]

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

Comment 4

[Jon Stevens]

sorry about all the duplicates. bugzilla was so slow that it was timing out my
browser when i was submitting the issue.

jon

Comment 5

[Josh Aas]

This happens in Mozilla 1.7.3 as well. Not Camino specific.

I cannot easily test whether or not this is a problem in Firefox right now.
Could someone else confirm whether or not it is? Is a problem on platforms other
than Mac OS X (I would guess it would be)? Is this actually a security issue?

Comment 6

[jhp (no longer active)]

Hmm, using Firefox on both Mac and Linux, I don't get an error when go to that
URL.  In both cases (regular click & Cmd+click), the page loads as www.paypal.com.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

url is not malformed, fixing summary

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

oh, hmm. I guess it may be malformed, since no port is given after the ':';
restoring summary

Comment 9

[Darin Fisher]

Some info about URL parsing...

Necko parses "http://https://voteprotect.org/index.php?display=EIRMapNation" as:

  scheme    = http
  host      = https
  port      = -1 (unspecified)
  path      = //voteprotect.org/index.php?display=EIRMapNation

So, moz then tries to connect to the host "https" on port 80.  That fails, and
then docshell's URL fixup code tries to fixup the hostname by generating
"www.https.com" from "https", and then it tries to load the resulting URL.

Comment 10

[Josh Aas]

The problem does not exist in Firefox 1.0 on Linux. In both cases it loads
https.com where in the regular case (no key modifier) on Mac OS X the URL fails
to load. If we can get this checked on Windows we might be able to isolate it to
Mac OS X. I suppose it could also only be a problem in the moz suite.

Comment 11

[Mike Pinkerton (not reading bugmail)]

-> josh, core mac bug

Comment 12

[Josh Aas]

What exactly is the correct behavior here? Is the docshell fixup code wrong to attempt to connect to https.com? Which should it be:

1)
No command key: error
Command key: https.com
2)
No command key: error
Command key: error
3)
No command key: https.com
Command key: https.com

I suspect #2 is the right option here, but if it isn't #1 that is correct, then what are the rules for docshell URL fixups that make #1 incorrect?

Comment 13

[Patrick McManus [:mcmanus]]

given that this is a malformed url, changing behavior seems to be riskier than staying put.