User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 RSnake observed in "Firefox weird referrer problem" (http://sla.ckers.org/forum/read.php?10,20033,20041#msg-20041) that Firefox generates incorrect Referer headers when a '@' is included in a URL. So, by linking from 'http://@xbank.com/', referer values referencing 'http://bank.com/' would be generated. Sites may be at risk if another malicious domain name could be registered such that by removing the left most character a match is made. If that original site depended on referer checking for CSRF protection, it could be vulnerable if users could be induced to visit the malicious site. Reproducible: Always Steps to Reproduce: 1. 2. 3. Additional validation with latest user agents: - Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008013004 Minefield/3.0b3pre - Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.12pre) Gecko/20080130 BonEcho/2.0.0.12pre

This is just a tarball of the files that I reproduced the problem with. I added "xbank.com" and "bank.com" to my local /etc/host file. E.g., 127.0.0.1 localhost xbank.com bank.com I added named VirtualHosts to my Apache configuration for "bank.com" and "xbank.com". The "bank.com" site needs ExecCGI. For example, <VirtualHost 127.0.0.1:80> ServerAdmin webmaster@dummy-host.example.com DocumentRoot /var/www/referer-spoofing-with-at/bank.com ServerName bank.com <Location / > Options +ExecCGI </Location> </VirtualHost> <VirtualHost 127.0.0.1:80> ServerAdmin webmaster@dummy-host.example.com DocumentRoot /var/www/referer-spoofing-with-at/xbank.com ServerName xbank.com </VirtualHost> The "bank.com" has a CGI script that protects its "secret" resource by checking that the referer matches 'http://bank.com/'. Additionally, it checks to see if a cookie is set. If these pass, the resource is returned; otherwise, error messages matching the failed condition are returned. By navigating to the "bank.com" site, the "auth" and "de-auth" actions set the authentication cookie. The "xbank.com" site is the malicious site. It attempts to make CSRF calls to access the secret resource at "bank.com". Different tests are launched from "/referer-spoofing-with-at/index.html". These progress through different stages of including the '@' in the URL. The "frame2" test is the most realistic.

I left this marked as security sensitive since no POC was made public. Open it up if you feel it is appropriate. I'll try to get an online demo setup so it is either to test.

Online demo: http://pseudo-flaw.net/r/referer-spoofing-with-at/ For this demo, I'm using "xbank.pseudo-flaw.net" and "bank.pseudo-flaw.net" (hopefully, the subdomains have finished propagating through DNS). I also thought I'd point out that this issue doesn't only affect TLDs. In addition to internet sites, intranet websites within a LAN environment could be impacted if DNS registration is allowed through DHCP. For example, if "example.biz" has their payroll system at "payroll.example.biz", a local attacker could register his machine name as "xpayroll" through DHCP and configure a web-server to launch CSRF attacks as "xpayroll.example.biz". CSRF attacks using GET and POST methods with referer of "payroll.example.biz" would both be possible.

Confirming, the broken referrers are easy to see (LiveHttpHeaders or similar tool). Thanks for filing this as security-sensitive as it does set off alarm bells and get attention. But now that we've noticed it can probably be opened given the public source. Otherwise we'll just collect dupes -- any objection? There were reports it didn't happen to everyone or didn't happen on Minefield. I see the flaw in recent versions of both FF2 and FF3.

Same as/similar to: http://www.0x000000.com/?i=509 ?

(In reply to comment #5) > Same as/similar to: http://www.0x000000.com/?i=509 ? That post doesn't mention the referer, so that seems unlikely to be related to this bug. I don't really understand what problem that post is highlighting, if any.

(In reply to comment #6) > (In reply to comment #5) > > Same as/similar to: http://www.0x000000.com/?i=509 ? > > That post doesn't mention the referer, so that seems unlikely to be related to > this bug. I don't really understand what problem that post is highlighting, if > any. > I agree that post doesn't have anything to do with this bug. The post seems to be suggesting that by specifying a SSL host that doesn't exist (or doesn't answer requests), the user can somehow be tricked into visiting the site by using the "Try Again" button. But that doesn't make any sense, because the post also states the rogue host is displayed in the URL bar. And, even if the host starts answering after the user selects "Try Again", the user name confirmation prompt is launched and the rogue host is displayed once again. So the user would have to ignore several warnings to actually interact with the rogue site. This doesn't seem different from the classic phishing attacks that disguised the true site by including the target site as the username in the authority section.

Perhaps the underlying problem is the same as that described in bug 415401 comment 1? (It seems like they are pretty much the same bug, except this one is a special case with empty password.)

About the 3rd or 4th comment in the sla.ckers.org thread thornmaker notes that http://:foo@p42.us/ results in a referer of http://s/. Bug 415401 is a straight-up dupe, and as far as I can tell the implications were realized in that thread. Some analysis of the code in bug 415401

Here's one approach, consider a userinfo section without a username an error. That means an empty userinfo (http://@example.com) or one with only a password (http://:foo@example.com). This makes some things that are currently valid links not links (e.g. some of the testcases in this bug). An alternate approach would be to simply ignore invalid sections. That's more or less what the current code does, except it messes up by remembering a length for the password. We could just set the password position and length to 0,-1 and it would just silently disappear. How strict do we want to be? I'd rather give errors to users so they stop this kind of thing than give them something they can play with and find holes in.

Silently drop empty or password-only user-info chunks. This is "friendlier" because such links will still work, but then it's quite possible to use the password part to create phishing links because users will not get the suspicious login warnings. That is, we warn on http://www.google.com@evil.com but we do not, and still would not with this patch, warn on http://:www.google.com@evil.com, which from a spoofing POV is probably close enough to be useful to phishers.

Checking in src/nsStandardURL.cpp; /cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp,v <-- nsStandardURL.cpp new revision: 1.107; previous revision: 1.106 done Checking in src/nsURLParsers.cpp; /cvsroot/mozilla/netwerk/base/src/nsURLParsers.cpp,v <-- nsURLParsers.cpp new revision: 1.30; previous revision: 1.29 done

Comment on attachment 301201 [details] [diff] [review] return errors for userinfo without a username approved for 1.8.1.13, a=dveditz for release-drivers

Checked into 1.8 branch

bug 419116 is a mail regression from this patch. Just in case there are other extensions doing the same thing (using "@host" regardless of whether there's userinfo or not) we should allow that case. As long as we don't mess with referrers it's OK (Opera also allows that form).

I verified this was fixed for 1.8.1.13 using the test site and build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13.

Comment on attachment 301201 [details] [diff] [review] return errors for userinfo without a username taking this for 1.8.0 distro patches.

1.8.0 branch should receive regression fix in bug 419116 as well.