[Seaside-dev] Seaside and CSRF attacks

[Philippe Marschall]

On Wed, Aug 22, 2018 at 8:49 PM Jerry Kott <jkott at image-ware.com> wrote:
>
> Tim,
>
> I have just started looking at Seaside more closely with a specific focus on security for my upcoming ESUG talk. I don’t think that a blanket statement regarding CSRF can be made about Seaside either way.
>
> However, some observations make me suspicious. Whether or not the following could be misused / misconfigured to introduce CSRF or any other vulnerability is not yet clear to me, but there is certainly some value in experimenting with it.
>
> 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.
>
> Now open Counter in one browser and check what breakpoints you’ll hit. Increase the counter a couple of times and check the breakpoints again. ‘Copy link address’ of the ‘++’ link and put it in another browser. Check the breakpoints.
>
> You’ll find that with #shallowCopy is sent every time a snaphsot is registered for the state. This results in a growing number of instances of WACounter in the image, each representing a different state of the application (in this case, the ‘count’).

No, you should not get new WACounter, you should get new state
snapshots. You should only get new counter instances on a new session.
The state snapshots do not represent the application state. They
represent the state of the component tree for the current session.

> If you do the ‘another browser’ step above, you’ll also find that there is a bifurcation of that state chain at that point, but all those state representations belong to the same session (i.e., the same value of the ‘_s’ query parameter.

Sure, this is intended.

> 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 don't follow you. What do you mean by "something more persistent
than an instance variable in memory"? How does this break the ‘copy
link address’ step. How does this represent a CSRF vulnerability?

> To sum it up and recap: like other frameworks, most vulnerabilities will occur because of how the developer designs the application, not necessarily because of the framework’s inherent properties.

If so then I don't see we can't claim the framework is safe.

Imagine somebody uses Seaside to build an application that uses a
database access layer that is vulnerable to SQL injection. That is
entirely because how the developer designed the application since
Seaside does not perform database access. I don't see how this should
prevent us from claiming that Seaside is safe from SQL injection.

Cheers
Philippe