Your first issue is less of a concern since if you are kicking the user, just invalidate() the session and who cares if they get the session id.
Your second issue is a little more important, INMHO, yes, the first screen after the session is established shows the jsessionid NMW in the address. I have wondered about it but so far have no answers (except to forward to a bogus jsp with a javascript timeout, which submits to the next page so the jsessionid is on the visible for the smalles amount of time). Edgar -----Original Message----- From: Tom Wadzinski [mailto:twadzins@;yahoo.com] Sent: Friday, November 15, 2002 10:55 AM To: 'Struts Users Mailing List' Subject: RE: Disabling jsessionid parameter in Struts forms > This is so easy to implement yourself it barely even bears discussing. > Create an abstract Action super-class, check to see if cookies are > enabled, and if they aren't, block access and give the user an error > message to that effect. You could have written it in the time you > composed this email. What you describe doesn't answer my question. It only solves half of the problem. Struts still calls encodeURL (or encodeRedirectURL) which will put the session id in the URL on at least the first call of the session, because it is not yet known if the user has cookies enabled or not. So, looking at the referer exploit, any 3rd party banner ad providers on the first page of a struts-enbabled site will be given the jsessionid, even if the site designers used the solution you describe. Also, I could swear that I'm seeing the jsessionid crop up on the URL on pages after the first page even with cookies enabled in the client. I suppose this is the fault of my app server, which is implementing HttpServletResponse.encodeURL. Perhaps others are seeing this as well. ... > From Craig: > Session ids in cookies are no more secure than session ids in URLs -- they > are just as susceptible to snooping even though they are not physically > visible. If attacks via session id are an important issue for you, you > should be using SSL instead. Using SSL to avoid session id attacks is not sufficient. The two scenarios I described are unique to jsessionid on the URL, and are exploitable using SSL or not. They can't happen if the jsessionid never shows up on the URL. So, the snooping scenario you describe is a separate matter. Sure, if a malicious 3rd party can sniff the packets, and you are not using SSL, you are in trouble. With today's browser usage and site design practices, I personally feel that the value of encodeURL's rewriting as an overall concept is outweighed by the security implications that are unique to session id URL rewriting. Sure, I can probably find a way around it if my app server supports it or I minimize it in my application, by why should site designers be forced to do that by default. I think many would take security over compatibility, or at least be given the choice. As a Struts advocate, I'd like to see Struts embraced by more site developers, so I wasn't exactly looking for a one-off solution. Tom -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
