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
Re: Disabling jsessionid parameter in Struts forms
From Craig McClanahan: The jsessionid path parameter is indeed added by the call that Struts automatically makes to response.encodeURL() when setting up URLs for you. Without this automatic feature, you'd have to call encodeURL() yourself in order to ensure that your application works when your client does not have cookies enabled. ... There is no configuration parameter to turn this off, and there won't be. The important principle you should get used to is that the actual contents of the request URL is pretty meaningless in a web application based on Model 2 design patterns. You're far better training yourself (and your users) to ignore the URL completely rather than obsessing over the detailed contents. What are of concern to site maintainers are the security implications of passing the jsessionid in the URL. Consider the following scenarios (assuming user has cookies disabled): 1) The Referer header now contains the jsessionid. An example exploit on this would be on a struts-based web email site. A malicious 3rd party sends an html email to a user which contains an html link back to the 3rd party's site. The user opens the email in the struts-based web client and clicks the link. The malicious 3rd party now has the session id and can impersonate the user, as long as the session hasn't timed out. Note that the referer header is sent on https-to-https links as well in most if not all browsers, so using SSL doesn't solve the problem. 2) User A wants to share a struts-based link with User B. They copy the URL they are on and send it to User B. User B clicks the link and is inadvertently logged in as User A, as long as the session hasn't timed out. So, a site that wishes to avoid these risks might impose a cookies must be enabled rule. This rule is commonly imposed by major web sites - mail.yahoo.com, for example. Note: I'm not suggesting that this is the reason that yahoo chose to require cookies, but it establishes the fact the enforcing a cookies only policy is common today. My understanding (and I'd be pleased to be wrong) is that with non-customized Struts, imposing a rule like this and keeping the jsessionid always out of the URL is not possible. This seems restrictive, and perhaps should be re-evaluated. One part I'm not clear on is whether or not this can be solved at the App Server level. Perhaps if the app server doesn't honor the jsessionid parameter as a session establishment method, this might be a way around the problem. Though even there, it seems in scenario 1 above that the malicious 3rd party would still receive the jsessionid, because struts will send it regardless of app server settings. The malicious 3rd part could then forge a cookie containing the jsessionid, and they'd still be able to impersonate the user by passing the id in via a cookie. Regards, Tom Wadzinski -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
