Last Comment Bug 415034 - Referer spoofing by including '@' in URL
: Referer spoofing by including '@' in URL
[sg:moderate][needs trunk baking?] ca...
: verified1.8.1.13
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: unspecified
: All All
P2 normal (vote)
: mozilla1.9beta4
Assigned To: Daniel Veditz [:dveditz]
: Patrick McManus [:mcmanus]
Depends on: 419116
Blocks: 415496 415500
  Show dependency treegraph
Reported: 2008-01-30 23:09 PST by Gregory Fleischer
Modified: 2008-04-16 12:22 PDT (History)
17 users (show)
mbeltzner: blocking1.9+
dveditz: blocking1.8.1.13+
dveditz: wanted1.8.1.x+
jwalden+bmo: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Example that demonstrates the problem (2.05 KB, application/x-gzip)
2008-01-30 23:23 PST, Gregory Fleischer
no flags Details
return errors for userinfo without a username (2.72 KB, patch)
2008-02-03 18:23 PST, Daniel Veditz [:dveditz]
cbiesinger: review+
benjamin: superreview+
dveditz: approval1.8.1.13+
Details | Diff | Splinter Review
"friendlier" fix (but phish-friendly too) (2.41 KB, patch)
2008-02-03 23:01 PST, Daniel Veditz [:dveditz]
no flags Details | Diff | Splinter Review

Description User image Gregory Fleischer 2008-01-30 23:09:17 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20071127 Firefox/
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20071127 Firefox/

RSnake observed in "Firefox weird referrer problem" (,20033,20041#msg-20041) that Firefox generates incorrect Referer headers when a '@' is included in a URL.  So, by linking from '', referer values referencing '' 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:

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: Gecko/20080130 BonEcho/
Comment 1 User image Gregory Fleischer 2008-01-30 23:23:36 PST
Created attachment 300605 [details]
Example that demonstrates the problem

This is just a tarball of the files that I reproduced the problem with.

I added "" and "" to my local /etc/host file. E.g.,  localhost

I added named VirtualHosts to my Apache configuration for "" and "".  The "" site needs ExecCGI.

For example,

    DocumentRoot /var/www/referer-spoofing-with-at/
    <Location / >
    Options +ExecCGI 
    DocumentRoot /var/www/referer-spoofing-with-at/

The "" has a CGI script that protects its "secret" resource by checking that the referer matches ''.  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 "" site, the "auth" and "de-auth" actions set the authentication cookie.

The "" site is the malicious site.  It attempts to make CSRF calls to access the secret resource at "".

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.
Comment 2 User image Gregory Fleischer 2008-01-30 23:28:52 PST
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.
Comment 3 User image Gregory Fleischer 2008-01-31 09:54:20 PST
Online demo:

For this demo, I'm using "" and "" (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 "" has their payroll system at "", a local attacker could register his machine name as "xpayroll" through DHCP and configure a web-server to launch CSRF attacks as "".  CSRF attacks using GET and POST methods with referer of "" would both be possible.
Comment 4 User image Daniel Veditz [:dveditz] 2008-01-31 23:09:24 PST
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.
Comment 5 User image Mike Beltzner [:beltzner, not reading bugmail] 2008-02-02 14:44:03 PST
Same as/similar to: ?
Comment 6 User image :Gavin Sharp [email:] 2008-02-02 19:23:21 PST
(In reply to comment #5)
> Same as/similar to: ?

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.
Comment 7 User image Gregory Fleischer 2008-02-02 19:59:01 PST
(In reply to comment #6)
> (In reply to comment #5)
> > Same as/similar to: ?
> 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.

Comment 8 User image David Baron :dbaron: ⌚️UTC-8 2008-02-02 22:01:46 PST
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.)
Comment 9 User image Daniel Veditz [:dveditz] 2008-02-03 13:31:18 PST
About the 3rd or 4th comment in the thread thornmaker notes that 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
Comment 10 User image Daniel Veditz [:dveditz] 2008-02-03 18:23:32 PST
Created attachment 301201 [details] [diff] [review]
return errors for userinfo without a username

Here's one approach, consider a userinfo section without a username an error. That means an empty userinfo ( or one with only a password (

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.
Comment 11 User image Daniel Veditz [:dveditz] 2008-02-03 23:01:03 PST
Created attachment 301233 [details] [diff] [review]
"friendlier" fix (but phish-friendly too)

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 but we do not, and still would not with this patch, warn on, which from a spoofing POV is probably close enough to be useful to phishers.
Comment 12 User image Daniel Veditz [:dveditz] 2008-02-20 17:25:24 PST
Checking in src/nsStandardURL.cpp;
/cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp,v  <--  nsStandardURL.cpp
new revision: 1.107; previous revision: 1.106
Checking in src/nsURLParsers.cpp;
/cvsroot/mozilla/netwerk/base/src/nsURLParsers.cpp,v  <--  nsURLParsers.cpp
new revision: 1.30; previous revision: 1.29
Comment 13 User image Daniel Veditz [:dveditz] 2008-02-22 11:12:46 PST
Comment on attachment 301201 [details] [diff] [review]
return errors for userinfo without a username

approved for, a=dveditz for release-drivers
Comment 14 User image Daniel Veditz [:dveditz] 2008-03-03 12:40:20 PST
Checked into 1.8 branch
Comment 15 User image Daniel Veditz [:dveditz] 2008-03-07 14:37:22 PST
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).
Comment 16 User image Al Billings [:abillings] 2008-03-17 17:53:08 PDT
I verified this was fixed for using the test site and build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008031114 Firefox/
Comment 17 User image Alexander Sack 2008-03-23 12:37:40 PDT
Comment on attachment 301201 [details] [diff] [review]
return errors for userinfo without a username

taking this for 1.8.0 distro patches.
Comment 18 User image Alexander Sack 2008-04-16 12:22:45 PDT
1.8.0 branch should receive regression fix in bug 419116 as well.

Note You need to log in before you can comment on or make changes to this bug.