[Seaside] Security
Randal L. Schwartz
merlyn at stonehenge.com
Sun May 3 17:59:27 UTC 2009
>>>>> "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.
Of course, if the Smalltalk VM has a buffer overflow problem, all bets are
off. :) But no known bugs at this time on those.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
More information about the seaside
mailing list