Referer spoofing by including '@' in URL

RESOLVED FIXED in mozilla1.9beta4

Status

()

Core
Networking: HTTP
P2
normal
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: Gregory Fleischer, Assigned: dveditz)

Tracking

({verified1.8.1.13})

unspecified
mozilla1.9beta4
verified1.8.1.13
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
blocking1.8.1.13 +
wanted1.8.1.x +
blocking1.8.0.next +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate][needs trunk baking?] can lead to CSRF, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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
(Reporter)

Comment 1

10 years ago
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 "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.
(Reporter)

Comment 2

10 years ago
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.
Flags: blocking1.8.1.13?
Whiteboard: [sg:low spoof]
(Reporter)

Comment 3

10 years ago
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.
Component: General → General
Product: Firefox → Core
QA Contact: general → general

Updated

10 years ago
Whiteboard: [sg:low spoof] → [sg:moderate] can lead to CSRF
(Assignee)

Comment 4

10 years ago
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.
Status: UNCONFIRMED → NEW
Component: General → Networking: HTTP
Ever confirmed: true
Flags: wanted1.8.1.x+
Flags: blocking1.9?
Flags: blocking1.8.1.13?
Flags: blocking1.8.1.13+

Updated

10 years ago
Group: security
Same as/similar to: http://www.0x000000.com/?i=509 ?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
(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.
(Reporter)

Comment 7

10 years ago
(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.)
(Assignee)

Comment 9

10 years ago
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
(Assignee)

Updated

10 years ago
Blocks: 415496
(Assignee)

Comment 10

10 years ago
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 (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.
Assignee: nobody → dveditz
Status: NEW → ASSIGNED
Attachment #301201 - Flags: superreview?(benjamin)
Attachment #301201 - Flags: review?(cbiesinger)
(Assignee)

Updated

10 years ago
Blocks: 415500
(Assignee)

Updated

10 years ago
Target Milestone: --- → mozilla1.9beta4
(Assignee)

Comment 11

10 years ago
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 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.
(Assignee)

Updated

10 years ago
Attachment #301233 - Attachment description: "friendlier" fix → "friendlier" fix (but phish-friendly too)
Attachment #301201 - Flags: review?(cbiesinger) → review+
Attachment #301201 - Flags: superreview?(benjamin) → superreview+
Whiteboard: [sg:moderate] can lead to CSRF → [sg:moderate][needs trunk baking?] can lead to CSRF
(Assignee)

Updated

10 years ago
Attachment #301233 - Attachment is obsolete: true
(Assignee)

Comment 12

10 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Attachment #301201 - Flags: approval1.8.1.13?
(Assignee)

Comment 13

10 years ago
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
Attachment #301201 - Flags: approval1.8.1.13? → approval1.8.1.13+
Depends on: 419116
Flags: in-testsuite?
(Assignee)

Comment 14

9 years ago
Checked into 1.8 branch
Keywords: fixed1.8.1.13
(Assignee)

Comment 15

9 years ago
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.
Keywords: fixed1.8.1.13 → verified1.8.1.13

Updated

9 years ago
Flags: blocking1.8.0.15+

Comment 17

9 years ago
Comment on attachment 301201 [details] [diff] [review]
return errors for userinfo without a username

taking this for 1.8.0 distro patches.
Attachment #301201 - Flags: approval1.8.0.15?

Comment 18

9 years ago
1.8.0 branch should receive regression fix in bug 419116 as well.
You need to log in before you can comment on or make changes to this bug.