137286 - browser should display warning when current page URL contains lengthy username@

Status: VERIFIED DUPLICATE of bug 122445

(Core :: Security, enhancement)

Description

[Simon Willison]

The following evolt article describes a simple but highly effective exploit for
stealing web application passwords:

http://www.evolt.org/article/Security_weaknesses_in_the_Passport_Security_Model/25/22404/index.html

To summarise, an attacker can create a fake login form identical to the real one
and obscure the location of the fake form by providing a link to it that looks
something like this:

www.hotmail.com&login?something=lots-and-lots-of-garbage-whos-soul-intent-is-to-
obscure-the-fact-that-this-is-actually-a-username-and-not-a-proper-url-by-ensuring-
[e-mail]/steal.cgi

While savvy internet users will know about the @ URL trick even the most
vigilant of users could be caught out by a suitable long URL - after all, how
many people scroll sideways in their URL bar to check there is no rogue @ sign?

I propose Mozilla should display a warning message in a javascript-alert style
box whenever a user loads a page which includes a username longer than 20
characters in the URL. I have never known a legitimate site use a lengthy
username as part of a URL, so a warning message would be unlikely to pose an
inconvenience. Something like this would be ideal:

Warning: The page you are visiting contains a username longer than 20 characters
in the URL. The real address of the site is "cracker.com/steal.cgi"

Comment 1

[Vadim Berezniker]

I'm pretty sure that this has already been filing, just can't find it at the moment.

Comment 2

[Simon Willison]

Attachment: example javascript implementation

This is an example javascript implementation of the warning mechanism. I tested
it by adding it to the mozilla gesture recognition package as I was unsure how
to add it to the browser in any other way.

Comment 3

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 122445 ***

Comment 4

[benc]

VERIFIED/dupe:

simon, thanks for the javascript code, it was a good idea, but there are several
formats for this exploit.

We probably want something which is hooked into the URL parser, to minimize th
chance of a parsing-gap (we've had problems w/ hostname parsing in cookies).