[Seaside] Seaside done?

Sun Apr 12 04:48:02 UTC 2020

Thanks for everyone's feedback.

I am not going to get drawn into ‘compare Seaside vs. X’. Zoom is hardly a benchmark we should be using anyway. As for other web frameworks, there are so many different criteria and usage scenarios that any attempt for comparison would immediately raise objections from someone, and this thread could quickly devolve into a ‘what about …’ kind of discussion.

WAAdmin class >> register:asApplicationAt:user:password: uses WAAuthConfiguration and WAAuthenticationFilter so there IS a default authentication of components. However, I may have been wrong in stating that the algorithm used is MD5. I remember if from a couple of years ago, and in any way this appears to be GRPlatform specific, so not exactly a Seaside issue. My humble apologies. I know about the authentication issues because I’ve seen them, and I had to fix them. I can’t discuss details because I am bound by confidentiality and intellectual property agreements. So… don’t ask :)

When it comes to security concerns, again comparisons with other tools are pointless. What matters is ‘is X vulnerable, and if so, is it exploitable’. That ‘it can be fixed easily’ doesn’t matter. I am aware that Seaside escapes all output so (AFAIK) there is no XSS vulnerability. I’d be only too happy to see more action on Seaside because it IS a great framework, and I look forward to subject it to a bit more formal security tests if I get a change.

I don’t want to change the subject of this thread, so I am going to write about the security survey in another thread. Here I’ll just mention that I reported on it quite extensively at ESUG 2018. I mentioned both in my presentation and in the mailing lists the creation of a Smalltalk security google group, interest from the community has been minimal. I stopped paying the $30/month for Survey Monkey after about a year, but I do have the raw data somewhere. As I said - subject for another thread.

Keep up the good work - don’t take my reservations the wrong way. Seaside has its place, it’s just that it has been and will remain a niche.

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

> On 10-04-2020, at 7:45 AM, Johan Brichau <johan at inceptive.be> wrote:
> 
> Hi Jerry, all,
> 
>>> Seaside security is fairly poor. It doesn’t offer any protection against CSRF attacks or session hijacking.
>> 
>> It currently does not, but could be added pretty easily, about session
>> hijacking it depends on how you implement the session tracking.
> 
> Session protection strategies can be implemented easily in Seaside using filters.
> In the next release (3.4.0), we added an example WASessionCookieProtectionFilter, which implements a session tracking strategy that prevents CSRF attacks.
> This implementation uses the Seaside framework to implement an effective session hijacking protection, and can be used in any Seaside version as far back as 3.0
> 
> There were other session protection filters already included in Seaside before, but they had practical downsides.
> I will agree it would have been better that it was included sooner, but then again, Seaside does not include an authentication framework either.
> 
> When you say that Seaside security overall is very poor, can you compare this with other frameworks that focus on rendering web applications? Because ’security’ is way broader than what the framework allows you to do and Seaside does not even do a bad job at that point. For example, the rendering mechanism prevents explicitly from script injection attacks because all output is escaped by default, the default session keys are way better than Zoom’s meeting ids (lol ;). But if you see security-related bad practices that the Seaside framework itself promotes, please share them so we can improve.
> 
>>> The built-in basic authentication only supports MD5-hashed password which has not been considered secure since 2004. Using other authentication mechanisms is non-trivial and can lead to deploying catastrophically insecure application (don’t ask me how I know).
> 
> I don’t see how this can be true. Seaside has no built-in authentication mechanism. It depends on what you (can) use in the Smalltalk you are running it on.
> If you choose to store passwords in clear text, there is nothing that any website framework will do to keep you from doing that.
> If you are referring to existing authentication libraries implemented for Seaside, that may be true, but it’s by no means inherent to the framework.
> 
>>> Last but not least, handling of volume has been issue.
>>> I don’t have experience with a deployed Seaside app on Pharo,
>>> but I know that on VW you quickly reach a point where your app performance
>>> suffers even with a couple hundred users.
>> 
>> Here I kind of agree, even "a couple hundred" seems like a lot in my experience.
>> Of course it depends on the kind of application, but for a typical
>> backoffice kind of app, database bound, my threshold in Pharo was
>> always around ~20 users... per VM. My solution was to have several
>> worker VMs for this, and other worker VMs for REST APIs.
> 
> This discussion heavily depends on what your application is doing.
> In my experience, the performance bottleneck is mostly found outside of Seaside (i.e. in your application code or database). The biggest performance-related impact that Seaside adds is because of its continuation state, which consumes a lot of memory (and database transactions if you run Gemstone). I will not say that this definitely impacts your application, but similarly, it does add functionality that other frameworks are not offering.
> 
> All in all, if you write your application in C instead of Smalltalk, the same discussion would apply.
> 
> Now, that being said, the continuation state-tracking has become obsolete in the current world and it would be good if we can improve Seaside’s performance by making that optional. It actually is already possible in the framework, but there are caveats. Would be great if someone wants to explore that direction, btw.
> 
>>> With GS, you need a multitude of Gems to handle even relatively modest load.
>>> I think this would be probably the worst weakness - today’s web apps are built for tens of thousands of concurrent users,
>>> and even with the use of a load balancer, this would be a limiting factor for anyone
>>> considering the deployment of a globally reachable web app.
> 
> There is maybe a little gap between an ‘internal web app for 2 people’ and a ‘globally reachable web app’ :)
> 
> We’re running gemstone instances of Yesplan with 150 concurrent users easily and the bottleneck on the number of users is entirely related to the application and not Seaside (although the thing I said above does apply).
> Since we’re running multiple instances, we currently serve 10K concurrent users easily.
> 
> Maybe using NodeJs, you could run less instances, but there’s a limit to what any single-instance setup using any framework can do.
> 
>> The Seaside is not going nowhere, it's the tide that comes and goes :-)
> 
> I like that quote ;)
> 
> Cheers
> Johan
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200411/a70d2ba4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200411/a70d2ba4/attachment.sig>