From alexander.kjeldaas at gmail.com Wed Aug 1 20:54:28 2007 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Wed, 1 Aug 2007 22:54:28 +0200 Subject: [cl-weblocks-devel] Re: #45: Don't use gensym for actions to avoid XSS attacks In-Reply-To: <091.7239142bd79e11c033aaf877a9012509@common-lisp.net> References: <082.33ef58ae61183f1b8efbd3093f4820ab@common-lisp.net> <091.7239142bd79e11c033aaf877a9012509@common-lisp.net> Message-ID: 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 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: > cl-weblocks > cl-weblocks -------------- next part -------------- An HTML attachment was scrubbed... URL: From coffeemug at gmail.com Wed Aug 1 21:45:08 2007 From: coffeemug at gmail.com (Vyacheslav Akhmechet) Date: Wed, 1 Aug 2007 17:45:08 -0400 Subject: [cl-weblocks-devel] Re: #45: Don't use gensym for actions to avoid XSS attacks In-Reply-To: References: <082.33ef58ae61183f1b8efbd3093f4820ab@common-lisp.net> <091.7239142bd79e11c033aaf877a9012509@common-lisp.net> Message-ID: On 8/1/07, Alexander Kjeldaas wrote: > > 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. I see. A multistep solution that comes to mind is this: 1. Split actions into destructive actions that modify back-end data, and 'pure' actions. 2. Ensure that destructive actions are only executed if the HTTP request is initiated via POST. I'll have to double check, but I think browsers don't allow forms to send POST requests to domains different from where HTML originally came from. 3. Programmers will sometimes make mistakes and create destructive actions as regular ones (we could prevent them from doing it in Haskell, but unfortunately not in Lisp). This means all actions, not just destructive ones must have URLs that are hard to guess. I'm not sure if I want to implement #1 (and therefore #2) because it forces a programmer to choose between two ways of creating an action. On the other hand this might be a good thing - this is something that needs to be thought out. #3 should definetly be implemented. I'll change the ticket accordingly. P.S. Could you use weblocks at googlegroups.com (or the UI interface) instead of cl-weblocks-devel?