<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:1241372793.19465.37.camel@corn.betterworld.us"
 type="cite">
  <pre wrap=""><!---->
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

  </pre>
</blockquote>
<br>
<br>
Your biggest issue (IMO) is going to be the possibility of session
hijacking.&nbsp; And, that is easily solvable, but not without placing some
level of limits on your audience.&nbsp; 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.<br>
<br>
Let me put it another way:&nbsp; the more "secure" your app is, the more
limiting you make your potential audience.&nbsp; Thus, it is up to you to
find the right balance.&nbsp; 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.&nbsp; Thus, for such an ecommerce site, you might
make cookies optional, but for a banking app, they might be mandatory.&nbsp;
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.<br>
<br>
For your app, I'd consider making your entire site use SSL, and I'd
consider requiring cookies.&nbsp; 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.<br>
<br>
Other folks may have other ideas, though.<br>
<br>
Nevin<br>
<br>
<br>
</body>
</html>