[Seaside] Security

[Nevin Pratt]

>
> I think there is a part that relates to Seaside.  This an other replies
> have suggested the issue is the design of my application or web security
> in general; this may be because you all know that the stuff at the
> Seaside level is OK.  I don't, and would still like info at the level. I
> know those other levels matter too.  
>
> Let me be more explicit. A request comes in through the web.  Assuming
> an attacker can put anything they want in the request, there are two
> concerns.  
>
> First, the attacker could pretend to be someone else.  I need Seaside to
> identify accurately who the requestor is or to reject forged requests
> before they get to my code.  Previous discussion on the list indicates
> that, with suitable precautions, an outsider can not hijack an existing
> session.  Can someone with a legitimate session assume another identity?
> Can someone without a session assume an identity?
>
> Second, the request could attempt to execute some code that is outside
> the normal flow of operations.  I don't know if the latter is possible
> with Seaside; in other frameworks such as Zope it is possible (and it
> has security systems to keep this in check).  Or they could start
> traversing the object graph, even with the debugging interface off.
> Again, I'm not clear: are either of these scenarios (access to code or
> objects) possible.  Are they?
>
> The possible application involves health information, so the security
> requirements are quite strict.
>
> Ross
>
>   


Your biggest issue (IMO) is going to be the possibility of session 
hijacking.  And, that is easily solvable, but not without placing some 
level of limits on your audience.  For example, if you architect the app 
to require cookies to be turned on in the browser, then of course you 
limit yourself to only the audience that is willing to have cookies 
turned on in their browser.

Let me put it another way:  the more "secure" your app is, the more 
limiting you make your potential audience.  Thus, it is up to you to 
find the right balance.  For an ecommerce website that doesn't save 
credit card data at all, security might take a more secondary seat than, 
say, a banking app.  Thus, for such an ecommerce site, you might make 
cookies optional, but for a banking app, they might be mandatory.  
Likewise, for an ecommerce site, you might choose to only have the 
checkout process use SSL, and yet for a banking app (like PayPal, for 
example), you might choose to have the entire site use SSL.

For your app, I'd consider making your entire site use SSL, and I'd 
consider requiring cookies.  I'd also consider configuring Seaside for 
using cookies for the session key, plus use a secondary cookie for 
additional "branding" of your login/logout process.

Other folks may have other ideas, though.

Nevin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20090503/7c18963c/attachment.htm