is it possible to disable session cookies on tomcat just for some web-application url patterns?
All the examples i´ve seen so far disables sesssion cookies for the entire web application, via configuration on context.xml.
Just for contextualization,in my scenario I have a BLAZEDS polling channel that I´d like to have cookies ignored.
TKS.
The easiest way I know of would be to create a Page Filter to remove the session cookie for those url patterns as the request comes in.
Related
I was doing some analysis on a grails application and i noticed two cookies being sent by browser to server everytime. If i understand correctly one session id should be enough to implement sessions in a web application but i am wondering why are two session ids being used instead of one. The cookie looks as follows:
JSESSIONID=4206209230A211D7D45DF1124B2E08C1; session-id=37663030303130312D353235342D313339652D383235372D363464386133343030303032
I apprecaite any help! Thanks!
The JSESSIONID is generated from the servlet-container like jetty or tomcat or the builtin if you run a grails app standalone.
The session-id is generated from the used http-server like apache, etc.
I assume, you run the grails application behind an apache/http-server proxy?
If you access the servlet-container directly, only the JSESSIONID cookie is send.
This might be a duplicate of this question, but the solution proposed isn't viable for us:
Protect against 3rd party callers of document.execCommand("ClearAuthenticationCache")? Clears our session cookies
Long story short: IE has a way to clear session cookies using JavaScript - document.execCommand(“ClearAuthenticationCache”). This is used in a variety of web apps including Outlook Web App (and presumably many others). Problem is MS in their infinite wisdom decided that this command should clear session cookies for all open sites (can you tell I'm a little bitter, it took me months to find the source of randomly missing JSESSIONIDs).
We use JSESSIONID as well as another token to make sure the user is authenticated. The JSESSIONID is secure and httpOnly. This works well except when the JSESSIONID is wiped out by a third party. So my question is in two parts:
Is there a way I can protect my session cookies from this (let's assume anything involving client side configuration, such as pinning or registry hacks, is a non-option)?
If not, is there a way for me to securely recover from this? Since the JSESSIONID is httpOnly, the browser shouldn't be able to read it, but maybe there is something I'm not thinking off.
If relevant: we use Tomcat 7 as our webserver. The app is a fairly complex SaaS app, and security is fairly important.
Thanks all.
I believe either of the following options would work to protect servlet sessions from document.execCommand(“ClearAuthenticationCache”):
You could set the max-age of your JSESSIONID in your web.xml. That way your JSESSIONID cookie would no longer be a session cookie! This would make your web application slightly less secure as the cookie would still survive after the browser is closed.
You could abandon HTTP cookies altogether and configure Tomcat to do session tracking with the SSL session ID. I've never actually configured it myself, but I would guess that this is more secure than using JSESSIONID cookies. However, session replication is not possible in this configuration.
In my code I am using spring direct login.
Once controller switches between https to http a new session is created, once new session is created, how do I pass/ copy the session attribute to new session Which was created by http?
Check the Spring Security FAQ. Basically, you can't copy the session attributes - all the session data from the previous is lost when you switch back to HTTP. Since the browser won't send the secure cookie, you have a new session and it's as if you hadn't logged in at all.
There are ways of working around this (see the FAQ for more details and search the web) but they are generally a bad idea. You should start in HTTPS and stay that way if security is important.
I have a web application running on JBoss server based on JSF framework.
I need to redirect my request to an entirely new web application running on some other server and on some other machine geographically located.
My doubt is if I redirect the request from my web page to another web application web page will it expose the session parameter at the other end.
I have some very critical information stored in the session and I cannot afford to expose the details to another web application..
Along with the redirect request I would be sending some parameters to the remote web application which will use these parameters for certain mathematical computation.
Can anyone guide me on this?
Is it possible for the other web application to see what is present in the session
No. That would have been a huge security hole throughout the current world wide web. Think about it once again, are you able to see what for example google.com and stackoverflow.com have in its session? No? Then the other web application definitely also can't. All which the web application can see from outside is the sole incoming HTTP request in its entirety.
This problem/question has at least nothing to do with JSF.
If you invalidate the session before the redirect then it doesn't matter if the external web application sees your session cookie. They couldn't turn around and emulate requests on your session anyway because the session is no longer valid.
request.getSession().invalidate();
I don't think this will be an issue though because I doubt that the request header to another web application would include the same session cookie.
How do Spring sessions work when you login to a form on Spring security as described in this tutorial? http://static.springsource.org/spring-security/site/tutorial.html
Is it cookie based? Im not sure what exactly is going on that allows the user to log in and have it remember and keep you logged in for the remainder of the browsing session.
It is cookie based similar to how the servlet maintains sessions . If cookies are disabled, you would have to resort to URL rewriting .According to the FAQ here.
"All it sees are HTTP requests and it ties those to a particular session according to the value of the the JSESSIONID cookie that they contain. When a user authenticates during a session, Spring Security's concurrent session control checks the number of other authenticated sessions that they have. If they are already authenticated with the same session, then re-authenticating will have no effect. "
also
"If clients have cookies disabled, and you are not rewriting URLs to include the jsessionid, then the session will be lost. Note that the use of cookies is preferred for security reasons, as it does not expose the session information in the URL. "
See here for the Single sign on feature