My normal method of creating a search result bookmark is to create the search and then copy the URL for the “Show Results” menu item. This gives me a URL with search parameters I can bookmark in my browser (I’m not discussing internal RT bookmarks here).
Under the latest RT with CSRF protections (3.8.12 in my case), a CSRF warning comes up when I follow a search results bookmark.
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.
Secondly, is there any way to disable such a warning without disabling all CSRF protections?
Thanks,
Chris
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.
Thanks for the great reply!On May 24, 2012, at 7:32 PM, Alex Vandiver wrote:
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.
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.
Ah, that was my mistake. Are “write” GET parameters removed in RT 4?