It's been a looong time since I did any work with Seaside. In fact I suspect the last thing I did with it was to persuade Avi that separate template files etc weren't nice and I think that lead to seaside 2.

Right now I need to remember/relearn where the system deals with the keys that ensure the incoming requests talk to the right widgets. I have a problem with convincing some potential customers that a seaside application is resistant to a CSRF attack and I'm having a hell of a time digging into the current code. Pointers to to the relevant classes would save some strain on my aging eyes. If anyone has any specific knowledge about the whole CSRF thing I'd be delighted to hear about it! I've tried testing with some OWASP tools (nasty icky java) but it's hard trying to make sense of the problem.

(It doesn't help that this is within a VW8.3 system and I haven't used VW since I stopped being the manager of the VW development group - in '95! )

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Eagles may soar, but weasels aren't sucked into jet engines.


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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.

Cheers,
Max


On 21 Aug 2018, at 21:08, tim Rowledge wrote:
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Hi,

On 21/08/2018 16:44, Max Leske 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.

If you use plain HTTP (it is, non-HTTPS) and get a man in the middle it
would be simple to activate more than once the same continuation.
However a MITM is sophisticated even in the simplest case, so unless you
application/data is critical, it isn't a big concern either, but would
be an unnecesary risk since it's easy to use SSL these days.

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

On the component level that would be true, but the state of pages and
the state of the underlying model objects or data stored in a database
is unpredictable.

In its "heresy" an HTTP GET is not idempotent in Seaside, so requesting
it more that once and having that action doing harm depends more on how
the Seaside application was programmed, but in my experience (and way of
working with Seaside) you don't program "defending" against that.

In an AJAX world, I'd like callbacks to be valid only once.

> Of course, you can use Seaside in a way that totally makes CSRF trivial ;)

Summarizing I agree with what Max mentions, and basically Seaside
provides some sort of security through obfuscation regarding the
crafting of the CSRF, since the keys are random.


> As for classes, that depends on the version of Seaside you want to use.

I'm working with Seaside in VW, let me know if you need any further help
with that. Seaside in VW isn't as updated as in other platforms.

--
Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Thanks Max,

> On 21-08-2018, at 12:44 PM, Max Leske <[hidden email]> 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.

That's a good explanation of what I very vaguely remembered from deep history. It would be nice to add it to the seaside security page section on CSRF, rather than the current rather short entry.

>
> Of course, you can use Seaside in a way that totally makes CSRF trivial ;)

As the old aphorism goes, some people can write bad FORTRAN in any language...

>
> As for classes, that depends on the version of Seaside you want to use.

Its a 2013 package for VW; can't find any obvious version numbering. Whatever Cincom include with VW8.3.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Thinks everyone else is entitled to his opinion, like it or not.


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> On 21-08-2018, at 1:07 PM, Esteban A. Maringolo <[hidden email]> wrote:
>
> Hi,
>
> On 21/08/2018 16:44, Max Leske wrote:
>
[snip useful stuff]

> I'm working with Seaside in VW, let me know if you need any further help
> with that. Seaside in VW isn't as updated as in other platforms.

Thanks; what would be really useful to me (and I feel it would make a good explanatory page for the seaside.st site as well) would be pointers to the right basic class(es) and methods to provide a simple example of the sequence of events that we get.

With much hand-waving I guess we might be able to say something like -

A buttonwidgetclass has created html that shows a button on your page. clicking on the button sends a URL like this {pighrpghrgrud.eu/dsifjjrgirjr/wibble?soopasekritkey} to the server and it gets routed to thingummyclass by the dispatch code in whotzitclass>>blurgmethod.  The soopasekritkey included in the URL is checked against the key(s) for classA/classB/whatever which ensures that only requests made by pages generated by this server in this session during this phase of the moon (etc) are handled (what happens to other ones? Can we make things at the bad guys' end blow up? I wish).

A diagram would probably help a lot to make a useful page.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"!" The strange little noise you make when you can't scream...


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> On 21-08-2018, at 3:26 PM, Ron Teitelbaum <[hidden email]> wrote:
>
> Hey Tim,
>
> Did you see: http://www.seaside.st/about/security

I did indeed see that, and it makes sense to me at a certain level BUT I don't think a client's security team is likely to look at that simple assertion ad say "yup, ok, we believe that is enough". I'd be kinda concerned about the competence of the security team if they did...

A more expansive explanation would be nice. And would be nice documentation to explain quite a lot of how seaside works.

>
> CSRF is basically being able to execute a task from a different program impersonating a user that is already logged into a different site.
>
> The attacker knows the user is logged into some program.  They know how to get that program to do something bad.  They trick the users into executing some code that does something bad on the other program that is running.  Click here to get free $50 gift card! href=https://imloggedin.com?my really bad code goes here.  This works because my really bad code is going to be sent to the location the user is logged into which means it will have access to cookies and will think this is a valid request for a user that is logged in.  Validating the cookies is not sufficient to ensure the request came from your application.
>
> You can prevent this from happening if you have something on the current page in the browser that is unique, you then check that token to make sure the request is coming from your program and not from some other program running on your computer (my really bad code).  The server needs to validate the data is coming from the browser (Header, URL, Field) matches what was set by your application (for each page) before executing any tasks.  The attacker doesn't have access to that token so trying to execute some task should fail.

That's one of the least confusing explanations of CSRF attacks I've seen. Thanks!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Drugs may lead to nowhere, but at least it's the scenic route.


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 21 Aug 2018, at 22:14, tim Rowledge wrote:

Yes, we should probably add something. I'll open an issue on github so
we don't forget.
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Tue, Aug 21, 2018 at 9:44 PM Max Leske <[hidden email]> wrote:
+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
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Tue, Aug 21, 2018 at 11:30 PM tim Rowledge <[hidden email]> wrote:
The actions are stored in a WACallbackRegistry in a WARenderContext in
a WARenderLoopContinuation which are then processed in
WACallbackProcessingActionContinuation >> #basicPerformAction which is
called by WASession >> #handleFiltered:

Setting breakpoints in

WACallbackRegistry >> #store:

WASession >> #actionUrlForContinuation:

WACallbackProcessingActionContinuation >> #basicPerformAction

should get you started.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Excellent - thank you for that.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother," said Pooh, reading his bank statement from Barings.


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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



_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> On 2018-08-22, at 11:49 AM, Jerry Kott <[hidden email]> wrote:
>
> 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.

Interesting thoughts; I'm going to hope someone with much more current knowledge will join in.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Kept an open mind -- and his brains fell out.


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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 <[hidden email]> 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

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Wed, Aug 22, 2018 at 8:49 PM Jerry Kott <[hidden email]> wrote:
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
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev