[pLog-svn] Anti CSRF solution

[Mark Wu]

Hi Matt:

It is okay. You don't need to apologize :P

I think it can be a good reference for us that a general solution for CSRF
is possible. 

But, is it okay for LT? I don't think so...

We maybe need rewrite some or all of them to adapt our session based admin
panel...

I think actions, forms, forms validator modifcations are needed.

Mark

> -----Original Message-----
> From: plog-svn-bounces at devel.lifetype.net 
> [mailto:plog-svn-bounces at devel.lifetype.net] On Behalf Of Matt Wood
> Sent: Monday, November 26, 2007 6:22 AM
> To: LifeType Developer List
> Subject: Re: [pLog-svn] Anti CSRF solution
> 
> On Nov 25, 2007 4:26 PM, Ahmad Saleh <ahmadfds at gmail.com> wrote:
> > Hi Matt
> >
> > I just have some questions and some notes about what you say here.
> >
> > > 2. Does not protect against CSRF attacks from your site, 
> it infact 
> > > will release your "sensative" token to any actual CSRF attacks.
> >
> > What do you mean by "from your site"  ??
> >
> >
> > >
> > > 3. This will also likely confuse search engine crawlers.
> >
> > As Mark say, it just for admin pages, so there is no confusing for 
> > search engine.
> >
> 
> The aim of this script is to make certain pages (and their 
> metadata) inaccessible in subsequent requests, whether it be 
> from a link on your site or a link from any other site by 
> requiring a specific nonce to be present in the request to that page.
> 
> I didn't read the whole thread, so my apologies to Mark. If 
> this is just for the admin pages, then I also have to say 
> this would be an esoteric layer of security. However the 
> inclusion of a nonce into our admin actions might have a few 
> useful functional side effects.
> 
> Since LT has session based authentication, there are only two 
> real threats via CSRF to the admin section: one would be the 
> theft of the session id (via cookie or other means); the 
> other would be a user that is currently logged-into LT 
> clicking or visiting a page with a very targeted malicious 
> request (delete a post).
> 
> The first is infeasible without specific web application 
> vulnerabilities... since without malicious javascript 
> execution within the LT installations domain (or some browser 
> flaw), or in other words a full blown XSS vulnerability, the 
> theft of the session id (via
> cookie) is much harder.
> 
> The second highlights a security flaw that many web 
> applications currently have (trusting any HTTP requests "if" 
> a user is logged in).
> But it is also rather difficult to exploit unless the user is 
> foolish, or there are other vulnerabilities in the LT domain 
> and have a targeted attacker.
> 
> The second attack is what CSRFx attempts to solve. However, 
> since the nonces CSRFx uses are valid on any URL within 30 
> minutes the protection it provides is minimal. This type of 
> nonce protection should be tightly coupled with the action 
> with which it is associated (as per what Reto hinted at).
> 
> The functional benefits of an implementation like this would include:
> a way to limit actions to only being executed once (For 
> example, double posting or something similar), enforcing 
> request action execution order (think ajax), and probably more.
> 
> -Matt
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn