[rt-users] Restrictions and limitations on use of ReferrerWhitelist, RestrictReferrer, RestrictReferrer (cross-site request forgery warning message)

[Duncan Napier]

Hi .. . 

> Date: Mon, 28 Oct 2013 12:20:42 -0400
> From: Kevin Falcone <falcone at bestpractical.com>
> To: rt-users at lists.bestpractical.com
> Subject: Re: [rt-users] Restrictions and limitations on use of
> 	ReferrerWhitelist, RestrictReferrer, RestrictReferrer (cross-site
> 	request forgery warning message)
> Message-ID: <20131028162042.GA1829 at jibsheet.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> On Sat, Oct 26, 2013 at 11:31:29PM -0700, Duncan Napier wrote:
> > > As for @ReferrerWhitelist, you'd have to show an actual error
> > > message
> > > to compare with the domains that you're whitelisting in order to
> > > know
> > > what's wrong.  This is the preferred solution (white list the
> > > source
> > > of your ticket form submissions).
> > > 
> > > -kevin
> > 
> > OK ... thanks for clarification. I think my problem with the
> > Whitelist is that I have whitespace in my $Organization name. The
> > Apache error log shows
> > 
> > [Fri Oct 25 20:03:48 2013] [error]: your $Organization setting
> > (Another Company) appears to contain whitespace.  Please fix this.
> > (/usr/local/rt/sbin/../lib/RT/Config.pm:505)
> > [Fri Oct 25 20:03:48 2013] [notice]: Possible CSRF: your browser
> > did not supply a Referrer header
> > (/usr/local/rt/sbin/../lib/RT/Interface/Web.pm:1458)
> > 
> > Does Whitelist use $Organization as a reference/lookup? When I set
> > RT
> > up, using my domain didn't make much sense because MY domain is
> > different from the organizational unit that I am supporting, so I
> > put
> > in the ACTUAL NAME of the the other organizational unit I support.
> > I
> > realize now that spaces in $Organization are not allowed in RT, but
> > I
> > have not had any problems up to now. I am prepared to change it if
> > necessary and I have seen instructions on this list to do an
> > $Organization search-and-replace in MySQL to preserve links.
> 
> While this is an error, and will cause you problems in Linking and if
> you ever use Articles, it is unrelated to your CSRF problem.
> 
> I actually meant the error message printed in the browser for the end
> user.  Normally when linking from an external form, it will say
> 'invalid referred' for the host of the external form.  However, if
> you're getting no Referrer, why is that?
> 
> -kevin

The error in the browser is 

"RT has detected a possible cross-site request forgery for this request, because your browser did not supply a Referrer header. A malicious attacker may be trying to create a ticket on your behalf. If you did not initiate this request, then you should alert your security team.

If you really intended to visit /Ticket/Create.html and create a ticket, then click <here to resume your request>."

Clicking on the link <here to resume your request> sends the user to the ticket creation page. 

I have done some research and apparently referrer headers are turned on and off in the browser. There are options to enable/diable referer headers in various browsers, but that doesn't make much sense from an organizational standpoint to ask hundreds of users to configure their browser settings. So I have no idea how whitelisting gets around this issue. 

Anyway, I have figured out how to do what I need (namely to allow non-privileged users to create a SelfService ticket) with 

Set($RestrictReferrer, '0')

and simply changing the direct link I was using

http://server-alias1.example.com/Ticket/Create.html?Queue=12&Subject=Computer%20Setup%20Request... 

to

http://support1.mbb.sfu.ca/SelfService/Create.html?Queue=12&Subject=Computer%20Setup%20Request... 

Thanks for all you help!

                                          Duncan.