I needed to change JSESSIONID's domain to ".something.com" in a context.xml file:
<Context path="/test" sessionCookiePath="/" sessionCookieDomain=".something.com" useHttpOnly="true" />
After that, when I perform a httpSession.invalidate() the session is reset but JSESSIONID value does not change.
I'm using Java 7, Spring MVC and Tomcat 7. I also tried to remove the JSESSIONID cookie manually, but it seems that Tomcat or Spring are not letting I change its value.
This may difficult troubleshooting on my system. I'd like to know if it's possible to change this behavior either on Spring or in Tomcat.
I found the problem in Tomcat's documentation:
"Note: Once one web application using sessionCookiePath="/" obtains a session, all subsequent sessions for any other web application in the same host also configured with sessionCookiePath="/" will always use the same session ID. This holds even if the session is invalidated and a new one created. This makes session fixation protection more difficult and requires custom, Tomcat specific code to change the session ID shared by the multiple applications."
Source: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
The issue is related to cookie path, and not with domain
Assuming you're using Spring Security, you can configure the session logout handler to delete the cookie for you.
...
<logout delete-cookies="JSESSIONID">
...
Or, in Java configuration, in a WebSecurityConfigurerAdapter:
#Override
protected void configure(HttpSecurity http) throws Exception {
http
...
.logout()
.deleteCookies("JSESSIONID");
}
If you're not using Spring Security, you can probably install a Filter object into Spring's existing filter chain to delete the Set-Cookie header in outgoing requests whose sessions have been invalidated (or on whatever condition you specify, at that point). This is more or less what Spring Security's logout handlers do, anyway.
Related
I am confused about a couple things regarding cookies.
Why do I need to use/customize javax.servlet.http.Cookie class in order to implement a Remember me feature?
In my web.xml couldn't I just use?:
<session-config>
<session-timeout>10080</session-timeout>
</session-config>
Isn't it a security issue having cookies on a computer? Couldn't a cracker steal another user's cookie and hijack their session?
You don't - you just need to create an http session. Tomcat will either create a cookie or use a jsessionid URL parameter to maintain your session - this is part of the Java EE servlet specification. If you use a JSP then they automatically create http sessions. Various other things can cause sessions to be created also.
Yes, this is called session hijacking.
In a webapp I'm using several filters and in one of the filter I'm using something that BalusC described as "session abuse". Basically in the Filter I do something like this:
request.getSession().setAttribute("abuse", ...);
while, later on, in a Servlet, I read back this attribute.
I'm using a session attribute instead a request attribute because I'm doing a redirect and that's where I'm lost...
After the browser receives the 302 and does the redirection, how does Tomcat (or any other Java webapp server) knows that the subsequent GET (the one after the redirect) belongs to the same "session" as the session returned while inside the first Filter (the one before the redirection took place)?
Does this work even if the client's browser has both JavaScript and Cookies turned off AND if I'm disabling JSESSIONID?
I should point out that JSESSIONID is disabled for SEO and for user-friendliness purposes: just like stackoverflow.com does never show super long URLs with pointless technobabbles in them, my webapp doesn't either while JavaScript and Cookies could be turned off by the user. So I want to know if the "session abuse" I'm doing would be working even if these three "client-side features" are not available.
If you have cookies disabled and url rewriting disabled, then the Servlet container cannot track sessions. Actually I think a few still can using SSL - there's a session tracking built into SSL, but I am not sure many servlet containers support this methodology and it requires pure SSL.
If you don't track sessions, then each session gets created and then orphaned.
I have JSP with calling to my Session Bean, I've implemented this via JNDI InitialContext(). Session Bean class is having a #RolesAllowed annotation with one defined user. I want to restrict users who can call methods of this bean.
Application Sever connected to TAM/WebSEAL via junction. So I can see that authenticated users have defined "iv-user", "iv-groups", "iv-creds" http request header values, unauthenticated - don't. But then I trying to call any of bean methods I've got a Security Exception like trying to access as unauthenticated user. Moreover, I don't see userPrincipal when at the response of request.getUserPrincipal()
How to pass security context from WebSEAL / Tivoli Access Manager into EJB and use it for JAAS annotations?
I've found one solution:
1. Switch WebSphere to use a Standalone LDAP registry, set link as Trusted (actually it not necessary)
2. Setup LTPA authentication between WAS and WebSEAL
after these JSP should get security context and pass to the called methods.
3. Define security constraints inside target web application.
I have read apache tomcat documentation a day before, and I am so confused about emptySessionPath . Up to my knowledge, if it's set to true, the emptySessionPath is stored at the root folder of web application. Please give the right definition of the term emptySessionPath and what happens if it is set to true and false?
Please guide me.Thanks in advance.
The emptySessionPath field just states whether the all cookie should be stored in the root URL path / (if emptySessionPath=true) or not (otherwise).
This is used by Apache's Connector. See details here (This is for AJP Connector, which is part of the Connnector object).
What this basically means is:
If emptySessionPath is enabled in
tomcat, the JSESSIONID cookie is
written to the root "/" path. This
means that whatever webapp you are on
will use the same cookie. Each webapp
will re-write the cookie's value to
hold that webapp's session id, and
they are all different.
When this is enabled and servlets in
different webapps are used, requests
from the same user to different
servlets will end up overwriting the
cookie so that when the servlet is
again interacted with it will create
a new session and loose the session it
had already set up.
If emptySessionPath is not set, there
are multiple cookies in the browser,
one for each webapp (none at the
root), so different webapps are not
re-writing each other's cookie as
above.
JSESSIONID is the ID Session for your Webapp. See a full explanation here.
Update: This information about usage is somewhat outdated - see here for a more up-to-date information on how to set the Session path also for recent tomcat.
If emptySessionPath is set to true, it will eliminate the context path from JSESSIONID cookie.It will set a cookie path to /.This attribute can be used for cross application autehentication mechanism.
Session are, as you probably know, often maintained by a cookie. A cookie has two values that determines whether they should be returned by the browser for a certain request, cookieDomain and cookiePath. The cookiePath must match that of the request.
A request is made for
/some/request/for/this.html
Cookie would be returned with cookie path:
/
/some
/some/request
But not for cookie path:
/other
By spec, a session is not shared between different web applications, so if you have web application foo.war deployed under /foo, the session cookie path would, by default be set to /foo.
It seems Connector.emptySessionPath is a protected variable on Connector. I haven't read the code - but I guess it has something to do with Tomcat's single sign on or sharing sessions, where you login to one context and are authenticated in all - in which case the cookie path must be / for the session cookies.
Just in case, for the web_app version 3.0, the cookie configuration is standarized, so the equivalent to the AJP's emptySessionPath in webapp 3.0 is:
<session-config>
<cookie-config>
<path>/</path>
<secure>true</secure>
</cookie-config>
</session-config>
In J2EE web application, how do I disable the default HttpSession creation?
We have our own way of tracking session, we don't use default jsp/servlet session but the default session sets cookie in browser which I would like to avoid. Right now on every JSP page we specify as session="false" in page directive but often some developers missing this part, so I am trying to find a common place where I can control default session.
I am trying to find a common place where I can control default session.
The answer is servletcontainer specific since that's the one responsible for session creation and management. The standard Servlet API isn't responsible for that. It's unclear which servletcontainer you you're using, so here's a Tomcat targeted answer: create your own <Manager>.
Alternatively, you can also entirely disable cookie support and rely on URL rewriting only (but not do it). This way sessions won't survive among requests. You can do this in in for example Tomcat by setting the cookie attribute of the <Context> element to false.
If you're using another servletcontainer, then you need to consult its documentation based on the newly learnt information and keywords here above, or just to mention here which one it is.