[Seaside-dev] Seaside and CSRF attacks

[Johan Brichau]

Hi,

This discussion would have been great on the Seaside users list instead of the developers list.
I’m keeping it here for now, but it’s a nice discussion of value for all Seaside users.

> On 22 Aug 2018, at 20:49, Jerry Kott <jkott at image-ware.com> wrote:
> 
> I don’t think that a blanket statement regarding CSRF can be made about Seaside either way.

I think that’s true for any framework, as you mention.

Seaside does help the developer a little to prevent CSRF attacks: all output is encoded per standard. If you store user input and render that directly on your page, you do not have to care if a user would enter malicious scripts to make a CSRF attack. Per default, standard Seaside rendering will encode the output to html text. There is one place in Seaside where this is not done: rendering of title attributes (ssshhhht!! :-). Still want to fix this… but it’s rather annoying in the current code as far as I remember.

> Try this: Run the Counter example as one of the simplest state changing ‘apps’. Put a breakpoint (or halt) in WACounter>>#initialize, and maybe in WACounter>>#increase. It might also be informative to add #shallowCopy method wiht a ‘^ super shallowCopy’ in it, and put a breakpoint there as well. These things helped me to better understand the default Seaside state management.
> 
> . ‘Copy link address’ of the ‘++’ link and put it in another browser. Check the breakpoints.

My understanding is that you executed a replay attack here. This is something Seaside developers should indeed be concerned about but there’s ways to deal with it.

When you use the default Seaside way of showing the session key in the url, then anybody who gets their hands on the url has the possibility to execute a replay attack as long as that session is alive. If you want to prevent that, a first step is just use SSL (TLS). That already excludes a lot of man-in-the-middle attacks who could execute a replay attack.

Next, it depends what you want to do. In Seaside, you can also include the option to store the session key in a cookie. This means that a copy/paste of the url to another browser will no longer work: a person looking over your shoulder will not be able to execute a replay attack. However, it also means that a single browser can only have a single application session, which is often undesirable.

A better solution is to decouple application authentication from session tracking. If you use authentication to access an application, instead of relying on Seaside (and it’s session keys) to authorize a request, add an authorization cookie to the browser and keep using the session keys in the url. This allows a single user to have multiple sessions running in a single browser but copy/paste of urls for replay attacks will not work. We implemented this strategy to secure our Seaside app.

> Now… if the state is representing by something more persistent than an instance variable in memory (e.g., a class instance variable or something in the file system), this will break, and doing the ‘copy link address’ step, you’ll be able to change state in one browser that is based on the last known state in another browser. I believe this would be a classic CSRF vulnerability but more analysis is needed.

I think if you put Seaside application state in anything else than instance variables of your components, you will be in trouble with more than your security. Seaside’s continuation mgmt to support back/forward will change that “global” state and I can imagine several things going wrong with that. I never tried though :)

Looking forward to your talk! Will be great to chat about this!

Cheers 
Johan