[Seaside-dev] Seaside and CSRF attacks

[Philippe Marschall]

On Tue, Aug 21, 2018 at 9:44 PM Max Leske <maxleske at gmail.com> wrote:
>
> Hi Tim,
>
> CSRF usually requires a URL that can trigger an action. In Seaside, if
> you use continuations, the URL will contain a continuation key that
> specifies the state of the session (the session will usually be
> identified by a cookie). Every callback (action) has a key.
> Since the continuation key is a random string bound to the session
> (multiple session could use the same continuation key without problems)
> an attacker would have to guess the continuation key in order to perform
> a CSRF. In addition callbacks are usually state dependent, i.e. specific
> to a page and the state to that page, so it's usually not possible to
> trigger a callback outside of this context.
>
> Of course, you can use Seaside in a way that totally makes CSRF trivial
> ;)
>
> As for classes, that depends on the version of Seaside you want to use.

+1 the continuation key acts as a CSRF token.
The same action always gets a different id and that id is bound to the session.

There is a dirty little secret that on Squeak/Pharo (not sure about
VW) the RNG we use by default is not cryptographically safe (in theory
you can predict the next session and continuation ids).
Seaside-Security solves this on Unix (on Windows we have no good way
to seed). AFAIK this is a non-issue on GemStone/S.

We actually have some additional features not present in many other
frameworks like the allow both absolute and relative session timeouts
at the same time, something with OWASP recommends.

We actually do have documentation on security but it certainly can be expanded
https://github.com/SeasideSt/Seaside/wiki/Security-Features

Cheers
Philippe