cl-weblocks-devel

Download

cl-weblocks-devel@common-lisp.net

August 2007

2 participants
1 discussions

[cl-weblocks-devel] Re: #45: Don't use gensym for actions to avoid XSS attacks
by Alexander Kjeldaas 01 Aug '07

01 Aug '07

One user accessing another user's stuff is not the attack I am describing. The attack I am describing is a purely destructive *someone making a user do stuff* attack. Get a user to do something that they didn't really intend to do. In order to do this, one only need to get the user to click on a link that has a guessed action in it. For example, if there's a "delete account" action on a weblocks page where the action id is guessable, *someone* can post a link somewhere that makes people delete their accounts. If the action id is unguessable, or the session id is part of the url, then this attack is not possible. A third option is to add a framework for confirmation of "important" actions. On 8/1/07, cl-weblocks <cl-weblocks-devel(a)common-lisp.net> wrote: > > #45: Don't use gensym for actions to avoid XSS attacks > > ------------------------+--------------------------------------------------- > Reporter: anonymous | Owner: sakhmechet > Type: defect | Status: new > Priority: low | Milestone: 0.2 > Component: weblocks | Version: pre-0.1 > Resolution: | Keywords: security > > ------------------------+--------------------------------------------------- > Changes (by sakhmechet): > > * milestone: => 0.2 > * priority: critical => low > * version: => pre-0.1 > > Comment: > > I don't think this is an issue. Weblocks stores actions per session > specifically so that a user cannot access another user's actions (unless > the session has been highjacked). If a malicious site generates a lot of > 'transfer' actions the user still won't be able to access them. > > It's probably better to use a scheme that makes action URLs harder to > guess anyway, but this isn't critical. Moving to 0.2. > > -- > Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/45> > cl-weblocks <http://common-lisp.net/project/cl-weblocks> > cl-weblocks

2 1