[pLog-svn] Anti CSRF solution

[Jon Daley]

 	I thought the issue was that someone posts a comment on my blog 
and puts this URL as their web page:

http://jon.limedaley.com/plog/admin.php?op=blogSelect&blogId=1&action=deleteComment&commentId=9027&articleId=873

and convinces me to click on it.


On Mon, 26 Nov 2007, Matt Wood wrote:

> 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
>>
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>

-- 
Jon Daley
http://jon.limedaley.com/

There are two ways of constructing a software design.
One way is to make it so simple that there are
obviously no deficiencies.  And the other way is
to make it so complicated that there are
no obvious deficiencies
-- Professor C.A.R. Hoare