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

Duncan_Napier1 · October 21, 2013, 10:30pm

Hi,

I have an RT 4.0.8 server that uses External Authentication (CAS) and has multiple aliases. I run mailgate, but as a policy, all ticket creation/submissions by regular (unprivileged) users are done through the /SelfServe webpage. Someone has requested that I allow the use of “ticket templates” for certain types of ticket submissions, eg via a website or email hyperlink. For example, the link

http://server-alias1.example.com/Create.html?Queue=12&Subject=Computer Setup Request&Content=%0APrimary User%3A %0AIs this a Computer? (Mac or PC)%3A

creates a ticket template with the subject “Computer Setup Request” already filled in and with a short questionnaire in the body filled in, eg “Primary User”, “Is this a Computer? (Mac or PC):”, etc.

The default RT configuration gives a cross-site request forgery restriction warning. I understand that the RT config variables ReferrerWhitelist, RestrictLoginReferrer, RestrictReferrer handle cross-site request forgery restrictions.

However, I am confused and frustrated by the limitations/restrictions of each of the “Referrer” parameters as I would like to not have the forgery warning appear for our users (who are already signed in through CAS). For example, on my system,

if RestrictReferrer is false (ie Set($RestrictReferrer, ‘0’) - the link above works (ie no cross-site request forgery warning) for Priviliged users only, but will not work (cross-site request forgery message appears for users) for unprivileged users all of ours who have login access via SelfServe. It send unpriviliged users to SelfServe instead.

ReferrerWhitelist [(Set(@ReferrerWhitelist, qw(*.example.com:443 *.example.com:80));] and Set RestrictLoginReferrer=0 do not seem to work at all and all users, priviliged and unpriviliged and all users get the cross-site request forgery message.

                             Regards,

                             Duncan.

Duncan Napier
duncan_napier@sfu.ca
http://www.sfu.ca/~dgnapier/
IT & Instrumentation Consultant
Dept of Molecular Biology and Biochemistry
Simon Fraser University

“It takes ten years to become good at being a kid. Then another ten years
to become good at not being a kid” - Larry Wall.

Kevin_Falcone · October 22, 2013, 5:08pm

However, I am confused and frustrated by the limitations/restrictions
of each of the “Referrer” parameters as I would like to not have the
forgery warning appear for our users (who are already signed in
through CAS). For example, on my system,

if RestrictReferrer is false (ie Set($RestrictReferrer, ‘0’) - the
link above works (ie no cross-site request forgery warning) for
Priviliged users only, but will not work (cross-site request forgery
message appears for users) for unprivileged users all of ours who have
login access via SelfServe. It send unpriviliged users to SelfServe
instead.

So that we’re clear, RestrictReferrer set to 0 disables any and all
Referrer header checking, so what you’re now seeing is merely RT’s
behavior, which is that when an Unprivileged user attempts to access a
URL that is outside the SelfService namespace, they are redirected to
SelfService.

While there is magic to handle a redirect from /Ticket/Display.html to
/SelfService/Display.html, there is no similar magic for ticket
creation. You’d want to overlay or patch the ShowRequestedPage method
in RT::Interface::Web and probably send along a patch. You might be
able to frob the requested component from a mason callback, but that’s
getting hairy.

Again, this has nothing to do with Referrer checking, since you’ve
turned it off.

ReferrerWhitelist [(Set(@ReferrerWhitelist, qw(*.example.com:443
*.example.com:80));] and Set RestrictLoginReferrer=0 do not seem to
work at all and all users, priviliged and unpriviliged and all users
get the cross-site request forgery message.

RestrictLoginReferrer only has to do with logging in, I’m not sure
what turning it off does for you.

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

Duncan_Napier1 · October 27, 2013, 6:31am

[Sorry … a repost. I sent this one with a generic Subject: rather than the problem-specific one)

Date: Tue, 22 Oct 2013 13:08:05 -0400
From: Kevin Falcone falcone@bestpractical.com
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Restrictions and limitations on use of
ReferrerWhitelist, RestrictReferrer, RestrictReferrer (cross-site
request forgery warning message)
Message-ID: 20131022170805.GY37001@jibsheet.com
Content-Type: text/plain; charset=“us-ascii”

ReferrerWhitelist [(Set(@ReferrerWhitelist, qw(*.example.com:443
*.example.com:80));] and Set RestrictLoginReferrer=0 do not seem to
work at all and all users, priviliged and unpriviliged and all
users
get the cross-site request forgery message.

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.

                             Regards,

                             Duncan.

Duncan Napier
duncan_napier@sfu.ca
http://www.sfu.ca/~dgnapier/
IT & Instrumentation Consultant
Dept of Molecular Biology and Biochemistry
Simon Fraser University

“It takes ten years to become good at being a kid. Then another ten years
to become good at not being a kid” - Larry Wall.

Kevin_Falcone · October 28, 2013, 4:20pm

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

Duncan_Napier1 · October 29, 2013, 8:43pm

Hi … .

Date: Mon, 28 Oct 2013 12:20:42 -0400
From: Kevin Falcone falcone@bestpractical.com
To: rt-users@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@jibsheet.com
Content-Type: text/plain; charset=“us-ascii”

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 ."

Clicking on the link 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.