[Radiant] [ANN] Radiant 0.6.5 Release Candidate 1

[Aitor Garcia Rey]

On Mon, Mar 3, 2008 at 6:20 PM, Sean Cribbs <seancribbs at gmail.com> wrote:
> Aitor,
>
>  We will need to investigate what it takes to use this.  It may have to
>  delay until the next release if it requires changing a lot of view
>  code.  Also, what are the risks of leaving it out?  I'm not aware of
>  what it specifically protects.

The CRSF attacks are based in the trust your applications give to the
authenticated users. Basically allows an attacker perform actions on
your site like an authenticated user. If the victim has logged in your
site and later navigate to a malicious page with the following
content:

<img src="http://radiant_installation/admin/page/remove/1">

his browser will send the request (and the needed cookie to
authenticate it) to radiant_installation, eventually deleting the home
of the radiant instance. For more info just check:
http://en.wikipedia.org/wiki/Cross-site_request_forgery.

The first step would be to use the correct HTTP verbs for each action,
delimiting the safe ones (think GETs). In this context and just like
an example SiteMap.getBranch() in sitemap.js is getting the childs of
a page with a POST request. Since this action is just returning info
without changing any state on the server a simple it'd better
acomplished with a GET request. Once the real POST/PUT/DELETE have
been determined we can focus on protect them.

To do this and with the CSRF protection enabled, rails form/view/ajax
helpers will emit a secret_token that is generated by a combination of
the user's session id and some pre-determined server secret. In the
words of Rick Olson, the creator of the original plugin later mixed in
the core:

"The idea is that a compromised page may be able to get your session
id, but would have no way of generating the correct token without
knowing the server secret."

As commented in the first mail radiant's forms are mostly handmaded
without helpers so we need to modify them to use the helpers o
manually put the authentication token for server validation. Finally
we could enable the protection on Admin::AbstractModelController with
something like:

class Admin::AbstractModelController < ActionController::Base
  protect_from_forgery
end


One more time I'd gladly help in these prosaic tasks XD.

-- 
Kind Regards,
Aitor Garcia
Cofounder - Linking Paths
http://www.linkingpaths.com