[pLog-svn] Anti CSRF solution

[Mark Wu]

After research some posts discussed about php security

I think

1. The easiest way to save us to avoid the CSRF  attack is referal check.
although it is not friendly to those browser which can not send referal
urls.
(We can provide an option for admin, let him decide want to turn it on or
not)

2. For http-post based operation, like add and update, it is easier to
porvide the protection by add one-time token. Need to add one hidden input
to each form that we want to protect.

3. For http-get based operation, then that's a big problem. We need to
rewrite them to post-based with one-time token protection, maybe we need a
AdminUrlGenerator to take care of this easily.

Mark

> -----Original Message-----
> From: plog-svn-bounces at devel.lifetype.net 
> [mailto:plog-svn-bounces at devel.lifetype.net] On Behalf Of Reto Hugi
> Sent: Monday, November 26, 2007 6:45 AM
> To: LifeType Developer List
> Subject: Re: [pLog-svn] Anti CSRF solution
> 
> Hi Matt
> 
> Thank you for your - once again - very helpful support on 
> this list regarding security.
> 
> On 11/25/2007 11:21 PM, Matt Wood wrote:
> > 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.
> 
> In case of LT-based communities with features like "authenticated"
> comments on other blogs within the same site, it's "easier" 
> than on stand alone blogs, to modify or delete an other users 
> post with CRSF. In fact we had a report on bugs.lifetype.net 
> (http://bugs.lifetype.net/view.php?id=1410). That's why the 
> discussion started.
> 
> > 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.
> 
> Thanks for pointing this out. I haven't even realized that one.
> 
> > This type of nonce protection
> > should be tightly coupled with the action with which it is 
> associated 
> > (as per what Reto hinted at).
> 
> Yes, Mark and I agreed, that I'll implement a PoC on the 
> current trunk to test what we could do.
> 
> > 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.
> 
> I'd like to use nonces tightly bound to an action within the 
> context of the users last presented view. I know about the 
> ajax double-post validation, but I'm not very happy with that 
> idea from a technical design view and I haven't seen it 
> implemented in a real world app so far. (If you know one, let me know)
> 
> I'd be glad if you could review our PoC, once we're ready.
> 
> cheers, reto
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn