> 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]
