Don't use gensym for actions to avoid XSS attacks

[anonymous]

gensym-based action urls can be guessed and thus the following attack is possible:

A user has his weblock-based bank system open. In gmail, the user gets a link to a web-page that will generate lots of guessed action urls that transfers funds out of the users bank account.

Ways to fix:

1. Require session id in URLs
   
2. Or, generate stronger non-gensym based action ids

[Slava Akhmechet]

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.

[Slava Akhmechet]

On 8/1/07, Alexander Kjeldaas <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.

[Slava Akhmechet]

Please forgive the bad formatting. Numbers above don't mean tickets, but points from Alexander's email.

[Slava Akhmechet]

Fixed. I implemented approach 3 - action names should now be very hard to guess. I generate a random block of text, hash it with MD5 (to ensure an attacker can't crack the random number generator), and prepend it with a gensym counter (to avoid a very unlikely event of two MD5-encoding action names clashing in the same session).