[pLog-svn] r7015 - plog/branches/lifetype-1.2/js/ui

[Reto Hugi]

Hi Mark

Thanks for your nice idea and sorry for my (again) superficial response
due to heavy time constraints ;) - I sometimes wish days would have 36
hours...

Anyway - the Blacklisting part ist IMO the most important one to
effectively secure the whole thing.

Oh, and first I thought the JavaScript Implementation wouldn't be a good
idea, but thinking of listening on click events, checking if it's a
relevant link and adding the nonce just before the request would even
omit the whole HTML parsing, right?

bye,
reto

On 08/02/2010 01:27 PM, Mark Wu wrote:
> Hi Jon & Reto:
> 
> Great job, It looks nice.
> 
> For all actions exist in system include plugin actions, I think a new
> method "getActionMap" could be add to Controller class, it could help
> CSRF plugin to get all actions through AdminController::getActionMap()
> easier:
> 
> Class Controller {
> ...
>     function getActionMap()
>     {
>           global $_plogController_actionMap;
>           return( array_keys(||$_plogController_actionMap) );
>     }
> ...
> }
> 
> Since Lifetype's action map is a global array, of course this method
> could be add to CsrfUrls DAO only.
> 
> Another problem is how to identify the admin action should be protected
> or not, .... Jon's current method is white list, it records all the
> actions need to protect by CSRF. Maybe, you can change it to black list,
> just record those ops that CSRF plugin don't want to protect by default.
> 
> So, the CsrfUrls dao could change to:
> 
> Class CsrfUrls {
> ...
>     $unprotected = array( 'adc', 'def' );
>     function getProtectedOps($op="") {
>         $protected = array_diff( AdminController::getActionMap(),
> $unprotected );
>         .....
>     }
> ...
> }
> 
> For further advanced CSRF protection control, maye a global variable
> $_plog_unprotected_actions can be added to CsrfUrls, so it can easier
> for CSRF plugin to provide a new method like
> CsrfUrls::registerUnprotectedAction( 'ghi' ) for plugin developers.
> 
> Then, plugin developers can decide the action should be protected or not.
> 
> It just my two cents.
> 
> Mark
> 
> 2010/8/2 Jon Daley <plogworld at jon.limedaley.com
> <mailto:plogworld at jon.limedaley.com>>
> 
>     On Mon, 2 Aug 2010, Reto Hugi wrote:
> 
>         I was thinking about those Blog communities that Mark was working on
>         some time ago, with lot's of content "creators". But fair
>         enough, it's
>         only the admin side.
> 
>            Yes, I occasionally hear about large communities, but I just
>     haven't worked on any of their code.
> 
>                 Please have a look at the /class/data/nonce.class.php
>                 (not the
>                 randomizer - yours is better)
> 
>         Well, acutally I thought that the nonce creation class would
>         have been
> 
>         nicer, than just creating the token inside the plugin code -
>         that was my
>         point :)
> 
>            True, that is good.
> 
> 
>         The "insecure" part on the implementation is the $protected
>         array, which may miss newly added actions and the fact that the
>         token is fixed for a session.
> 
>            Yeah, I'm not sure how to fix the newly-added actions part.
>      If you have any ideas about that, that'd be good.  I don't want to
>     fix the second.
>            I was thinking about it tonight, and wondering what it would
>     be like to add the nonce on the javascript/client side, so then the
>     template parsing would not be server-side, and so the load would be
>     lower, and it would also fix the plugin issue, at least partly - in
>     that the links could have the nonce added.  The values would still
>     need to be validated on the other side.
> 
> 
>         my aproach involved much more work but it treats csrf protection
>         just as we treat any other validation, so it's more kind of a
>         "native" aproach.
> 
>            True, and if we could get it in the adminaction base class,
>     then it'd be great.
> 
> 
>         True. Although the problem is, that I'm not running the latest
>         svn code
>         - heck, I'm still on 1.2.8!
> 
>            Hmmm...  Though I'd still venture to guess that you could
>     just replace the adminloginaction and add the plugin and be good to
>     go.  If you don't care about dynamically adding categories on the
>     newpost page, you can ignore those changes.
> 
> 
>     -- 
>     Jon Daley
>     http://jon.limedaley.com
>     ~~
>     No matter where you go,
>     there you are.
>     -- Buckaroo Bonzai
> 
>     _______________________________________________
>     pLog-svn mailing list
>     pLog-svn at devel.lifetype.net <mailto:pLog-svn at devel.lifetype.net>
>     http://limedaley.com/mailman/listinfo/plog-svn
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn