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

Reto Hugi reto at hugi.to
Sun Aug 1 18:01:32 EDT 2010


On 08/01/2010 02:30 PM, Jon Daley wrote:
>> At least it was one quick way to ad the protection through the plugin
>> event. But parsing the the rendered page is expensive and thus it's
>> probably not an option for high traffic sites.
>  	It is only on the admin side, 

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.

>> Please have a look at the /class/data/nonce.class.php (not the
>> randomizer - yours is better)
>  	Thanks.  I did look at your code when you first mentioned it, but 
> then after my reading of CSRF protection stuff, and all the various ways 
> people do CSRF protection incorrectly, made up my own randomizer.  One 
> thing that lots of security people don't take into account is that lots of 
> their methods only work on closed-source apps.  I thought about adding a 
> configuration option with a secret salt, but then we'd need a 
> configuration page.  I think in an upcoming version, I am going to add a 
> salt like WP does, where it is generated at install time, and then used in 
> various places to hash items.

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 :)

After all I think the quality of the nonce is not that important in any
csrf protection. It has to be reasonable random (the more, the better)
and your implementation works. 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.

>  One thing I didn't like about your code was that you modified each 
> action.  If the code could go in adminaction or something, then I'd be 
> happier.  I guess the adminaction could check my table of nonce-required 
> actions, and decide whether to validate or not there.

That's why the branche never developed into a working version :) too
many admin actions and templates... 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. On the other hand our
implementation of input validation has a long history of "hit and miss"
because we always validated each input field manualy (including security
validation).

>> Overall I think your approach makes a good trade off between effort and
>> protection. I'll definitely upgrade but probably not the next 2 months...
>  	Why not - it's easy to upgrade this.  You just need two files 
> (that you aren't likely to have modified), plus the plugin - should take 4 
> minutes to upgrade.  :)

True. Although the problem is, that I'm not running the latest svn code
- heck, I'm still on 1.2.8!

regards, reto


More information about the pLog-svn mailing list