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

[Kevin Falcone]

On Mon, Oct 21, 2013 at 03:30:08PM -0700, Duncan Napier wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 235 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20131022/d1971388/attachment.sig>