[Seaside-dev] Seaside and CSRF attacks

[Jerry Kott]

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’). 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.

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.

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. Of course, there may be situations where a framework simply IS badly designed but I am not aware of any vulnerability (yet) that would be because of Seaside design.

I am curious what you will find in your own investigation.

Jerry Kott
This message has been digitally signed.
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



> On 22-08-2018, at 10:36 AM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2018-08-22, at 4:07 AM, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>> 
>> 
>> Setting breakpoints in
>> 
>> WACallbackRegistry >> #store:
>> 
>> WASession >> #actionUrlForContinuation:
>> 
>> WACallbackProcessingActionContinuation >> #basicPerformAction
>> 
>> should get you started.
> 
> Excellent - thank you for that.
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "Bother," said Pooh, reading his bank statement from Barings.
> 
> 
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20180822/8e7109ce/attachment.sig>