[Seaside] Security

Philippe Marschall philippe.marschall at gmail.com
Sun May 3 21:32:23 UTC 2009


2009/5/3 Randal L. Schwartz <merlyn at stonehenge.com>:
>>>>>> "Ross" == Ross Boylan <RossBoylan at stanfordalumni.org> writes:
>
> Ross> First, the attacker could pretend to be someone else.  I need Seaside to
> Ross> identify accurately who the requestor is or to reject forged requests
> Ross> before they get to my code.  Previous discussion on the list indicates
> Ross> that, with suitable precautions, an outsider can not hijack an existing
> Ross> session.  Can someone with a legitimate session assume another identity?
> Ross> Can someone without a session assume an identity?
>
> Seaside doesn't know "identity".  That's all in your app code.  All seaside is
> going to do with the incoming values is reawaken your session-saved state,
> including the state of all components.  If one of those values is your
> app-defined "identity", that's up to you to manage properly.
>
> Ross> Second, the request could attempt to execute some code that is outside
> Ross> the normal flow of operations.  I don't know if the latter is possible
> Ross> with Seaside; in other frameworks such as Zope it is possible (and it
> Ross> has security systems to keep this in check).  Or they could start
> Ross> traversing the object graph, even with the debugging interface off.
> Ross> Again, I'm not clear: are either of these scenarios (access to code or
> Ross> objects) possible.  Are they?
>
> Not possible, unless you happen to be silly enough to "eval" incoming
> arbitrary strings as Smalltalk code.

You might think so. But then try to convert a String to a Boolean and
follow the path of execution. You might be in for a surprise. There is
no telling how many time bombs like this are in Squeak.

Cheers
Philippe


More information about the seaside mailing list