> On 11/17/2003 06:32 AM Andrew Mottaz wrote:
>>> http://nagoya.apache.org/bugzilla.  However, there aren't very many
>>> developers who like the idea of allowing you to hang yourself :).
>>> 
>> Thanks much for the tip -- I have to disagree about this not being a
>> necessary change.  There are plenty of apps where people browse without
>>  a secure connection, but have to log in to perform some functions.
>> Users like to bookmark pages -- why should I force them to bookmark only
>> non-secure pages? Giving a developer control over how session cookies
>> function is better than forcing a hack where you have to always redirect
>> to a non-secure page to establish the session.  If you are writing an
>> application where the session data is so sensitive that you have to
>> protect against session hijacking, you should know about the difference
>> between secure and non-secure cookies.  I've got no problem if the
>> default behavior uses secure cookies when ever possible, but change the
>> "Session uses cookie" parameter to have a flag that allows session
>> cookies to always be non-secure.
> 
> Andrew,
> what reason is there for preventing users from bookmarking secure pages?
> I don't follow you there.
> 
> Also, as far as I can see, the java community has decided that once you
> start a secure session, you should stay in a secure session, for various
> security reasons. Are you doing a secure login and then redirecting back
> to http afterwards?
> 
> Adam


Hi Adam,

If a user bookmarks a secure page, and then tries to browse a non-secure
page, the session is lost.

The decision to keep a session secure iff the FIRST access is secure does
not make sense to me.

Imagine the following scenario -- A web site has different levels of user
access.  The difference between the users is what products they can see.
The data is not terribly sensitive.  However, the log-in should be secure
for several reasons -- 1) For the users perception -- people do not like the
"This form is not secure" message when logging in.  2)  Capturing a user id
and password is worse than hijacking one session.

Now -- I have a web site with hundreds of pages of product data, and
thousands of users.  Many of these users bookmark the page
https://www.example.com/jsp/login.jsp

So -- if I want to allow users to bookmark this page, they will create a
secure session.  When they then browse the pages, I have two options:

1)  Keep all of the links secure

2) Redirect them to a non-secure page (To establish a non-secure session),
and then send them back to the secure log-in page.


Option 1 is unacceptable -- the overhead of having all of these connections
encrypted is not a viable option.

Option 2 is a hacky workaround -- cookies have a Secure=yes flag so that it
can be set and un-set as appropriate.


Also -- this is the standard for Tomcat -- not Java --( it may be in the
servlet/jsp spec -- but if so, it is a new addition).  Other Java based app
servers treat this differently.

Finally -- I know that ASP used to have the OPPOSITE implementation --
session cookies were always non-secure.  This is worse than Tomcat, but both
are wrong.  The developer needs to make the decision about what is
appropriate.



Again -- Just my 2 cents -- Is there a security issue I'm missing?  If the
argument is that you should NEVER go from secure to non-secure, the Tomcat
solution does not assure that. It only means that you have to go non-secure,
secure, and then non-secure.  That seems quite arbitrary to me.


Thanks,

Andrew


--
Andrew Mottaz
Site 9 :: Internet Business Solutions
116 W. Illinois, Ste 6E
Chicago, Illinois 60610
312.670.8469
www.site9.net 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to