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?
A network attacker could take control of DNS for all dotless hostnames. It would be quite a passive attack. Comcast does this, for example.
"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  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.  http://support.microsoft.com/kb/834489
(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.