Protect passwords from being sent when user fails to escape "#" in user:pass in the address bar

RESOLVED DUPLICATE of bug 662206

Status

()

Firefox
Address Bar
RESOLVED DUPLICATE of bug 662206
7 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

({sec-low})

Trunk
x86_64
Mac OS X
sec-low
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low])

(Reporter)

Description

7 years ago
Suppose cPanel generated the password "81#sword" for me.

1. Type into the address bar:
      ftp://user:81#sword@host/

Result: 
      Firefox tries to connect to "user" on port 81 and reveals my password to that server, if it exists.

Expected:
      Firefox should tell me I messed up (or escape the "#" for me?). It is very unusual to specify a port AND omit the "/" before "#".

Background:
      Some password generators create passwords with "#", not expecting that users will try to create URLs containing the password. It's less obvious that "#" needs to be escaped than "/" (see bug 454241). This problem was pointed out by avih.
      This is a trickier case than bug 662206, because the password starting with numbers makes it a possibly valid URL.
Is there a way for an attacker to actually make use of this?
(Reporter)

Comment 2

6 years ago
A network attacker could take control of DNS for all dotless hostnames. It would be quite a passive attack. Comcast does this, for example.
(Reporter)

Comment 3

6 years ago
"Passive" as in waiting for someone to make this mistake, not "Passive" as in "Passive network attack".
How about we just disable the ability to type URL containing username/password? (If you do, we just strip and ignore the input). That at least, in the long term, removes the expectation that entry of such URLs is expected.

URLs with user/pass included have been nothing but trouble, and are rather infrequently used. So I'm quite willing to explore just dropping support for typing them.

I'm not sure there's any other way to fix this bug without weird heuristics. It's a perfectly valid URL, just not with the parts where you might expect.
(In reply to Justin Dolske [:Dolske] from comment #4)
> How about we just disable the ability to type URL containing
> username/password? (If you do, we just strip and ignore the input).

This is what IE has done since IE6 SP1 [1] unless you make registry changes. This would lead me to believe that it won't break the web but there is potential to break intranets.  I agree with this approach though.

[1] http://support.microsoft.com/kb/834489
Keywords: sec-low
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 662206
(In reply to Justin Dolske [:Dolske] from comment #6)
> 
> *** This bug has been marked as a duplicate of bug 662206 ***

We duped this despite the distinction being made in comment 0, because we think the WONTFIX comments in bug 662206 apply equally to this bug.
You need to log in before you can comment on or make changes to this bug.