[Radiant] [ANN] Radiant 0.6.5 Release Candidate 1

[Sean Cribbs]

Aitor,

Ok, I get it now.  However, this seems like something best left for 
0.6.6 (which should be a shorter turnaround to release).  We will be 
normalizing all of the admin controllers to be RESTful, and need to 
address the correct verbs anyway.  Also, be aware that simply loading 
"/admin/pages/remove/1" will give you a confirmation page.  We don't 
currently have any actions that do something destructively via GET.

Sean

Aitor Garcia Rey wrote:
> 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.
>
>