[rt-users] Creating Search Results Bookmark w/o CSRF Warning

[Alex Vandiver]

On Thu, 2012-05-24 at 14:51 -0700, Chris Hiestand wrote:
> Firstly, I think that in general, you do not need to worry much about
> CSRF if the request method is GET. I do not know the internals of RT,
> but shouldn't all harmful operations be POSTs? If that were the case,
> I'd say you don't need to launch a CSRF warning if you follow such a
> search result URL.

Unfortunately, there are two difficulties with that statement.  The
first is the assumption that you cannot forge POST requests; that only
GET requests can be attack vectors for CSRF.  This is unfortunately
false -- there are a myriad of ways (primarily using javascript) to
convince browsers to forge POST requests.

Secondly, RT has historically not differentiated between GET parameters
and POST parameters; it is quite possible to alter a ticket's status by
appending a "&Status=resolved" to the appropriate URL.  Changing that is
not an option in the middle of a stable series, as there are extensions
that rely on it.  As such, we must continue to protect against all GET
requests.

> Secondly, is there any way to disable such a warning without disabling
> all CSRF protections?

You have two options.  First, if you wish to simply blanket-disable CSRF
protections for particular Mason components, you can add to the 
%RT::Interface::Web::is_whitelisted_component hash.  While the search
result pages are not _quite_ idempotent, as they can be used for denial
of service attacks and do alter the user's session, they are of high
utility, and are candidates for whitelisting in a future release of RT.
They can most probably be added to the is_whitelisted_component hash
with little security implication.

Alternately, though I do not believe it necessary in this case, you can
locally override the RT::Interface::Web::IsCompCSRFWhitelisted function
to include additional logic, if you have more complex restrictions that
you need to apply.
 - Alex