User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121305 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121305 Minefield/3.0b3pre It seems like a reasonably easy and lightweight way to eliminate the "obfuscated domain name" phishing attack (e.g. www.mozilla.org.bugzilla.resource.showid.all.your.bugs.are.belong.to.us.com) would be to check to see if the first TLD in a url being visited is followed by a slash. If it isn't, warn users that the page is probably not what they are expecting. Reproducible: Always Steps to Reproduce: 1. Go to any myspace page. 2. Click on the first thing that looks like a video of a girl dancing. Actual Results: "Myspace" tells you that you need to log in to see the sexy sexy video. Expected Results: Firefox warns you that this page belongs to "haxors.r.us.com" instead of what it looks like "myspace.com". Maybe use the phishing warning page that already exists, but provide text along the lines of "It looks like the page you are trying to visit is trying to pretend that it is "innocent.com" but we would like to warn you that it actually belongs to "spammers.co.uk". If you were expecting to visit "spammers.co.uk" it is probably safe to click here, continue on to the page, and ignore this message.
I think this would have too many false positives: 1. http://de.wikipedia.org/ (.de) 2. http://www.history.uk.com/ (.uk) 3. http://news.com.com/ (.com) 4. http://www.net.com/ (.net) 5. http://www.museum.state.il.us/ (.museum) I guess you could use the heuristics that it's ok if the tld-lookalike appears at the beginning (optionally preceded by "www."), and it's ok if the tld-lookalike appears at the end (since those domains are expensive).
Yeah, another huge false-positive list is pages with "info" in their url. One thing I thought was: don't consider "info" a spoof if it's not ".info". And in response to yours: Don't consider it a spoof if the unexpected TLD is (exactly?) one dot away from the actual TLD. Another thing that could be done to reduce FPs would be to only apply this to pages that contain form elements. I'm not a coder so I don't know if that is more or less resource intensive, nor how easy it is to make a browser think that a page with forms doesn't have any.
Resolving unconfirmed bugs older than a year with no activity as INCOMPLETE. Please reopen or file a new bug if you can still reproduce the bug.
I think the only way this could work is with a whitelist, otherwise it's not the right way to let users know what domain they're on.
This is not a problem that can be easily solved. For example www.mozilla.co.uk would create a problems since .co is a TLD too (Colombia). And www.mozilla.co will probably become a valid domainname too, as they're opening up they're second level domain (it's already taken btw).
Jesse: when you reopened this bug did you have any workable heuristic in mind? The location bar approach (highlight the base domain (eTLD+1)) seems more workable because we know the real domain for sure but can only guess which parts might be misinterpreted as TLDs.
Reject if it has the pattern xxx.com.yyy, where "xxx" and "yyy" are non-TLDs and "com" is a TLD. This would allow all the common false-positive cases in comment 1, and it would make attacks expensive (the attacker would have to buy tld.tld). The fun part will be breaking nyud.net (coral cache).