[pLog-svn] Anti CSRF solution

[Matt Wood]

I read the bug description... isn't this more of a priviledge
escalation issue rather than CSRF? The other user really shouldn't be
allowed to delete the post/comment anyway. The "CSRF" protection may
not be enough to adequately stop this issue.

If the other user has access to the admin "view" page then, he can
obtain a correct nonce and just change the postId. Then you have the
same problem. Thus a need for more rigorous permissions.

I haven't looked at code, so I may be understanding this wrong.

-Matt

On Nov 25, 2007 11:36 PM, Mark Wu <markplace at gmail.com> wrote:
> 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
>
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>