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
